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.

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,

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

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

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.