Hi all..,
   im quite finished with a program.., and i want to create an effective installer... i tried using visual basic's package wizard but i  don't know what files it icluded but its quite large.., so i used a selfextractor how ever it looked unprofessional. when i tried it on a different computer w/o vb installed. it did not run.. it was looking for some .ocx.. (i did not catch the name..).. now im using INNO SETUP..., please help me on what files to include...

my program uses dao, jet engine, dbgrid

- Thanks.

For me u can try with install shields 9.0 is the best
u can download at:
www.installshield.com/downloads

but if u want the list for the file in your setup u can go to the tool of the microsoft visul studio a nd create a package , the it show u all the dependencies



____________________________
I don't mind not going to heaven
As long as they've got cigarettes
in hell

People always seem to underestimate:

http://msdn.microsoft.com/vstudio/downloads/tools/vsi11/default.aspx

and it's free too...

____________________________
Everywhere's Local (classifieds, job postings, & more for everycity in the world - user entered)

I agree with JLRodgers, I've given up on the Package and Deployment Wizard and use Visual Studio Installer (vsi11) instead as it gives more control over the process as well as providing the familiar Windows installer interface.

Steve


[Edited by SteveG on 02-12-2003 at 10:00 PM GMT]

tnx.. i look into it..

I had problems using Windows Installer, cause i couldnt make him register crystl32.ocx, so I had to continue using Package and Deplyment Wizard. When I tried to install it, I always received message

Error module \Windows\System32\Crystl32.ocx failed to register.

VSI has included CR files that needed to be installed (same files as PDW included), but I was successful in registering it using PDW.

Has anyone succeeded in registering CR using VSI?  

____________________________
If you find the answer helpful, please mark this topic as solved.

well, all you really need is what are needed for your program to run on other machines... like dlls, ocxs, fonts, registry data...

then you can create your own installer, seriously. i have done this before, though i don't have the code any longer, but it really isn't that hard..

with all coding, you can do what every installer does, from restarting the pc to registering data and dlls and other stuff!  

seriously!  

____________________________
Been busy trying to take a second degree <--it's not working out...

quote:

---

well, all you really need is what are needed for your program to run on other machines... like dlls, ocxs, fonts, registry data...

---

i didn't say it was siple, right?

i meant that most of the things an installer would do can be done with vb!  

if not all, then perhaps incorporating 3rd party software may be needed, but that has to be seen.  

____________________________
Been busy trying to take a second degree <--it's not working out...

