I have created a signed vs 2008 setup project and placed the resulting msi file on my website for clients to download.
The program installs and runs fine, but if the msi file is removed from their computer, the program stops running giving the error message that 'the feature they are trying to use is on a network resource that is unavailable'. If they save the msi to their desktop then remove the msi, the error occurs or if they hit Run instead of Save, then delete tempoary files, the error occurs.

I don't want my program to be dependent upon the msi file. What is it looking for and how do I make it stop looking?

Thanks,
Rick

It's best to keep the MSI file available (that's a recommendation from the MSI dev team) because of repairs. Ordinarily your program should not be dependent on the MSI file, but it looks like you are seeing a repair and it's trying to get to the MSI file.

In the web case, the thing to do is download it to a safe place on the client system and install it from there (because otherwise it installs from the Temp Internet files folder and can get removed). The Windows SDK has a setup tool together with another called msistuff that creates an exe to download from the web site and run it from a non-temp folder because of this issue.

---

Phil Wilson

Phil:

The app being installed is a .net remoting app that automatically downloads updated program files. I suspect this triggers the msi to want to 'repair' it by restoring the original file. Obviously this is undesirable behaviour.

I just want the msi to install. I don'tneed or want the msi file to handle repairs or be required for my app to function, so the question is how I disable these undesirable behaviours.

Thanks,
Rick

Hello Rick,

As far as I know, most programs don't need the installer package(msi) to run correctly. You can try to use the Dependency Walker to check if there is any library missed for the application to run correctly, or if the referred library is in the temporary folder and might be removed from time to time. If there are some libraries missed, it might start a repair process and needs the MSI package.

http://www.dependencywalker.com/

I performed a test on my side, but I cannot reproduce this issue. To troubleshoot this issue, I would like check the following things with you.

1. Does this happen to all client machine?
2. How you package the program files? Embedded in MSI file, in cabinet file or as uncompressed files?

It would be more helpful if you could show us more detailed information and the steps that you create the MSI package. So that we can try to reproduce and investigate the issue locally. It is not necessary that you send out the whole of your project. We just need a simplest sample to reproduce the problem. You can remove any confidential information or business details from it. I appreciate your work on providing these information.

Thanks,
Rong-Chun Zhang
MSDN Subscriber Support in Forum
If you have any feedback on our support, please contact msdnmg@microsoft.com

---

Please remember to mark the replies as answers if they help and unmark them if they provide no help.
Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.

Hello Rong-Chun:

The scenario is the msi file is downloaded and installs the application successfully regardless of whether the msi is 'Run' or Saved to the desktop and executed from there. In our testing, if we delete the msi file prior to running the application for the first time, there is no error.
During this first run, the program is downloading other required applications and dll files and initializes user data. It may also overwrite some of the existing setup files in this process.

The next time we run the program, if the msi file had been deleted, the application will not start because of the 'the feature they are trying to use is on a network resource that is unavailable' error message. It doesn't matter whether the msi had been installed in the temp folder or the desktop, if it is deleted,this message is thrown. If the msi file is not deleted, the program runs perfectly.

I re-installed from the desktop msi, then renamed the msi which caused the program to generate the error. I then had 'depends' profile the program.exe. Here are the results... The warnings seem to be areference to a windows dll dwmapi.dll.

There was an error on:DWMAPI.DLL Error opening file. The system cannot find the file specified.
However, this is not my dll but a windows library reference.

Any suggestions on how to block the msi from stopping my application from running?
As a second issue, when uninstalling the application, it removes the files originally included in the msi, but does not remove the program folder or any of the other files. How can I force it to remove the entire folder?

Thanks,
Rick

Warning: At least one delay-load dependency module was not found.

Warning: At least one module has an unresolved import due to a missing export function in a delay-load dependent module.

--------------------------------------------------------------------------------

Starting profile on 8/20/2009 at 9:30:08 PM

Operating System: Microsoft Windows XP Professional (32-bit), version 5.01.2600 Service Pack 3

Program Executable: c:\program files\company name\program name\myprogram.EXE

Program Arguments:

Starting Directory: C:\Program Files\Company Name\Program Name\

