Hoppas någon som vet!
Jag har har gjort ett litet program till min bil i VB 6.0. När programmet var klart så skapade jag en .exe fil. Nu var det så att en kompis ville ta del av programmet så jag la .exe filen och databasfilen i en mapp på hans dator och skapade en Användar-DSN koppling. Grejen med detta är att jag tycker det känns inte som ett komplett program eftersom man först och främst måste lösenordskydda databasfilen så ingen kan komma åt att ändra i den från datorn plus att jag måste skapa en DSN. Detta innebär ju att jag måste hjälpa alla som vill ha programmet vilket känns både amatörmässigt och som ett okomplett system. Alla program man installerar på datorn har ju någon sorts installationsprocess.

Min fråga är:
Hur upprättar man en en sådan installationsprocess så att man slipper lösenordskydda databasfilen och skapa en DSN?

PDW (Package and Deployment Wizard)

Jag har gjort en installation i PDW men får följande fel då jag ska installera programmet:
"Setup cannot install system files or update shared files if they are in use.
Before proceeding, we recommended that you close any applications you may be running."

Vad kan vara felet?

Bakas databasfilen in då man gör en installatinsfil, det är ju en föruttsättning?

Nej .mdb filen och andra tex läsMig filer får du addera när du kör PDW.
det kommer ju en sån fråga en bit in i programmet.

Felet du får betyder att något annat databas eller Vb prog körs på datorn
som du försöker installera på. Gör som dom säger stäng ner program som stör.

Ctrl Alt Delete så ser du vad som är i gång.

Kom igen om det kör ihop sig.Så kan Vi ta det steg för steg via mail här hos pelle.

En sak till vilken Win ver. installerar du på ? WinXP kräver ett visst trix.

"WinXP kräver ett visst trix."

Please Sven, jag vill veta mer om ovanstående

Om jag fortsätter att installera trots ovanstående problem får jag efter ett tag följande problem:
"An error occured while registrering the file 'C:\WINDOWS\System32\msado26.tlb'"

Jag använder WinXP.

Jag har inga program som körs i bakgrunden.

Jag skulle hemskt gärna vilja veta steg för steg hur man gör.

En till fråga, jag la till databasfilen och det funkade. Men den filen kan man ju komma åt i mappen där setup.exe ligger. Då kan man ju öpppna filen och ändra i den. Det jag menar är att man då måste varje gång någon ska använda programmet säga åt dom att lösenordsskydda databasfilen vilket känns konstigt. kan man inte göra den oåtkomlig då man lägger till den när man gör installationen i VB.

HJÄLP!!!

mmm.... det var det jag förstod. Det betyder att den versionen av .dll:en redan finns
och WinXP System32 inte tillåter att du pillar med dessa vitala dll:er.

Din version som du försöker installera måste vara äldre än den som redan finns
Då känner installationen av att det finns en nyare och skippar denna åtgärd.

Detta är en känd gammal "bug" som det skrivits spaltmeter om.

Jag kan hänvisa om du är intresserad. Du kan söka här hos pelle på Oleaut32.dll
så hittar du massor av tips.

> <b>Det betyder att den versionen av .dll:en redan finns och WinXP System32 inte tillåter att du pillar med dessa vitala dll:er.</b>

Jodå, om man vet vad man gör så går det utmärkt. Hur tror du annars att tex ett ServicePack till WinXP kan uppdatera nyare filer?

> <b>Din version som du försöker installera måste vara äldre än den som redan finns</b>

Naturligtvis inte. Varför ska du överhuvudtaget försöka installera en äldre version? För att slippa ett felmeddelande? Då använder du dig av en taskig installer.

> <b>Detta är en känd gammal "bug" som det skrivits spaltmeter om.</b>

Knappast en bugg. Den heter Windows File Protection och är till för att man inte ska kunna installera okända och otestade filer/versioner hur som helst i systemet.

Titta tex på Wise.
Wise KB Article #1396
HOWTO: How does Windows Installer handle the file versioning?
<URL:http://www.wise.com/KBArticle.aspx?articleno=1396&keywords=windows+file+protection>

