Software Deployment

All I can offer is this. Almost everyone that posts on this site does so to fix problems with poorly designed software and/or documentation. If you don't want to see your product or company's name listed in a title of a forum post, FTLOG follow best practices and think of the end user, not what YOU want. Its the end users that will be using your product in ways you haven't considered yet. Make your product capable of handling situations such as silent installs, multiple users on a single machine, variables instead of hard coded pathes, flexibility in deployment methods, use in closed or dark networks (ie, no contact ever with the outside world) and get your product signed to make everyones life easier.

Don't take this as directed as you personally, but a plea from someone that has been deploying/packaging software for 12 years and has had my fill of crappy software and vendors that just don't GAS.

Capture the items that are being changed. Discover where the problem in the changes are (likely a hardcoded path or something that requires better use of a variable). Create some means to impliment them (exe, msi, script, etc). Create an Active Setup to apply the changes per user at login.

There's no difference if the launching shortcut is Advertised or not. The behavior is the same.

Why, when the apps are repaired, are they then broken for another user that was already functioning?

The item missing is...C:\Users\User1\Documents\My MyApp WorkArea. This comes from a component whose destination is set as [PersonalFolder]My Adept WorkArea in InstallShield.

This is what appears in the Event Log as the trigger for User2's repair. Why is it looking across to User1's information.

I would rather have user specific items removed from the install then bothering with Active Setup. I don't want to compound the install process further, I want to simplify it. I've read recommendation that an install should be Per Machine or Per User. We can't go the Per User route as we need some things in HKLM and protected areas of the file system.

Also, isnt the purpose of Active Setup to launch a repair when no entry point is available to the user? A repair is firing for me with both an advertised and non-advertised so what will Active Setup get me?

Per Machine vs Per User are not the same when it comes to coding within the application. Unless you are willing to go through and rewrite the vendors code (or MSI) and subsequently negate any type of support from the vendor, I would suggest you work with the Per User install. Make an MST which removes the user specific changes and then add them to a MSI/EXE/script. Call the MSI/EXE/script to make the changes required by the original MSI then also use it in an Active Setup.

ORIGINAL: jmaclaurin

Per Machine vs Per User are not the same when it comes to coding within the application. Unless you are willing to go through and rewrite the vendors code (or MSI) and subsequently negate any type of support from the vendor, I would suggest you work with the Per User install. Make an MST which removes the user specific changes and then add them to a MSI/EXE/script. Call the MSI/EXE/script to make the changes required by the original MSI then also use it in an Active Setup.


Not quite sure what you mean, but this. We are the vendor so we create the .msi. My ultimate goal is to remove all user specific components from the install and make it a true Per Machine installation. Then, we will rework code in our application to handle any needed user specific settings from items placed in Common App Data or somewhere in HKLM. The only real downside I see to this is creating a widget to run during uninstall that will clean all user areas. It would rid us of repair installs altogether. I should say it will rid us of the repairs we are used to seeing through use by non-installing users. Repairs may still occur, but after modifications, the per machine install/app will truly be 'broken'.

Until the time of rework, we are presented with the problem described initially. I just don't understand why Windows Installer looks to another User's area for installed components under the current, app initiating user. I can repeatedly toggle between the two users and a repair is always fired. Once repaired, it should be repaired as far as I'm concerned. Initiating our app from User1 should not trigger a repair because something in User2's profile is 'missing' or 'inaccessible'. I just can't figure out that logic. I would think it has to be something in our authoring of the installation package, but I wouldn't be surprised by this backwards logic from Microsoft.

When it comes to our authoring, I don't know what else it could be outside of marking certain user-specific items as component keys.

Per User installations won't really work for us since we have to place items in HKLM and restricted areas of the file system.

Presumably, in the original log of the install for User2, [PersonalFolder] resolved to the correct folder?

Believe me, that is what I'm trying to do. I try to tell development that I am simply dumping what they tell me is needed by the application and to locations they specify. One even stated the our file system structure is based on Windows 3.1. We still even write 'stuff' to the root of C:\!!! I hear everything you are saying about making things as seemless for the customer as possible. That is why I want to move away from writing user specific items during the install. We need admin rights for install now anyway so why not make it a strictly Per Machine install. User specific info should be handled by the app itself in this instance, I feel.

In short, I'm trying, but old timers here are resistent to change. They're starting to get it now that security is tightening.

ORIGINAL: VBScab

Presumably, in the original log of the install for User2, [PersonalFolder] resolved to the correct folder?


Why wouldn't it resolve properly. If it resolves correctly for one user, why wouldn't it for every user. That, I would think would be a Windows Installer shortcoming.

everything in the directory table should resolve properly on repair/install/remove whatever.
BUT maybe the vendor has some custom action in the msi filling the path.
maybe the custom action is not run during user repairs (because of conditions).

