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

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. " node/1102
13 帖子 / 0 全新
最新文章
如需更全面地了解编译器优化,请参阅优化注意事项

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?

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.

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?

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

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

Thanks Brian for your suggestion.

It'll help many people here.

Dinesh,

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

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).

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.

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?

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.

Thanx a lot Mr.Brain,Quite informative. I want to know , How our files can be protected and installed in programme folder, I have made MSI, Which is having one dat file and exe. I want to give Read only permission for my dat file and exe after installation, i am using Advanced Installer, Please help me in this regard.

Chief Executive Officer

发表评论

登录添加评论。还不是成员?立即加入