[First off, I'm using Windows 7, Visual Studio 2008, and this topic is in regard to C++]

I've always avoided the topic of manifest files up until now, but now I feel I'm of the level to at least understand what they do. So heres what I think they do .. :)

When compiling an application, its almost always going to need external assemblies, most definatly the windows C++ implementation, Msvc***.dll. When compiling you can choose to have your dependencies statically linked or dynamically linked. When you choose to staticaly link your project dependencies, then anything with a .lib has the code you use in that library included directly into your assembly, which means everything you need is within the .exe, no .dlls are required. If your dependencies do not happen to come in the form of a .lib, then you cant statically link them.


1. How do you choose which dependices you want to statically link and which you dont? Within visual studio I only see the option for doing this with the run time libraries, which I believe are just the Microsoft ones, not say 3rd party ones you may be using. For example, how do i say, Staticially link this, but dynamically link that?


DLLs are often updated but still stick with the same name. This creates problems for applications that were compiled with the same named dll, but that dll might have many revisions with different internal workings. This could cause a problem when an application is used on multiple machines, which may all have the same DLL, but different revisions of that DLL. Where the application may be compiled to use the newer revision of the DLL, but the machines its moved onto has an older revision, but would still try to use it as it has the same name, which may lead to the application crashing or not working.

To prevent this, applications are also shipped with a manifest file that informs the OS, of what DLLs it needs, and what revision of the DLLs it needs. If the System doesnt have the DLLS and the correct revision, then the application will fail to load. As opposed to just blindly matching DLL names.

As dlls with the same name cant exist in the same folder, this is solved by windows having an Winsxs folder that contains all the common dlls globally avalible, where dll's with the same name coexist by being in different folders, that contain the revision number as part of the folder name.

Manifests can be either built into the .exe or provided as a separate file in the same directory as the .dll


2. Whats the differences?

3. What if both are included? ( i.e. the exe has a built in manifest and a
shipped manifest file )

4. Do Dll.s have manifests to? So could the .exe have a shipped manifest, where it depends on some dll, which could also have a shipped manifest?


If you're unsure as to whether the target machine has your dependant .dll and the right revision, you can instead just ship the correct .dll. Or perform some kind of action to download it.


5. Does backwards compatibility come into it? For example, if your application ships compiled to use a newer revision of some dll, but you know it can work with older dlls, can you specify this? Or does this just overcomplicate things?

6. Does the DLL itself contain any information regarding to what revision it is or what its backwards compaitble with?