🔒 Locked

What is up with side-by-side assemblies?

Started by Drakkcon Nov 1, 2007 at 10:40 AM 4 replies 2.4k views

Original Post

Nov 1, 2007 at 10:40 AM

Okay, I've had this problem for a while, and I'm thinking of just changing programming languages all together. Here's the problem: every time I try to use Visual C++ 2005 with certain libraries (like SDL) I get this weird error that says "this application failed to start because it's configuration is incorrect" whenever I try to run my programs. The problem is related to my manifest file, which is apparently being generated wrong or something. Is it possible to just have the linker just generate a native exe file without that manifest dll or whatever? I mean, I can disable manifest generation, but then I get an error saying that "msvcrt80.dll" wasn't found, which I assume refers to the C runtimes. This wouldn't be a problem if I could just statically link them, but SDL requires that I use a multithreaded debug dll for some weird reason. Also, what on earth is side-by-side supposed to fix? I read it fixes problems with dll-hell and deployment, which are never problems I had to begin with since I only use statically linked libraries. Man, it seems like every version of visual studio just adds more crap I don't need and complicates stuff even more. . . Thanks for any explanation.

dave

Nov 1, 2007 at 10:46 AM

Is this happening with every project you create? If i get any problems i usually start a new temporary project and if that one works then compare the project properties.

BTW: Are you on a fat32 filesystem by any chance? I had manifest problems on that and there is an option called Use Fat32 workaround in the manifest properties...

Cheers,

Skizz

Nov 1, 2007 at 11:02 AM

Quote:
Original post by Drakkcon
Also, what on earth is side-by-side supposed to fix? I read it fixes problems with dll-hell and deployment, which are never problems I had to begin with since I only use statically linked libraries.

You may have statically linked the C run time libraries, but there are plenty of other libraries you will be using on Win32 that are dynamically linked: kernel, gdi, comctl32, etc. DLL hell is caused by unfriendly applications overwriting new versions of DLLs with old versions or by new versions of DLLs not being 100% backward compatible with old versions. In either case, you'll get applications that stop working. A side-by-side assembly allows multiple versions a DLL to be present in the system and the application's manifest determines which version to use. This has some really useful benefits: you don't need to be backward compatible, thus reducing code size and testing effort; you can drop unused/legacy features; you don't have to worry about breaking legacy applications. In XP, the comctl32 library is a side-by-side assembly, with the newer version providing a much richer set of controls and control properties than the standard library. The only way to use the new library is to explicitly specify the library in the manifest.

Quote:

Man, it seems like every version of visual studio just adds more crap I don't need and complicates stuff even more. . .

It wasn't VS that introduced this change, this was a change introduced in the OS to solve the DLL hell problem.

Skizz

Skizz

Nov 1, 2007 at 11:07 AM

Quote:
Original post by Drakkcon
Is it possible to just have the linker just generate a native exe file without that manifest dll or whatever? I mean, I can disable manifest generation, but then I get an error saying that "msvcrt80.dll" wasn't found, which I assume refers to the C runtimes. This wouldn't be a problem if I could just statically link them, but SDL requires that I use a multithreaded debug dll for some weird reason.

With the latest version of MSVC you need to use a manifest to tell the OS the version of the CRT to use. The "msvcrt80.dll" is a 'known assembly' which means the OS won't let anyone overwrite it by mistake and multiple versions of it can exist at the same time.

Quote:

"this application failed to start because it's configuration is incorrect"

That is possibly generated when the OS loader can't find the DLLs the application requires. Try moving the DLLs for the libraries you're using into the same folder as the application.

Skizz

Drakkcon

Nov 1, 2007 at 12:10 PM

Thanks for all the responses. I think I understand what to do now, and why side-by-side is useful. I'll try putting the dll in my application's bin folder and see what happens.

TheAdmiral

Nov 1, 2007 at 3:32 PM

The SxS system does address a real problem, but it doesn't do it very well. This has caused a lot of people a lot of trouble. While a large project with a predicted long lifespan should take advantage of SxS, it is not always feasible for distributors of small or one-off applications to lug around the bulky VS redistributable and manifest files, and MS should have given developers the option of linking in such a way as to avoid the trouble.

Well, although it probably wasn't their intention, they did give the developer that option, it just isn't documented as a solution. What most of us are doing is taking advantage of the SxS system's immaturity and instead telling our projects to link against the static multithreaded libraries (Properties | Configuration Properties | C++ | Code Generation | Runtime Library | Multi-threaded). As much as this is a hack (and inadvisable for large-scale distributions), it side-steps the SxS problem altogether - producing a predictable-dependency exe - and saves all us a few headaches in the process.

Admiral

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.