install seems ok, app only runs under admin user

[Nerissa]

I'm new to creating actual packages for deployment, since I generally have full control of the machines I deploy to, and so I usually copy & register any needed libraries manually. (I know, bad idea) However, this time I need a package, since we're actually talking about distributing this one to clients.

The machines I'm deploying to (at least the first ones) are locked down pretty tight, so apps (and, in particular, library files in the system directory) can only be installed under an admin login.

I've created installs using both the P&D wizard and Inno, and in both cases it seems to install ok, and runs ok when I'm still logged in as the admin, but when the admin logs off and the actual user logs back in, I get "Unexpected Error; Quitting" when I try to run my app.

My app includes a couple of custom library files, a bunch of IPWorks libraries, and a handful of other libraries, so I don't know if any of those might be causing the problem, or if it's something else.

Any ideas?

[dilettante]

I won't comment on 3rd party setup packaging tools because I don't use them myself. However I am pretty sure that the old PDW that was replaced by Visual Studio Installer 1.0 and then 1.1 (back in the 1998 to 2000 timeframe) can only create per-user setups.

If you were to use VSI 1.1 (http://msdn.microsoft.com/en-us/vs2005/aa718352.aspx) you have the option of choosing either per-machine or per-user as the default, and overriding this via the command line if desired when you actually install.

You might take a look at:

Per-user Installations (http://msdn.microsoft.com/en-us/library/aa370813(VS.85).aspx)

Per-machine Installations (http://msdn.microsoft.com/en-us/library/aa370810(VS.85).aspx)

Specifying a Per-User or Per-Machine Installation (http://msdn.microsoft.com/en-us/library/aa371865(VS.85).aspx)

[Nerissa]

Thanks, I'll try VSI now and see if that solves my problem.

[Nerissa]

I guess I'm making progress... after I tracked down a script (someone) posted over here (http://www.xtremevbtalk.com/showthread.php?t=291403) so I could set the actual property for per-machine installation after creating the msi ...

But now I'm having install problems.

The dependencies go like this (names changed because it's probably more important to you to understand what type of critter they are than what specific functions they perform):

myApp.exe requires: msxml4.dll, myActiveX.exe, myControls.ocx, and a couple of other MS controls.

myActiveX.exe requires: msxml4.dll

myControls.ocx requires: msxml4.dll, myActiveX.exe, msinet.ocx, and a bunch of 3rd-party ocx files, some of which require mswinsock.ocx.

I'm now getting an error on install where myActiveX.exe fails to register. The app then proceeds to work for the admin user (I'm assuming because it registered ok on previous attempts to install on the same machine, so it is still registered), but I'm still getting the same error for the user, along with an error about not having a license for something, I'm not sure what.

I've tried creating a .msm file for myActiveX.exe, and another for myControls.ocx, and including them in my .msi for myApp, but I'm still getting the error registering myActiveX.exe

[dilettante]

The specific libraries are important for several reasons. Many, like MSXML 4.0, come in OS-specific versions and must be deployed in a particular manner, see: MSXML 4.0 Service Pack 2 (Microsoft XML Core Services) (http://www.microsoft.com/downloads/details.aspx?displaylang=en&familyid=3144B72B-B4F2-46DA-B4B6-C5D7485F2B42).

Others are considered part of the OS and cannot be redistributed, but must be installed or updated via Windows Update or a similar mechanism.

However since after all of this an admin user can still run the program that's probably not what has happened here. More likely something was trashed in HKCU during earlier attempts at per-user installation. The license error message might provide more clues.

You shouldn't need to create MSMs for your own components, they can go right into the MSI in the first place.

[Nerissa]

The license error message provides no clues whatsoever. It's simply "You do not have an appropriate license to use this functionality" with the title being my app's internal name. It comes after clearing the "Unexpected error; quitting" error, sometimes significantly after.

All of my 3rd-party ocx files come from the IPWorks package, which is licensed for distribution, I'm pretty sure you only need to have an explicit license for development. All of the other ocx and dll files I call are from Microsoft (TABCTL32, MSINET, MSWINSCK, MSXML4, and I think one other which is used in the main app, not in either myActiveX.exe or myControls.ocx.

I even tried to 'punt' just to get this app running (I have 2 machines I need to get it up and running on quick, then I have a bit more leisure before it needs to get installed anywhere else) and manually copy / register the components. I have had no problems doing this with these components in the past on other computers.

I directly downloaded msxml4.msi from MS onto the machine and installed it, in case that was the issue, then tried to register my myActiveX.exe -- the cursor never changed back from the hourglass, although the command line appeared as if it finished executing... then I tried to register myControls.ocx and got a failure with a return code of 0x80004005. Since myControls.ocx uses myActiveX.exe, I'm suspecting the problem is really in myActiveX.exe.

Also, I'm having the same issues on my development machine, which of course already had these things registered. I even tried recompiling both libraries in case they had gotten corrupted or something and still couldn't register them.

BTW, I'm not surprised to hear that I shouldn't need to create MSMs, but I figured it was worth a try, I suspect that at some point I'll want to create a separate install for them anyway, but that's not a top priority right now.

[dilettante]

You may have to back out earlier component registration manually using REGSVR32 /U for your component libraries. This may need to be done for every user under which a setup or MSI was deployed or the EXE was run.

Some scenarios will result in the run of an EXE self-registering components under HKCU.