INFO: Windows Installer and Windows File Protection
<URL:http://support.microsoft.com/default.aspx?scid=kb;en-us;303970>

Nu kom "Bror Duktig" in bug och bug men NT XP tillåter inte vad som helst.

Sanning är att du skall ha äldre versioner av aktuella dll:er mm som redan finns
på maskinen för att inte få konflikt med NT XP System32. Ref. PDW (vet inget annat)

Sen en fråga till Rickard ??? hur många appliktioner har du programmerat
och gjort lyckade installationer på NT och XP maskiner ???

> <b>bug och bug men NT XP tillåter inte vad som helst.</b>

Nej, naturligtvis tillåter inte WinXP vad som helst. Vad WinXP tillåter och hur det fungerar med WMP står i de artiklar jag refererade till.

> <b>Sanning är att du skall ha äldre versioner av aktuella dll:er mm som redan finns
på maskinen för att inte få konflikt med NT XP System32. Ref. PDW (vet inget annat)</b>

Generellt är det inte sant. Möjligt att det fungerar så i PDW, men isåfall är det dags att uppgradera sina kunskaper. Läs på om MSI-formatet. Om en dll redan finns i systemet med en version som fungerar med din applikation, då ska du ju inte behöva skeppa med en äldra bara för att PDW kräver det. Varför håller du kvar vid en gammal teknik som inte fungerar så som nya OS är byggda för?

> <b>hur många appliktioner har du programmerat och gjort lyckade installationer på NT och XP maskiner ???</b>

Jag har inte programmerat några applikationer, men det är inte applikationsprogramering denna frågan handlar om, utan installationspaketering. Jag är, som du mycket väl vet administratör och inte utvecklare. Däremot så ligger installationspaketering närmare administration än utveckling. På mitt arbete så sitter jag med i gruppen som paketerar om 600 applikationer till MSI-formatet för att distribuera dem på 14.000 WinXP klienter. Det kanske ger svar på att jag uttalar mig inom de områdena jag har kunskap om?

Ok Rikard jag har respekt för hur det ser ut på din sida.

Jag har efter stor möda också lärt mig vad som behövs för att mina prog
skall funka på NT XP ,nu vet jag allt som är värt att veta hur man får PDW
att funka i denna miljö.Vad beträffar att bli modern , så ligger jag lågt där.
Ms slänger ut så många "sjunkbomber" så jag ser helst att alla gick över till Linux.

Läste för någon dag sedan att det stora landet Kina är inne på samma ide.

Jag är deras supporter , gör Er av med beroendet till MS.

Okej, vad ska jag använda mig av för att kunna skapa installationsfil för att sedan kunna installera programmet på alla datorer oavsett operativsystem och utan att få felmeddelanden.

Det är ju en förutsättning attt det ska gå att installera på alla datorer annars kan man ju inte sälja eller ge bort programmet till andra. Man vet ju inte vad dom har för operativsystem.

Detta får bli ett generellt svar.

> <b>Okej, vad ska jag använda mig av för att kunna skapa installationsfil för att sedan kunna installera programmet på alla datorer oavsett operativsystem och utan att få felmeddelanden. </b>

Vad menar du med "oavsett operativsystem"? DOS? Windows? Linux? Mac? AS400? OS390? Om du menar alla dom så vet jag faktiskt inte. Troligtvis får du skriva din mjukvara i C till att börja med.

Men troligtvis menar du Windows. Vilka versioner av Windows menar du isåfall? Win3.11? Win95-98-ME? WinNT4? Win2000-XP-2003? Antagligen menar du de operativsystem som Microsoft fortfarande supporterar, och då är det Win98-ME och Win2000-XP-2003.

Om du menar de OS som Microsoft fortfarande supporterar, då tycker jag att du ska titta på någon mjukvara som använder sig av MSI-filer för att skapa installationspaketen. Det finns en uppsjö, tex har Microsoft en egen som ingår/finns att ladda ner för VS.NET, dels har Microsoft en fri mjukvara i sin MSI-SDK, det finns även mjukvaror från Wise, Installshield och Veritas.

