The title says it all: What exactly is a manifest file for? does it link to other files? I suspect it might, since I have been developing an app using the SDK sample customUI. I thought this might have a link to a texture file in the SDK because the customUI is obviously referencing different areas of a texture somewhere, but its not in the project folder, for the buttons etc.... However, opening the manifest file in wordpad just shows a dependency on common controls, i think.... If this is the case,, where does the texture come from? very puzzling! Thanks Simon

A manifest file is an XML formated file that essentially serves as a runtime configuration to determine (among other things) which libraries and files a program should use.


Their main purpose is for SxS (side by side) installations.

They are also yet another attempt to avoid "DLL Hell." Unfortunately it can make the problem worse for non-geeks thanks to the implementation details. Also, it can prevent old applications from using newer functionality even when there would be no problem in doing so.

Example (somewhat unrealistic) case of how manifest files are useful:

Quote:I, frob, start a major company, Frob's Obscure Objects Incorporated (FOO). The people at FOO have a huge inventory system to track the billions of obscure objects moving through our inventory every day. The developers love the "Release early, release often" mentality, so all of our tools are run directly from the network.

The IT team has written inventory tracking code for our workstations (32-bit Windows), new servers (64-bit Windows), old servers (64-bit Windows for Alpha), and several handheld scanners we use (MIPS and ARM) running several different versions of Windows CE. [Okay, it's contrived, but bear with me.]

We have 5 different hardware architectures to support, and several different versions of windows.

Since the people using the program are either high school dropouts or illigal immigrants, it has to be stupid-proof. [Oh, and the app has been localized for 15 different languages to support the immigrants.]

These people are taught that to run the program at \\Apps\FOO

We can create a single .net front-end executable (\\Apps\FOO.exe) that all the target platforms can run. The front end has calls to a set of assemblies. The manifest files state which set of files to use for the architecture. When the development team wants to support some new version of hardware (perhaps an ARMv5 optimized version), they don't have to rebuild everything. They can just add the new assembly files, modify a manifest or two, and be done.

It's a solution that most people will never face. Many developers and comentators feel it is a solution waiting for a problem. A few people at really big companies (like the FOO Inc. above) somewhat like the solution of manifests.

Hope that helps.

frob.

Quote:Original post by iMalc
Typical usage these days is largely to make a program have the new xp control styles from the newer comctrl dll or whatever it's called.
Without one, you get the old square-edged Windows95 style buttons in your app.

It doesn't even have to actually be compiled into your app either. You can simply put one in the same directory as your app, with the correct name, for the same effect.

True enough. And that's a source of criticisim for intentionally not using the visual styles. But I didn't want to get in to that.

Still, it goes back to the reasons for manifest files in their SxS design.

* Developers can state specific library versions that have been tested
* Administrators can override it and use new, or different, libraries
* Default settings basically match old Windows behaviors


The whole Windows XP visual styles just copmlement those three points. Leave it out, and the app will feel like the W2K or Win98 counterparts. Add the common controls 6.0 to the manifest file if you know the app will support it --- many old apps would skin their own controls which could break the new common controls.

frob.