I really cannot see what is so great about this manifest file in XML. Hav,nt you heard of INI files which were just plain text config files and were searched for in the App path, windows dir and then the default path. They too were the same name as the app except with an ini extension.
Other than the INI becoming XML what has changed? MS COM dictated that entries were made in the registry. MS could just as easily have dictated that COM look in INI files or Manifest files or whatever, like they do now with "Managed" code.
The reason (I suppose) the registry was chosen was because it was one place that was guaranteed to be there on every Windows computer.
So if not the registry, how then does any application know where to look for the XML file?
If NET is to substitute COM can someone explain how an external app knows where the XML mainfest is located on a particular computer?
For instance in COM when I ISSUE Createobject Windows looks in the registry and gets the location of the COM app. But in NET doing something similar, how does windows know where to look for this manifest?
>>
>Christian pointed out in message #
1012012 that XP SP2 and Windows 2003 Server both support the ability to create XML manifest files that contain registry information for the components your application is using. In brief, these newer versions of Windows look for registry entries in an XML file with the same name as the running app FIRST and if this file is not present (or if its present but doesn't contain the requested entries), THEN Windows looks in the registry.
>
In the old DOS days, there never was DLL hell because, all needed files were stored in a single directory structure that acted like a manifest. There was no registry of course. Installation was just a simple COPY and then a config for hardware and software settings.
So what's new? Manifests look like rebadged INI files.
>This is COOL because it gives one a safe and seamless way to distribute COM and ActiveX components without needing to update the registry.
>
>Malcolm
