Hi everybody, I'm going to tell you about a problem I encountred while trying to distribute my application. I've started working on a project with SDL some time ago, using VC 2008 SP1, and when I try to run the compiled program on a different computer which doesn't have VS installed, it doesn't work, giving me the error message "this application failed to start because the application configuration is incorrect", this was because I didn't installed the VC 2008 runtime. When I install it, it works perfecly. But I didn't wanted to have an installer for a small application, that would be somewhat heavy and not encouraging.. so I thought I would just copy the required files in the application folder. I found out using "Dependency Walker", that I needed MSVCR90.dll and SDL.dll. And even if the application was already compiled in the release version, this solution haven't worked. So I started looking in different forums and websites for a possible solution, and there was no success, I found a thread here that's dealing with the same problem but it didn't resolve it for me either, I tried to reply there but it was already closed, so with despair I thought I'll just include the redistributable package with every application, which I didn't like... By chance, I tried to look at the resources of the application, with 'resource hacker', there was a manifest where I found some information about dependencies, here's that part of it: <dependency> <dependentAssembly> <assemblyIdentity type="win32" name="Microsoft.VC90.CRT" version="9.0.21022.8" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity> </dependentAssembly> </dependency> when I saw this I thought I'd check the manifest file that's with the dlls in VC/redist folder, and then I found that there was a little difference, here's how it looked: filename: Microsoft.VC90.CRT.manifest <assemblyIdentity type="win32" name="Microsoft.VC90.CRT" version="9.0.30729.1" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity> if you look carefully you'll find that the version is different in the two manifest files. in the manifest with my program it's stated version="9.0.21022.8" and in the DLLs it's "9.0.30729.1". The simplest solution is to look for the DLLs having the same version as the one from your program that way you have the exact required version of the DLL(you can look for them, they are in Windows/WinSxS folder). Then all you have to do is to redistribute the program .exe file, the manifest file and the dll (note that if you use MFC, ATL .. you'll have to put their manifest and dll too with the program) and your program is going to work. Another solution to this is to try to build the application and ask VC to bind the latest build of the DLLs, the SP1 ones, with your program. This process is a little delicate, because you'll have to check all statically linked libraries to see which version do they require, because if they require an older version, even if you change your own project to bind the latest ones, the manifest file will include the oldest required version by your project and it's dependencies. this process is described in detail in this page, I suggest you to take a look at it. If you binded the latest Dlls with your project as described in that page, all you have to do next is to put the manifest file and the Dll required by your executable. For example: using 'dependency walker', I checked my program and I found that it needs SDL.dll and Msvcr90.dll, I went to the folder Microsoft Visual Studio 9.0\VC\redist\x86\Microsoft.VC90.CRT and I copied the manifest and the Msvcr90.dll, I checked again the manifest file to see if it's the right version, and if everything was okay those four files ca be distributed : the executable, SDL.dll, the manifest file and Msvcr90.dll. that's all to it. I hope I helped those unlucky dudes who are trapped in this devil SP1 trap :p Microsoft guys should just make VC SP1 make projects to include the latest DLLs, and not make us go crazy looking for a way to distribute our apps with the wrong files... and..Sorry if I made this a little long :p Thanks for your attention anyway ^^ ;)

What you are doing is:
a) Against the EULA of the Microsoft Runtime libraries
b) Extremely stupid
c) Asking for trouble

First of all, Microsoft FORBIDS you to distribute the Visual C runtimes yourself. This is in the EULA of it, and by using Visual Studio and linking to the runtimes, you are breaking their rules. There is a reason for this, because by distributing the runtimes yourself, you're going to set up the end-user's computer for failure.

Microsoft introduced the side-by-side DLL cache for this. All the specific versions of a DLL are kept in there in case a DLL isn't backward compatible with a previous version. By distributing your own copies, you might polute this system, and cause the end-user's OS to break, or more specifically, break with certain applications build against certain DLLs.

And no, why should each application distribute it's own runtime DLLs? They made installers for a reason, Microsoft already offers users to download and install the runtimes with a breeze.

And of course, not to mention you're going to have to give the user support on this, because you're breaking standard guideline rules for this. While previously you could have a massive warning on your site bout this, now you actually have to do debuggin yourself for each user.

Toolmaker

This is not specific to SP1, but affects all versions of VS2008, and also VS2005 too, if I remember.

It's going to change in VS2010, though: In Visual C++ 10, you can simply put the runtime DLLs in the application directory and it works.

As the program manager lead in Microsoft Boris Jabes said at PDC:"This is a little sin we introduced in Visual Studio 2005 and perpetrated in Visual Studio 2008", (thanks Codeka for the article!) We can see that it was just Microsoft's poor software design again, their solution to include side-by-side DLL cache is good when talking about big projects, but when you want to make a small utility or anything that doesn't require an installation then you can't run it on a computer as a stand-alone, with no extra runtimes...
What do you think Toolmaker? what's the solution to this? How can I handle some of my non-geek friends who just don't know what a runtime is? even worse when you don't have that VC redist, you get a vague error message telling you that the application configuration is not correct how's that supposed to help the end-user?
and how is my application going to break the end user's OS if I don't change any system files? My program needs a DLL, I put this DLL beside it, and nothing's going to break. Please tell me if i'm wrong..

Regards
Charnet3D

Quote:Original post by Antheus
It'll bloat your exe, but should avoid the dependency problems.

It'll bloat the exe, but if you're going to include the DLLs in your .zip anyway, it'll actually make the whole distribution smaller.

It's not a bad design on Microsoft's part, it's just a matter of managing trade-offs. The problem with having application-private versions of the DLLs is that if a security vulnerability is found in Microsoft's runtime, they have to go spelunking in every application's install directory if they want to update the DLL (or worse, they have to wait for the vendor of the application itself to update). This is the lesson they learned from that GDI+ JPEG vulnerability.

Quote:Original post by charnet3d
when you want to make a small utility or anything that doesn't require an installation then you can't run it on a computer as a stand-alone, with no extra runtimes...

Isn't static linking to the runtime the answer to that?

Also, I think Microsoft actually should distribute the runtimes immediatly upon release. That might save users a lot of hassle.

But then again, most applications do in fact require an installer. And besides, why not link your friends to the redist, tell them to install it and then give them your application? It's a one time process...

Toolmaker

I tried linking statically, it was such a painful process (I had to recompile all the libraries I use: SDL, SDL_image, SDL_gfx...) and finally I'm having an exe file that doesn't have any dependencies to the runtime Dlls.. and of course the program worked in the virtual machine like a charm!
Thanks to you all for your great help.. ;)

Quote:Original post by Toolmaker

I think Microsoft actually should distribute the runtimes immediatly upon release. That might save users a lot of hassle.

I don't understand, What do you mean with that?

Quote:Original post by Toolmaker
why not link your friends to the redist, tell them to install it and then give them your application? It's a one time process...

I'm with you in this point, I think this is the best solution. The end-user will have the runtime installed definitly and any application that needs it in the futur will find it. But when talking about small applications, as I just realised, static linking is the right solution, that way you have a real distributable application - no installation required.