.NET app checks for original install location before running?

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.

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.

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.