Just a note, Goran (I've been cranking my head over MSDN about MSI for all the weekend...)

About DAO files, you could set the correct installation dir - Common Files dir - by adding a new special dir in the Installer project (they call the project a 'solution'): in the right pane, double click on File System under the Target Machine node, and on the File System window that appears, right click on a folder and choose Add Special Folder. Special folders avaliable are many, included Common Files folder, the right one for dao350.dll. In fact, you better check all the dependecies files' SourceFile property, in order to place each one in the right folder on target machine. So, no need of SharedLegacyFile = True, nor vsifrSelfReg (MS lords suggest never use this setting, so why they put in it?...).

It's amazing to me that among the avaliable special folders there's not the Start Menu\Programs folder. If I select the Start Menu folder as destination of a certain file, it places it in the root of Start Menu. Well, perhaps I must study it a bit more... (any hint?)

HTH


____________________________
Real Programmer can count up to 1024 on his fingers

Yes, Yronium, that is correct. To be precize, Common Files FolderMicrosoft SharedDAO is the appropriate folder for daoX.dll's. Thats the place where I also install them.
But, as I know, if you dont use vsifrSelfReg, on machine where no DAO library exists, it will display message like : DAO library not correctly installed, or registered, dont remember which.
Again, if you dont set SharedLegacyFile = True, it will uninstall it, no matter if any other application used it before you installed your app.
As I said, this is from my experience, I have installed several times fresh WinXP and Win98 OS in order to check if it works.

As for Start Menuprograms folder, the resolution would be in creating these folders: User's Start MenuProgramsYourApp and pasting your shortcut there.

Just a note, If you install your app on Win98, you will need InstMsiA.exe and Mdac_typ.exe in order to complete your installation succesfully.

[Edited by Goran on 18-01-2004 at 07:56 PM GMT]

____________________________
If you find the answer helpful, please mark this topic as solved.

quote:

---

Goran wrote:
... if you dont use vsifrSelfReg, on machine where no DAO library exists, it will display message like : DAO library not correctly installed, or registered, dont remember which.
Again, if you dont set SharedLegacyFile = True, it will uninstall it, ...

---

quote:

---

As for Start Menuprograms folder, the resolution would be in creating these folders: User's Start MenuProgramsYourApp and pasting your shortcut there.

---

quote:

---

Just a note, If you install your app on Win98, you will need InstMsiA.exe and Mdac_typ.exe in order to complete your installation succesfully.

---

If OS doesnt recognize msi extension then you need to install InstMsiA.exe. To perform this installation, MDAC should be installed on OS. If msi is known file format by your OS, then you dont need to install these files.

Windows Installer 2.0 Redistributable for Windows 95, 98, and Me

Windows Installer 2.0 Redistributable for Windows NT 4.0 and 2000

Microsoft Data Access Components (MDAC) 2.8

This files shouldnt be integrated in WMI (pointless), but distributed separately from installation. You should make readme.txt and explain user what steps should be taken if YourApp.msi cant be started.

I am glad that it helped you.  

[Edited by Goran on 18-01-2004 at 11:26 PM GMT]

____________________________
If you find the answer helpful, please mark this topic as solved.

OK, I'll have a look into. (What do you mean by 'pointless'?)

I checked my pc, and no problem with DAO. The error I got was due to a bug im my app, and I fixed it. I ran it without any installation, and got no misworking. I picked out some old MSAccess dbs in which i placed many DAO funcs, but everythig worked properly. I also found dao350.dll actually in its place, C:\Program Files\Common Files\Microsoft Shared\DAO folder. So it seems it didn't uninstall it. (Anyway, I believe SharedLegacyFile = True is always a good choice for dao, ado and other db engines, because users will probably need them again sooner or later).

I'll try running the .msi, and then uninstall it, out from the MSI environment, but as I read in MSDN site, the debug function in the Installer IDE creates an effective installation, the same we obtain running the .msi file out of it, so I'm expecting no changes, even about DAO. I'll tell you.

____________________________
Real Programmer can count up to 1024 on his fingers

As I said before, no problem with DAO. But I experienced another strange behaviour. Listen here:

I made my .msi files (two), and made a small Launcher.exe app, that chooses which one's to launch. It prompts user 'Do you want to install Module1 or Module2 ?', then according to user's choice launches the msiexec.exe file, with Module1.msi or Module2.msi file as parameter, and then closes itself.
(I first coded to run the .msi file directly by the Shell function, but it gave me an 'Invalid argument' error, so then I coded Shell SystemPath & "\msiexec.exe /i" & ModuleFile and it worked properly)

I stored it all in a removable storage device, tested it and everything worked. I stored it all in a hard disk, and again everything worked fine. So, I was ready to burn an install cd.
Prepared the autorun.inf file, and burned the cd.

Put the cd into the drive, the autorun made its duty, launched the Launcher.exe, then I selected the module, the Windows Installer windows 'Preparing the Windows installation' appears, but then.... an error: 'Unable to open install package. Contact application provider to verify the Windows Installer package is a valid package'. Then, the desert!
The funny thing is the following: I manually open the cd, locate the Module1.msi file (or either the Module2.msi), double click it, and it performs the installation as usual.
Today I tried it in four different pcs, and always the same behaviour.

What do you mind, can you explain this?


____________________________
Real Programmer can count up to 1024 on his fingers

Pointless - as no point in doing that.

Why would you include two files that are necessary on some OS to be installed, in order msi installation to work. So, if you include them in your installation (soution), this instalation cannot be started (due to above mentioned reasons) on some OS. WindowsXP, however, doesnt need this files, cause it already has them installed.

____________________________
If you find the answer helpful, please mark this topic as solved.

And would it be the cause of the above misworking? I always tried to install on Win98 machines, and the first pc I tried on is the same I made the whole app and setup solution (so it surely has those two files installed). But always, simply double-clicking the .msi files it worked properly.

(anyway, sorry, I don't understand yet what do you mean by 'point', I'm so dumb eheheh  )

____________________________
Real Programmer can count up to 1024 on his fingers

quote:

---

(I first coded to run the .msi file directly by the Shell function, but it gave me an 'Invalid argument' error, so then I coded Shell SystemPath & "\msiexec.exe /i" & ModuleFile and it worked properly)

---

No point of doing that - means that you are doing something that will have no results, so you shouldnt do it.

When you installed Windows installer, he installed all the necessary files. That is why I suggest you to install fresh new Win98, and then try to run your installation on it. Then you will see what I am talking about. Project installation shouldnt be tested in working area, cause u have there all the dlls properly installed. As for DAO, you can test if it works by unregistering it with regsvr32 ... /u, and then start your installation. If your program works, then you will know that it is properly installed. But, as I said, install fresh new OS and testing it there would be the best thing to do.

____________________________
If you find the answer helpful, please mark this topic as solved.

(So, if I'm right: "pointless" = "no doubts on doing it, do it, do it absolutely, do it now, why didn't you do it yet?, do you need Sister Act to help you put these files in your solution, guy?", am I right?)

So, if you need to install fresh an OS for each misworking I find, how long does it take to debug an app? I really believe you've done it, but it's a bit hard to me.
First: I don't have the cds of the OSs my app is destined.
Second: my app is destined to two specific pcs, and I know they already have dao, ado and other stuff installed, included over all Windows Installer (I'm aware this is not a general rule, but I'm in a hurry now for them)
Third and more: I don't really think that there are more than the five percent pcs in the world not using Windows Installer. It's been distributed first with MS Office 2K, so four years ago, and quite all the software avaliable since then use WI, that installs itself before making any installation. In my pc, installing and reinstalling various application, WI has been reinstalled and configured about a hundred times in four years. Anyway you're right: I could find an user that don't have it. But even in that case, couldn't I give him a special .msi pack with the two files included?
But anyway, this is only theory, and you're right, it takes only two minutes to me to include these files in my packs.

Only, now I'm urged with the above cd bug, and I need to solve it asap. I'll try this way too.

____________________________
Real Programmer can count up to 1024 on his fingers

quote:

---

So, if I'm right: "pointless" = "no doubts on doing it, do it, do it absolutely, do it now, why didn't you do it yet?, do you need Sister Act to help you put these files in your solution, guy?", am I right?)

---

So, how should I manage it?
Problem case: user don't have msiexec installed, or even mdac.
To solve it: I should modify my start setup small program, so it would install them when needed.
Procedure:
MyStartSetup Code
    Launch MySelectedModule.msi
    (Should I wait here? Normally I unload my app at once)
    If ErrorOccurred Then  ' (?)
        Launch InstMsiA.exe
        (Wait for complete msiexec installation, or NoMdac error)
        If AnotherError Then  '(??)
            Launch mdac_typ.exe
            (Wait for complete mdac installation)
            Resume Launching InstMsiA.exe
        End If
        Resume Launching MySelectedModule.msi
    End If
    Unload MyStartSetupProgram
End MyStartSetup Code
Is this method correct?

Now, the question: how could I detect the errors (?) and (??) and know that user don't have msiexec and/or mdac installed? And how can I know the launching error is the specific case 'User don't have msiexec/mdac in this machine'?
And then, what would be the ShellExecute correct syntax for launching InstMsiA.exe or mdac_typ.exe? I wasn't able to launch an executable by ShellExecute (tried with 'msiexec.exe i/Module1.msi' with no results), and found no samples.

(I used ShellExecute to launch the file directly, it works fine, so I burnt a - finally - working cd [ringing bells!!]. But it doesn't explain why using Shell by an hard disk or a flash pocket drive it worked properly. Maybe the Shell() function has problems when run by cds?)

____________________________
Real Programmer can count up to 1024 on his fingers

I think the best and easiest way for you would be to create readme.txt file, where you would explain the user how to deal with problems that occur. I think (but not sure) that when mdac is installed OS needs to be restarted. So, this will only make you more problems (after restarting you would need to detect if your setup was launched, so u should continue where you were), if you think of handling it with your app automatically.

I am glad that ShellExecute worked for you. Why Shell didnt work, that I dont know. You could go step by step, for instance, launching only msiexec, without any parameters. If it display a msgbox, requesting parameters,then you will know that it works, and that parameters are causing error.

Here is description for ShellExecute:

Declare Function ShellExecute Lib "shell32.dll" Alias "ShellExecuteA" (ByVal hwnd As Long, ByVal lpOperation As String, ByVal lpFile As String, ByVal lpParameters As String, ByVal lpDirectory As String, ByVal nShowCmd As Long) As Long

· hwnd
Specifies a parent window. This window receives any message boxes that an application produces. For example, an application may report an error by producing a message box.

· lpOperation
Pointer to a null-terminated string that specifies the operation to perform. The following operation strings are valid:
“open”
The function opens the file specified by lpFile. The file can be an executable file or a document file. The file can be a folder to open.
“print”
The function prints the file specified by lpFile. The file should be a document file. If the file is an executable file, the function opens the file, as if “open” had been specified.
“explore”
The function explores the folder specified by lpFile.

The lpOperation parameter can be NULL. In that case, the function opens the file specified by lpFile.

· lpFile
Pointer to a null-terminated string that specifies the file to open or print or the folder to open or explore. The function can open an executable file or a document file. The function can print a document file.

· lpParameters
If lpFile specifies an executable file, lpParameters is a pointer to a null-terminated string that specifies parameters to be passed to the application.
If lpFile specifies a document file, lpParameters should be NULL.

· lpDirectory
Pointer to a null-terminated string that specifies the default directory.

· nShowCmd
If lpFile specifies an executable file, nShowCmd specifies how the application is to be shown when it is opened. This parameter can be one of the following values:
SW_HIDE
Hides the window and activates another window.
SW_MAXIMIZE
Maximizes the specified window.
SW_MINIMIZE
Minimizes the specified window and activates the next top-level window in the Z order.
SW_RESTORE
Activates and displays the window. If the window is minimized or maximized, Windows restores it to its original size and position. An application should specify this flag when restoring a minimized window.
SW_SHOW
Activates the window and displays it in its current size and position.
SW_SHOWDEFAULT
Sets the show state based on the SW_ flag specified in the STARTUPINFO structure passed to the CreateProcess function by the program that started the application. An application should call ShowWindow with this flag to set the initial show state of its main window.
SW_SHOWMAXIMIZED
Activates the window and displays it as a maximized window.
SW_SHOWMINIMIZED
Activates the window and displays it as a minimized window.
SW_SHOWMINNOACTIVE
Displays the window as a minimized window. The active window remains active.
SW_SHOWNA
Displays the window in its current state. The active window remains active.
SW_SHOWNOACTIVATE
Displays a window in its most recent size and position. The active window remains active.
SW_SHOWNORMAL
Activates and displays a window. If the window is minimized or maximized, Windows restores it to its original size and position. An application should specify this flag when displaying the window for the first time.

If lpFile specifies a document file, nShowCmd should be zero.

Example from AllAPi:

Private Declare Function ShellExecute Lib "shell32.dll" Alias "ShellExecuteA" (ByVal hwnd As Long, ByVal lpOperation As String, ByVal lpFile As String, ByVal lpParameters As String, ByVal lpDirectory As String, ByVal nShowCmd As Long) As Long Const SW_SHOWNORMAL = 1 Private Sub Form_Load()     'KPD-Team 1998     'URL: http://www.allapi.net/     'E-Mail: KPDTeam@Allapi.net     'Send an E-Mail to the KPD-Team     ShellExecute Me.hwnd, vbNullString, "mailto:KPDTeam@Allapi.net", vbNullString, "C:\", SW_SHOWNORMAL End Sub

____________________________
If you find the answer helpful, please mark this topic as solved.

You know, the installing/uninstalling procedure I used removes effectively some elements. I explain better.
My modules are designed to work on two different machines, but to test them I installed them both on the same machine. And of course they use many common libraries. So, when I uninstall the first module everything works, but once I run the second uninstall it requires me to insert the cd. Its a proof that some shared files have been uninstalled with the first uninstallation. But I wonder why, in that case, if I run the Uninstall function in Control Panel it doesn't require me any cd? Where did it put the temporary file to be used to uninstall? It should be an .msi file, and it'd be different by previous module's one (they have different ProductIDs) but I didn't find it in the pc. It seems somehow the first uninstall has removed the second .msi file too. I'll have to manage this sooner or later, maybe by correctly setting the SharedLegacyFile property. I'll mind it.

I saw that sample code at AllAPI, but still remain the same question: once I launched MyModule.msi, how can I programmatically detect that msiexec is not installed? And then, how can I detect neither mdac is installed?



____________________________
Real Programmer can count up to 1024 on his fingers

Try with the -x insted of -i. If you use -i, it is equal as you have started your app.msi package.

Shell SystemFolder & "\msiexec.exe /x{2E43E9EE-52C2-4B8A-8172-ED1E0C583F26}", vbNormalFocus

This code will uninstall it.

Now, for the msiexec and mdac question, i dont see the reason why do you want everything to be automatically done. Many programs have their readme.txt file tat explains what should be done if some files are not installed. But if you are determined to do it automatically, i Suggest that you search for file(s) that is installed during this two operations. If it is missing - not installed, if not, everything is fine.

____________________________
If you find the answer helpful, please mark this topic as solved.

quote:

---

Try with the -x instead of -i. If you use -i, it is equal as you have started your app.msi package.

---

quote:

---

...i dont see the reason why do you want everything to be automatically done...

---

Returning this topic from the archive. Why? Becasue I was playing with the VSI today and came up with some very interesting discoveries, and answers to some Yronium questions back then.

Since me and Yronium were having some discussion on how to implement installation of Windows installer engine (files that are necessary to be installed in order to recognize msi extension). WinMe,Win2K, WinXP have this engine already installed with them, Win98 doesnt (not sure of WIn98SE), so if you try to run  msi setup package on brand new Win98, It will not recognize extension. I didnt know then that installing these files is possible from VSI:

Project - Properties - Build Type = Installer With WIndows INstaller Loader

....voila  

Then, for all those who were wondering how to associate files with your applicaton, no need to coding it, just go to Project - Associations, and there you can set which extensions will be associated with your application.

Then, when I wanted to create Stert - Programs - MyApp folder, I was always doing it by creating a folder named Programs, then folder my App, and VSI recognized it correctly and placed it where I wanted it to be. Today I have discovered that there is a constant that serves for this matter - ProgramMenuFolder. The way to implement it would be : Add Special Folder - Custom, and then enter ProgramMenuFolder instead of NewFolder. Maybe this way there would be no troubles with different OS language verions, as Yronium pointed out.

If I came up with some new discoveries, I will post them later

____________________________
If you find the answer helpful, please mark this topic as solved.

quote:

---

Goran wrote:
.... how to implement installation of Windows installer engine (files that are necessary to be installed in order to recognize msi extension).
....installing these files is possible from VSI:

Project - Properties - Build Type = Installer With WIndows INstaller Loader

---

quote:

---

....how to associate files with your applicaton, no need to coding it, just go to Project - Associations, ....

---

quote:

---

.... Add Special Folder - Custom, and then enter ProgramMenuFolder ...

---

quote:

---

If I came up with some new discoveries, I will post them later

---

i couldn't see any reply like this. 'cause it will 100% solve your problem. u better know that microsoft includes it's packaging and Deploying Wizard's Setup project.

if u've installed vb in ur C drive then it's project's file will be at: C:\Program Files\Microsoft Visual Studio 6\VB98\Wizards\PDWizard\Setup1

open setup1.vbp and make changes whatever u like.

We all knew PDW existance, yaar. We made this topic to deepen a more powerful tool: VSI. Once you tried it, you'll never leave it. Read the whole thread.

____________________________
Real Programmer can count up to 1024 on his fingers