"...kunna installera programmet på alla datorer oavsett operativsystem och utan att få felmeddelanden"


Svar: påminner stark om gamla moment-22

Det är därför det går åt så många specialister att fixa eländet med att få installationer att funka.

JA, JA, JA, det krävs att den som gjort installationsfilen verkligen fattar vad han gör och det är tyvärr väldigt ofta jag inte vet det och med mig många andra.

Här är sådana som RickardD en guldgruva som har mycket god erfarenhet och kan säkert ge oss mer tipps, han har sett eländet många gånger.

Bara att inse att de som skapar os inte bryr sig om att det blir problem senare.

Jag menar de operativsystem som Microsoft fortfarande supporterar.

Till att börja med är jag väldigt ny på detta område så därför tänker jag ställa lite frågor.

>Titta på någon annan mjukvara som använder siga av MSI-filer för att skapa installationspaketen.
Fråga: Vad menar du med annan mjukvara (istället för PDW)?

Vad används Windows Installer till?
Är det för att skapa ett installationspaket till ett program eller är det bara för att hantera versioner, språk etc.

Är tex MSI-SDK en typ av motsvarighet till PDW?

Används Windows Installer och MSI-SDK tillsammans eller separat?, eller är det helt olika program?, vad är skillnaden?

Är MSI-SDK något som du rekommenderar?

En god ide vore väl om RickardD skapde en artikel inom detta område som han kan lägga upp här på Pellesoft!

Som du märker är jag inte insatt i detta så all hjälp är önskvärd :-)

Joo "Bror Duktig" vill gärna göra sig lustig och inpopulär,jag förstod att du menade
olika Win xxx , det förstod han också , men ! han vill "häva" sig och det blev "förhäva".

Ok till saken : I din SetUp får du inte ha nyare ver. av filer som redan finns
i användarens System32.Detta gäller NT4 2000 XP. Oftast Oleaut32.dll och . tbl filer.

Har skrivit många rader om detta, allt ligger i mappen Wizard - PDW - Redist .
Sök igen på tex "Oleaut32.dll" så kan du läsa om detta som varit uppe 100 ggr.

Till Rickard din "mesterschmidt" attityd för inte verksamheten framåt.

> <b>Jag menar de operativsystem som Microsoft fortfarande supporterar.</b>

Perfekt, då blir det genast mycket lättare. Men man vet faktiskt aldrig, du kunde ju faktiskt menat exakt vad du skrev.

> <b>Vad används Windows Installer till?</b>
> <b>Är det för att skapa ett installationspaket till ett program eller är det bara för att hantera versioner, språk etc.</b>

Windows Installer är ett helt koncept från Microsoft. Skapat just för att lösa alla problem som Roland beskriver och det problemet som du upplever med PDW.

En bra början för att få grepp om konceptet är att läsa:
Windows Installer: Benefits and Implementation for System Administrators
<URL:http://www.microsoft.com/windows2000/techinfo/administration/management/wininstaller.asp>

Kort kan man säga att Windows Installer är hela konceptet. I det så ingår en service på klienten som har hand om själva installationen. Den har även hand om att man ska kunna avinstallera, uppgradera, lägga till/ta bort komponenter och reparera sin installation. Har du installerat Office 2000/XP någon gång? De är helt byggda av Windwos Installer/MSI. Har du tillgång till din Officeskiva? Isåfall kan du prova att ta bort hela katalogen C:\Program Files\Microsoft Office, och sedan gå in i Control Panel => Add/Remove Programs och köra Repair på Officepaketet. Alla filer kommer att återställas, beroende på vilka val du gjorde under installationen. Om du inte vågar göra riktigt det drastiska steget så kan du gå in i Add/Remove Programs och välja Change på Office-paketet. Då får du upp installationsalternativen igen, och kan lägga till och ta bort komponenter. Det är detta som Windows Installer hjälper dig med.

Windows Installer bygger på några olika filtyper, MSI, MSP och MST. MSI-filen är egentligen en databas som antingen innehåller pekare till filer du ska installera och/eller själva filerna. I den databasen så står alla defaultvärden som ska gälla under installationen. När du sedan installerar din applikation så kommer en MSI-fil att skapas som kommer ihåg dina val. När du sedan väljer Add/Remove så uppdateras MSI-filen.