so take a look at the custom action table.
also try to get a verbose logfile out of the installation and repair and post everything relating to that path in it.

ORIGINAL: Superfreak3

The item missing is...C:\Users\User1\Documents\My MyApp WorkArea. This comes from a component whose destination is set as [PersonalFolder]My Adept WorkArea in InstallShield.
This is what appears in the Event Log as the trigger for User2's repair. Why is it looking across to User1's information.
You are expecting the target directory to be dynamic (to be reevalutated for each user that launches the app) but it is not. When User1 installed the app, [PersonalFolder] evaluated to User1's Documents folder, and that's what's cached when the installation is complete. When User2 runs the app, it sees a key path missing (possibly a CreateFolder entry for the above directory?) and so proceeds to repair the app based on the cached information, which is still pointing to User1's profile. There are special ways of dealing with per-user information in a per-machine installation. This subject has been covered extensively in this forum.

I would rather have user specific items removed from the install then bothering with Active Setup. I don't want to compound the install process further, I want to simplify it.
Good to hear. And your thoughts on removing user-specific information from the package and making it the responsibility of the app sounds valid, especially since you're talking about data under the Documents folder. It really doesn't seem appropriate for an app to install anything under the user's Documents folder. Let the app take care of that at run-time.

I've read recommendation that an install should be Per Machine or Per User. We can't go the Per User route as we need some things in HKLM and protected areas of the file system.
It's technically possible to go both ways, if your app supports it. I'm not sure I would bother, though. IMO, per-user installations are for home users, per-machine installations are for managed users.

My ultimate goal is to remove all user specific components from the install and make it a true Per Machine installation. Then, we will rework code in our application to handle any needed user specific settings from items placed in Common App Data or somewhere in HKLM.
Again, this sounds valid and I like it.

The only real downside I see to this is creating a widget to run during uninstall that will clean all user areas.
You shouldn't clean up anything in the user area on uninstall. This goes against best practice. Never delete user-created data and settings. (Plus, the data might not even be local to the machine!) If the user is merely reinstalling, they should not lose their preferences and data. If they are upgrading, the new version should be able to read the old data and settings and be able to migrate them.

If absolutely necessary to separate application settings between versions (maybe because you're changing the format of the settings files or some major change), consider having the new version store settings in a new, versioned directory and migrate from the old directory. For example:

MyApp v1.0 writes user settings to <AppData_Local>\Vendor\MyApp\1.0\
MyApp v2.0 writes user settings to <AppData_Local>\Vendor\MyApp\2.0\
etc.
Maybe MyApp v2.0 looks for settings in MyApp\1.0 on first-time launch and migrates settings to the 2.0 folder.

In general, though, if the app can safely reuse the same directory with each upgrade without difficulty and the developers remain consistent with settings file format and filenames, then consider going that route. It's entirely up to the development team and how the app is maintained.

Also, be sure to reference Microsoft recommended development practices such as Windows Logo documentation (or whatever they're calling it now).

(Hope that wasn't too muddled, especially when I switched from talking about user data to application settings.)

Actually, it might be better if you could have the software perform its final configurations for user specific settings at time of first launch (which is what I think you are working towards?), because it frees up the installation to be greatly simplified and can be made pretty vanilla in the end. The difficult part will be to convince your developers. It sure would make packaging and deployment easier. Especially if you design it so that something like an Transform or an Active Setup could be used to perform much of that first launch customization prior to launch.
Good luck!

All excellent responses and even better, they contained what I really wanted to hear!!

My feeling now is to spend most of my energy pushing for the Per Machine installation changes. I'm sure I'll get some pushback from the 'old time' Devs, but that won't deter me. In my opinion, the changes won't be that major and shouldn't have a huge impact, but some Devs will think they'll be re-engineering the entire product.

Since the repair of the two different user instances isn't really a show stopper, I'm not that concerned about tracking down the specifics of the scenario. Once the repair completes, the user is off and running. Also, we don't have many customers that have systems that are shared between different users, so that makes the issue even rarer, I guess. If I have some free time in the next couple of days, I might weed through logs, etc. My guess was that caching was involved in some way. In short, my situation is a product of how Windows Installer is supposed to work.

You are correct in that my idea is to have app startup complete any needed configuration. It is a good thought about configurations in version specific folders. I'll be sure to check with Dev to see if they feel that would be a safer way to go. In saying that, I don't know that the items I have slated for change will require this, but I will certainly check with them.

Thanks all SOOO much!!!

When User1 installed the app, [PersonalFolder] evaluated to User1's Documents folder, and that's what's cached when the installation is complete. Cached where?!? The user won't have rights to alter the MSI or the installation metadata in the registry, so...?