Search Path: C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\Program Files\Wave Systems Corp\Dell Preboot Manager\Access Client\v5\;C:\Program Files\ATI Technologies\ATI.ACE\;C:\WINDOWS\system32\WindowsPowerShell\v1.0;c:\Program Files\Microsoft SQL Server\90\Tools\binn\;C:\Program Files\Common Files\HP\Digital Imaging\bin;C:\Program Files\HP\Digital Imaging\bin\;C:\Program Files\HP\Digital Imaging\bin\Qt\Qt 4.3.3;

Options Selected:

Simulate ShellExecute by inserting any App Paths directories into the PATH environment variable.

Log DllMain calls for process attach and process detach messages.

Hook the process to gather more detailed dependency information.

Log LoadLibrary function calls.

Log GetProcAddress function calls.

Log debug output messages.

Automatically open and profile child processes.

--------------------------------------------------------------------------------

Started "MYPROGRAM.EXE" (process 0x1370) at address 0x00400000. Successfully hooked module.

Loaded "NTDLL.DLL" at address 0x7C900000. Successfully hooked module.

Loaded "MSCOREE.DLL" at address 0x79000000. Successfully hooked module.

Loaded "KERNEL32.DLL" at address 0x7C800000. Successfully hooked module.

DllMain(0x7C900000, DLL_PROCESS_ATTACH, 0x00000000) in "NTDLL.DLL" called.

DllMain(0x7C900000, DLL_PROCESS_ATTACH, 0x00000000) in "NTDLL.DLL" returned 1 (0x1).

DllMain(0x7C800000, DLL_PROCESS_ATTACH, 0x00000000) in "KERNEL32.DLL" called.

DllMain(0x7C800000, DLL_PROCESS_ATTACH, 0x00000000) in "KERNEL32.DLL" returned 1 (0x1).

Injected "DEPENDS.DLL" at address 0x08370000.

DllMain(0x79000000, DLL_PROCESS_ATTACH, 0x00000000) in "MSCOREE.DLL" called.

DllMain(0x08370000, DLL_PROCESS_ATTACH, 0x00000000) in "DEPENDS.DLL" called.

DllMain(0x08370000, DLL_PROCESS_ATTACH, 0x00000000) in "DEPENDS.DLL" returned 1 (0x1).

GetProcAddress(0x7C800000 [KERNEL32.DLL], "FlsAlloc") called from "MSCOREE.DLL" at address 0x79006079 and returned 0xFFBADD11.

Exited "MYPROGRAM.EXE" (process 0x1370) with code -1073740791 (0xC0000409).

Hello Rick,

>In our testing, if we delete the msi file prior to running the application for the first time, there is no error. During this first run, the program is downloading other required applications and dll files and initializes user data. It may also overwrite some of the existing setup files in this process.

It seems that it is the application itself that setup the dependency to the MSI package. To troubleshoot this issue, I would like to suggest you try the Process Monitor to monitor when the application tries to read the MSI package, and then check the call stack and detect where it tries to load the MSI package.

http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx

To troubleshoot this issue, we need the source code and the detailed steps to reproduce the problem, so that we can investigate the issue locally. It is not necessary that you send out the whole of your project. We just need a simplest sample to reproduce the problem. You can remove any confidential information or business details from it. I appreciate your work on providing these information.

Thanks,
Rong-Chun Zhang
MSDN Subscriber Support in Forum
If you have any feedback on our support, please contact msdnmg@microsoft.com

---

Please remember to mark the replies as answers if they help and unmark them if they provide no help.
Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.

Hello Rick,

I am writing to check the status of the issue on your side. Would you mind letting me know the result of the suggestions? If you have any additional question, welcome to post here.

Have a great day!

Thanks,
Rong-Chun Zhang

---

Please remember to mark the replies as answers if they help and unmark them if they provide no help.
Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.

We are changing the issue type to “General Discussion�because you have not followed up with the necessary information. If you have more time to look at the issue and provide more information, please feel free to change the issue type back to “Question�by opening the Options list at the top of the post window, and changing the type. If the issue is resolved, we will appreciate it if you can share the solution so that the answer can be found and used by other community members having similar questions.

Thank you!
Rong-Chun Zhang

---

Please remember to mark the replies as answers if they help and unmark them if they provide no help.
Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.