TIP: Make sure your required DLL's are in the right place to avoid validation failure

BrianDevArch

Mon, 04/19/2010 - 15:20

This may seem like a no brainer, but with the recent change in validation on how MSI Installation it may get you too. I have to admit that this one got me. I received one of the emails today with the following subject: "Urgent: Please read-Changes to your Atom application are requested" Let's say you have App.exe and RequiredLibrary.dll. When the shortcut to App.exe has a startup path that contains the two files all works well. Now what happens if the startup path changes in your link? Your App.exe will be executed, then fail because it has no idea where to find RequiredLibrary.dll. * The App Store can do just this using MSI parameters during install, the target and start-up paths may differ from what you expect. Any or all of the fixes may apply to your project: 1.) Place your DLL's in the appropriate folder (example c:\windows\system\) 2.) Register your DLL's (COM) if needed 3.) Install your DLL's into the GAC (Global Assembly Cache) * Note: Do not forget to add a strong named key Best of luck! Update: ww8520 has found a great solution to problems with GetModuleFileName: "GetModuleFileName( NULL, strExePath, MAX_PATH ) is getting the path of the executable file of the current process. See http://msdn.microsoft.com/en-us/library/ms683197%28VS.85%29.aspx. " http://appdeveloper.intel.com/en-us/node/1102#comment-3224

12 posts / 0 new

Last post

For more complete information about compiler optimizations, see our Optimization Notice.

pinigames

Mon, 01/17/2011 - 23:34

For dynamically linked DLLS we can use GetModuleFileName etc. But for statically linked DLLs we must follow the rules as Brian suggested. But is it a good idea to place any custom DLL in windows\system folder? e.g. if we make a DLL which is usable by only our application,should we place it in windows folder? Any other working solution?

BrianDevArch

Tue, 01/18/2011 - 07:22

pinigames,

You could use any path specified in the PATH environmental variable. Taking that one step further, your installer could add a new path which would allow you to select your default install path.

pinigames

Wed, 01/26/2011 - 07:00

I think the bug is fixed as I can see many apps (including My Little Artist) using statically linked DLLs and placing them in the same folder as that of main executable, and not modifying the PATH environmental variable.
I can also see filled "Start in" path in their shortcuts. Was this the problem?
Can I get an official answer from validation team?
The question is: Does the AppUp client now starts app from the app's folder? In other words does it sets the working directory to the EXE path?

pinigames

Fri, 01/28/2011 - 04:26

While I am still waiting for official answer, here is the solution I recommend for statically linked DLLs.

Use "Delay load Import" to delay DLL loading, and the first task of you app should be setting working directory with the help of

SetCurrentDirectory and GetModuleFileName.

How to delay DLL loading:

http://msdn.microsoft.com/en-us/library/yx9zd12s(v=VS.80).aspx

Dinesh S

Wed, 03/10/2010 - 20:53

Many thanks Brian... Maybe it'll remove my bug

Dinesh S

Thu, 01/07/2010 - 20:36

Thanks Brian for your suggestion.

It'll help many people here.

BrianDevArch

Fri, 05/14/2010 - 10:23

Dinesh,

I am just following up to see that this resolved the issue. Is everything running smoothly now?

MarcT

Tue, 01/12/2010 - 11:30

I'd like some more details on what the AppStore is doing here. Are they simply setting the "Start In" field of the App shortcut? Or are they actually moving the exe to a different folder before running it? Because we depend on our Application Directory for more than just dll linking. We load content folders and open files using the directory returned from GetModuleFileName(NULL).

BrianDevArch

Tue, 01/12/2010 - 11:40

Marc,

Currently it is just the Startup Path and Target properties that they are modifying. They are currently installing into the paths you specify in your MSI.

The MSI standard (http://en.wikipedia.org/wiki/Windows_Installer) accepts parameters to allow override the installation path. This functionality may be utilized in the future, since we are still in a beta stage many aspectsd of this process are under development.

Given that it may happen and your solution depends upon knowing the installation path I would suggest you utilize the registry or another means to keep track of where your MSI is deployed to. I am happy to write up an example of how to do this using a Visual Studio 2008 Package and Deployment project.

MarcT

Tue, 01/12/2010 - 12:22

Thanx, Brian, you're most helpful. We're using a different installer package, and writing the path to the registry isn't hard. We're actually fine if they change the install directory for the whole application, but your post makes it sound like they may put some files (i.e. the exe) in one directory, and the rest somewhere else. In that case, a registry key won't help. Maybe I'm misunderstanding the issue?

As long as our exe is installed in the same folder as our Content directory, and GetModuleFileName(NULL) returns that folder, we'll be fine. Can Intel guarantee that?

BrianDevArch

Tue, 01/12/2010 - 12:29

Marc,

You are quite welcome.

They would not separate individual files from within your MSI into different paths. In my description above, I was giving advice on place you could place shared libraries to overcome the Startup Path vs Target differences seen in the shortcuts.

From your description, it does not sound like the issue above will pose a problem for you.

Back to original post

Intel® Developer Zone

TIP: Make sure your required DLL's are in the right place to avoid validation failure

TIP: Make sure your required DLL's are in the right place to avoid validation failure

Login to leave a comment.