MSP-filen är en patch. Om du i din orginal MSI-fil har en minfil.dll version 1.0 och väljer att köre en Repair, då kommer din MSI-fil att återställa version 1.0. Om du har uppdaterat din mjukvara med version 1.1 så kommer MSI-filen fortafarnde att återställa version 1.0, därför att det är den informationen som finns i MSI-paketet. När du släpper en uppdatering så ska du göra det via MSP. Vad som då händer är att din mjukvara kommer att uppdateras + att MSI-filen kommer till att uppdateras med vilken version du har installerat. Så när du sedan kör en repair så kommer rätt version att installeras.

MST filen är en Transform. MSI-filen som du installerar innehöll ju filer och defaultinställingar. Som systemadministratör är man ju intresserad av att kunna påverka defaultinställingarna. Det gör man via en MST fil. Man kan se det som en svarsfil till de olika valen man som användare får under installationen. På så vis kan man som admin skräddarsy sina installationer och göra de helt automatiserade för användaren.

Man ska också ha i baktanken att Windows Installer bara är en teknik från Microsoft, ingen mjukvara.

> <b>Är tex MSI-SDK en typ av motsvarighet till PDW?</b>

PDW är ett komplett verktyg för att göra den gamla typen av installationspaket.

En SDK betyder Software Development Kit och är egentligen allt en utvecklare behöver för att sätta sig ner och göra saker från scratch. Som tur är så har många tillverkare gjort applikationer så man inte behöver använda SDKn själv. Men den finns, och den är gratis, och med den kan man göra allt som man kan göra med andra program. Länken dit <URL:http://www.microsoft.com/msdownload/platformsdk/sdkupdate/default.htm?>

Det som snarare är en motsvarighet till PWD är Visual Studio Installer.

Visual Studio Installer 1.1
<URL:http://msdn.microsoft.com/vstudio/downloads/tools/vsi11/default.aspx>.

Visual Studio Installer Quick Start
<URL:http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vsinstal/html/vehowvisualstudioinstallerquickstart.asp>

Och en jämförelse mellan VSI och PDW
Considerations for Choosing Visual Studio Installer
<URL:http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vsinstal/html/veconconsiderationsforusingvisualstudioinstaller.asp>

Med VSI så kan du skapa MSI-paket från din Visual Studio 6. När du paketerar MSI-paket så kan du även använda Merge Modules. Och det är egentligen detta som är ditt ursprungliga problem. Det var att du hade problem med en fil till MDAC. Om du använder en Merge Module till MDAC så kommer MSI-filen att installera MDAC om den behövs, och om den inte behövs så hoppar den över den.

"How to Install MDAC with a Windows Installer Merge Module" White Paper Is Available
<URL:http://support.microsoft.com/default.aspx?scid=http://support.microsoft.com:80/support/kb/articles/Q320/7/88.asp&NoWebContent=1>

Nu ska det också sägas att VSI är ett väldigt basic Windows Installer GUI, men det är gratis. Vill du dra full nytta av Windows Installer så får du gå på någon av de kommersiella produkterna. Exempelvis:

Från InstallShield
<URL:http://www.installshield.com/downloads/>

Från Wise
<URL:http://www.wise.com/products.asp>

Från OnDemand Software:
<URL:http://www.ondemandsoftware.com/>

Ja, det finns hur många som helst som gör applikationer för att skapa MSI-paket.

> <b>En god ide vore väl om RickardD skapde en artikel inom detta område som han kan lägga upp här på Pellesoft!</b>

Tid min vän, tid! Har en sambo som redan tycker att jag jobbar för mycket. Dessutom, Microsoft har artiklar för detta som är betydligt bättre än något jag skulle kunna knåpa ihop. Men jag hoppas att jag har förklarat lite. Annars är det bara att fråga på.

Ok, tack så mycket för hjälpen. Ska prova Visual Studio Installer 1.1. Jag återkommer ifall det dyker upp problem. Det känns som om jag skulle behöva support :-)

