Rob Ainscough

It appears that when I install/deploy my .NET 2.0 app using a Deployment Project within my app solution, the first time my app runs it checks the the MyApp.MSI in the location from where the install was originated.

Is there any way to prevent this behavior My app is NOT deployed as a ClickOnce app and is not published so I don't understand why this check is happening

My deployment files are:

Setup.EXE
MyApp.MSI
CRRedist2005_x86.MSI

What I usually do is combine these three files in a single WinZip self extracting to produce an end result of MyAppSetup.EXE. This all works fine with ONE exception, WinZip self extractor will remove the above 3 files from the temp folder it creates. This becomes a problem because when I click on the desktop shortcut to MyApp, it proceeds to search for the original install location -- which WinZip self extractor process has removed.

I assume .NET framework is doing this to be able to determine "repair" location Is there anyway to tell it NOT to do this

Thanks, Rob.



Re: ClickOnce and Setup & Deployment Projects .NET app checks for original install location before running?

PhilWilson

MSI setups are nothing to do with .NET, this is a Windows installer thing.

Removing the source MSI file is not a good idea because it's required for repair if anything gets removed or damaged. It looks like you've installed the app then changed something, so it's going into repair. You can't guarantee that a repair will never happen (Add/Remove Programs has a repair choice; another app can be installed and damage your app, causing it to repair).

Rule 31:

http://blogs.msdn.com/windows_installer_team/archive/2006/05/24/605835.aspx

http://ablog.apress.com/ p=868






Re: ClickOnce and Setup & Deployment Projects .NET app checks for original install location before running?

Rob Ainscough

Phil,

Can you clarify So when I click on a shortcut that is created via my .MSI install, Windows Installer is triggered BEFORE it triggers the loading of my .NET app when I click on the shortcut

So I assume this means there is some MSI installer service now running on my PC monitoring this activity so it can intercept the message to start the .NET app

Is there any way to turn this OFF (use Orca)

Interesting links, but some of those rules make WAY too many assumptions about the intended user base. For my case, providing choices to our end users IS NOT what I want to do -- my end users get paid McDonalds wages, the less choices they don't understand the better. I realize Microsoft don't subscribe to this type of end user, but it sure would be helpful if they gave us developers the tools/options necessary to develop for this type of end user other than tell them to go buy a Mac.

Thanks, Rob.





Re: ClickOnce and Setup & Deployment Projects .NET app checks for original install location before running?

PhilWilson

MSI shortcuts are different - invoking them goes through some internal checking that the product is installed correctly. If not it goes into repair mode, then your shortcut target gets called. The interesting question is why it appears broken. It may be that you intentionally changed files/directories, or something else is going on and it's broken.

Repair via shortcuts can be turned off with setting DISABLEADVTSHORTCUTS to 1 in the Property table of the MSI file with Orca. Although that makes most people happy it's no guarantee that a repair won't occur. There are repair options in Add/Remove Programs, other entrypoints in setups apart from shortcuts that can trigger repair, and the possibility that some other product could change your product files and trigger a repair. Windows Installer just works like that, it's framework that imposes some rules, repair is built in, and discarding the original install source MSI file is a potential problem with repair.

This mechanism really is aimed at end users so that (among other things) accidental removal of files doesn't make the entire product unusable. I don't understand what user choices have to do with the repair issue. It's just a question of extracting to some non-temp location. I've done something similar, in one case with a self-extractor to the Program Files folder\Company\App that then launched setup.exe. In another case I packaged it all in another MSI file called "App Setup" that installs the setup files with a shortcut to setup.exe to install the app, they use the shortcut to install the app. .

There are about 20 tools to build MSI files:

http://installsite.org/pages/en/msi/authoring.htm






Re: ClickOnce and Setup & Deployment Projects .NET app checks for original install location before running?

Rob Ainscough

Some problems witht he assumptions Microsoft have made.

1. If the original install was on a network drive which then disconnected, the product will not execute at all even thought it was successfully installed -- I'm all for repairs, but the way it's implement causes MORE significant problems then it tries to solve.

2. The process of searching for the original MSI should NOT prevent the application from running when the shortcut is clicked -- if it doesn't find it MSI it should still continue, not prompt with a message for the user to locate it (this IS DEFINITELY NOT END USER friendly) and if cancel is pressed then it should still continue to run the app, not just fail and do nothing.

3. The repair is triggered directly after the install when the users clicks on the shortcut -- this is apparently done once and only once.

The tool I'm using is what is provided with VS 2005. Spending $4000/yr (more than the cost of my MSDN Universal subscription at $2500/yr) for a single dev license for InstallShield services is NOT an option. The very fact that InstallShield can price their product at such a high cost is pretty indicative that Microsoft's OS and installation process is overly complicated for the task at hand -- and Vista has only made matter worse not better.

I realize, not your issue (hoping someone at Microsofts gets a clue, but I doubt they ever will) -- but thanks for the MSI setting and link to MSI building tools. I'll investigate them as clearly what comes with VS 2005 is seriously limited (again more half hearted attempts from Microslop).

Rob.