Varför Vi ofta hamnar fel när RickardD kommer med sina inlägg är
att han jobbar i en storanvändarmiljö nätverk > 100 användare.

De flesta som skiver här jobbar på ett lägre plan ,sitter och pular med
en två användarlösningar. Dvs proffs och amatörer,själv är jag amatör och trivs med det.

Ha det tänk på Era kära bortgångna Format$(Now,"yyyy-mm-dd").

Jag har installerat Visual Studio Service Pack 4.0 och hämtat hem Windows Installer 1.1 (setup1.exe och setup2.exe) men jag kan inte installera Windows Installer pga av att följande fel visas under installationen:

Setup could not open the file:
VSI2.cab

Vad kan vara fel?

> <b>Jag har installerat Visual Studio Service Pack 4.0</b>

Visual Studio 5 är den senaste.
<URL:http://msdn.microsoft.com/vstudio/downloads/updates/sp/vs6/sp5/default.aspx>

> <b>Setup could not open the file:</b>
> <b>VSI2.cab</b>

Det känns som om att du inte packat upp båda filerna i samma katalog.

VSI2.cab är innehållet i setup2.exe.

Ok, tack. Det var det som var felet.
Tack än en gång. Ska prova jag återkommer ifall det blir problem.

hej! Testa så här.
1. klicka på Add-ins
2.Välj add in manager
3. välj package and deployment wizard, klicka på den och om allt är rätt så ska det stå loaded. Tryck på ok.
4. klicka på Add-ins
5. välj package and deployment wizard följ instruktionerna

Hoppas att det funkar Mvh Mattias

Problem igen!

Jag valde Visual Basic Installer när jag skapade ett nytt projekt. Sedan letade jag fram mitt projekt och valde "Create Merge Module", sedan "Only runs on the current OS locale, with English dialogs".

Får följande fel i Task listen:
*** One or more files in MSVBVM60.MSM have different versions than those installed on this machine.

*** One or more files in MDAC.MSM have different versions than those installed on this machine.

*** Neither a merge module or dependency information could be found for c:\program\delade filer\system\ado\msado26.tlb

*** Neither a merge module or dependency information could be found for c:\program\microsoft office\office10\msword.olb


>>>När du paketerar MSI-paket så kan du även använda Merge Modules. Och det är egentligen detta som är ditt ursprungliga problem. Det var att du hade problem med en fil till MDAC. Om du använder en Merge Module till MDAC så kommer MSI-filen att installera MDAC om den behövs, och om den inte behövs så hoppar den över den.
"How to Install MDAC with a Windows Installer Merge Module" White Paper Is Available


Måste jag installera MDAC eller räcker det bara att kryssa i alternativet "Create Murge Module" när jag skapar Visual Basic Installer.

Detta är inte lätt, hur ska jag få detta att fungera. :-(

Ja det är en djä soppa.Men jag får det alltid att fungera Nu på tex XP med PDW
sedan jag alltid följer denna princip.

The Package and Deployment wizard will pick up the files
from this location rather than taking them from your
Windows\System32 folder.

Files: versioner

· ASYCFILT.DLL 2.40.4275

· MSVBVM60.DLL 6.00.8495

· OLEAUT32.DLL 2.40.4275

· OLEPRO32.DLL 5.0.4275

· STDOLE2.TLB 2.40.4275
Dvs äldre versioner än de som redan finns på moderna XP maskiner.
Sen tillkommer att du måste göra installationer på XP som Administratör .
Din PDW folder Redist är nyckeln till framgång den skall innehålla de rätta versionerna.

> <b>Får följande fel i Task listen:</b>
> <b>*** One or more files in MSVBVM60.MSM have different versions than those installed on this machine.</b>

> <b>*** One or more files in MDAC.MSM have different versions than those installed on this machine.</b>

Detta handlar om att du ska skicka med Merge Modules för Visual Basic SP5. Dessa felmeddelanden brukar man kunna ignorera vid skapandet av sin installation. Viktigt med Merge Modules är att du använder samma version som för den Service Pack du har installerad i ditt Visual Studio. Du hittar den här:

<URL:http://msdn.microsoft.com/vstudio/downloads/updates/sp/vs6/sp5/mmoverview.aspx>

Den här artikeln verkar också bra för dig:
Deploying Hybrid Visual Basic 6.0 / Visual Basic .NET Applications
<URL:http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dv_vstechart/html/vbcondeployinghybridvisualbasic60visualbasicnetapplications.asp>

> <b>*** Neither a merge module or dependency information could be found for c:\program\delade filer\system\ado\msado26.tlb</b>

Detta verkar ha att göra med ADO 2.6 Type Library. Du kan inte prova att använda ADO 2.7? Som förhoppningsvis ingår i MDAC 2.7? Som du fick en Merge Module till i förra inlägget. Ledsen, men databaskopplingar och MDAC är inte mitt starka gebit. Men, generellt är det bättre att distribuera en hel Merge Module en enstaka filer.

> <b>*** Neither a merge module or dependency information could be found for c:\program\microsoft office\office10\msword.olb</b>

Vad är detta? Något med Word antagligen. Innebär det att du kan skicka med enbart bara den komponenten, eller måste du kräva att den som ska installera ditt program måste ha Office/Word installerat? Får du licensmässigt skicka med enbart den komponenten? Jag vet inte, men generellt känns det nog inte som en bra ide att använda sådana komponenter.

Hej

När ändå diskutionen handlar om installationsprogram.

Är det någon som har några synpunkter eller erfarenheter av programmet
Visual Installer 2002 från SamLogic, om det programmet uppfyller kraven på ett
bra installationsprogram för vb applikationer.

Är inte direkt gratis men verkar väldigt enkelt att använda!

/Tobbe

> <b>Är det någon som har några synpunkter eller erfarenheter av programmet Visual Installer 2002 från SamLogic, om det programmet uppfyller kraven på ett bra installationsprogram för vb applikationer.</b>

För mig är det ett krav på att slutresultatet blir en MSI-fil som jobbar med Windows Installer. Visual Installer 2002 från SamLogic uppfyller inte detta, och du kan därmed aldrig följa Microsofts rekomendationer för en Certified for Windows-logga. Inget att rekomendera alltså.

Den här är en riktigt lurig sak som jag hittat i samband med installtioner.

På ett svenskt system finner man denna:

c:\Program\delade filer\system\ado\xxx

(där xxx syftar till filer som ligger i den mappen

På ett engelsk system finner man denna:

c:\Program Files\shared files\system\ado\xxx

Har råkat ut för en användare som troligen gjort om installation eller blandat från olika lansunika typer eller dyligt, (det är tydligen möjligt) han visste inte exakt hur det gått till bara att han inte hittat på något hyss själv. (Nä, han heter inte Emil, men han är relativt duktig och arbetar som IT-ansvarig på företaget)

Där fick vi elände med installationer då vissa filer var registrerade från ena mappen och andra filer registrerade från nästa. (dll-er)
Vi hade då problem med att äldre dll-er ej ville ersättas med nyare trots att vi körde med Microsofts installationsfiler nedtankade från deras sida
(installtion MDAC version 2.7)

Givetvis var det vi som var korkade och borde ängnat tiden åt något bättre t.ex läst mera manualer (där vi nog fortfarande hade suttit fast)

Men hur något OS kan tillåta att man får ha landsunika namn där man lägger systemfiler är fullkomligt obegripligt. Finns säker någon bra förklaring. Men detta är en källa till problem med installtioner.

Fick hjälp här på forumet av flera duktiga och hjälpsamma personer bl.a. personer från Microsoft för att knäcka det problemet. (återigen Tack till er)
(den installtionen gällde en XP-pro maskin)

>Program Mapp shared files / delade filer
Har gjort samma erfarenhet , det är för djä... att det inte finns en enhetlig standard.

Skulle vara inressant att höra RickardD kommentera detta dilemma.

Tack Rikard för inlägget om de olika MSI, MST osv. -filerna. Mycket intressant läsning!

/Magnus
MCSE, MCSA, MCT