Manifest Hell - a thing of the past?
in [MFC]
|
From: Hector Santos on 25 May 2010 21:36 Liviu wrote: > "David Ching" <dc(a)remove-this.dcsoft.com> wrote... >> "Tom Serface" <tom(a)camaswood.com> wrote... >> >>> At least we have more control over what is distributed and we can >>> put the DLLs in our own folder like the old days. >> Actually DLL hell gives us *less* control as the manifests let us >> specify precisely which versions of the Microsoft DLL's we wanted >> to be loaded into our processes. DLL hell is easier because we can't >> specify any of that anymore (like automatic transmission). But we >> have no recourse if it's wrong. > > I'll disagree with the "less control" part, on grounds that DLL hell > will at least start the app (except for borderline exotic cases), thus > giving it a chance to check the versions of the loaded modules and > decide on the appropriate course of action in case of mismatches, > be that a warning, auto-repair, or immediate shutdown. The manifest > hell on the other hand always chooses the latter with no recourse. > > Liviu +1, unless you are "master" in understanding manifest, and that means using them, you can get really lost just trying to get applications running probably without extensive debugging and tracing and not even that will help sometimes, unless you know what you doing. The old school way - UNDERSTANDING basic DLL loading - in my view is far easier and less distruptive. But again, it might have been a matter of just understanding what the hell it was doing. Here is something I just did the other day where I think "Manifest" saved the day. Compiling under VS2005, I was exploring a new API function that according to the MSDN docs, its only comes in the 2008/VISTA Platform SDK. I have the 2008/VISTA SDK installed. The only way I was able to RUN it was with the manifest. I had to use the COMMAND SHELL for the 2008/VISTA and not the others which allowed it to compile but not run. I forget the exact issue because I WAS LOST with it. I have all kinds of command shells and in some I don't use the manifest. That might of been the problem. But I think in this case, the MANIFEST allowed me to use a 2008/VISTA API on a non 2008/VISTA machine. I don't the details of it. But I guess that is good - in this case. Not sure I would like this in general. Either the dependencies are resolved as you understand it or not. No Confusion with Manifest vs OS v SxS or whatever is desired. -- HLS
From: Tom Serface on 26 May 2010 01:02 Well, good points. Kind of can't win either way :o) Tom "David Ching" <dc(a)remove-this.dcsoft.com> wrote in message news:15B80129-2E82-4B79-A50E-D56DAEFFB345(a)microsoft.com... > "Tom Serface" <tom(a)camaswood.com> wrote in message > news:Oh0393F$KHA.980(a)TK2MSFTNGP04.phx.gbl... >> At least we have more control over what is distributed and we can put the >> DLLs in our own folder like the old days. >> > > Actually DLL hell gives us *less* control as the manifests let us specify > precisely which versions of the Microsoft DLL's we wanted to be loaded > into our processes. DLL hell is easier because we can't specify any of > that anymore (like automatic transmission). But we have no recourse if > it's wrong. > > -- David
From: Tom Serface on 26 May 2010 01:03 I usually just open the EXE using Notepad to check the manifest information (text) that is buried in there. I wish the OS was smart enough to display a decent error message when the versions were wrong. Tom "Hector Santos" <sant9442(a)nospam.gmail.com> wrote in message news:OgWhkPH$KHA.4316(a)TK2MSFTNGP04.phx.gbl... > Liviu wrote: > >> "David Ching" <dc(a)remove-this.dcsoft.com> wrote... >>> "Tom Serface" <tom(a)camaswood.com> wrote... >>> >>>> At least we have more control over what is distributed and we can >>>> put the DLLs in our own folder like the old days. >>> Actually DLL hell gives us *less* control as the manifests let us >>> specify precisely which versions of the Microsoft DLL's we wanted >>> to be loaded into our processes. DLL hell is easier because we can't >>> specify any of that anymore (like automatic transmission). But we >>> have no recourse if it's wrong. >> >> I'll disagree with the "less control" part, on grounds that DLL hell >> will at least start the app (except for borderline exotic cases), thus >> giving it a chance to check the versions of the loaded modules and >> decide on the appropriate course of action in case of mismatches, >> be that a warning, auto-repair, or immediate shutdown. The manifest >> hell on the other hand always chooses the latter with no recourse. >> >> Liviu > > +1, unless you are "master" in understanding manifest, and that means > using them, you can get really lost just trying to get applications > running probably without extensive debugging and tracing and not even that > will help sometimes, unless you know what you doing. > > The old school way - UNDERSTANDING basic DLL loading - in my view is far > easier and less distruptive. > > But again, it might have been a matter of just understanding what the hell > it was doing. > > Here is something I just did the other day where I think "Manifest" saved > the day. > > Compiling under VS2005, I was exploring a new API function that according > to the MSDN docs, its only comes in the 2008/VISTA Platform SDK. I have > the 2008/VISTA SDK installed. The only way I was able to RUN it was with > the manifest. I had to use the COMMAND SHELL for the 2008/VISTA and not > the others which allowed it to compile but not run. > I forget the exact issue because I WAS LOST with it. I have all kinds of > command shells and in some I don't use the manifest. That might of been > the problem. But I think in this case, the MANIFEST allowed me to use a > 2008/VISTA API on a non 2008/VISTA machine. I don't the details of it. > But I guess that is good - in this case. Not sure I would like this in > general. Either the dependencies are resolved as you understand it or not. > No Confusion with Manifest vs OS v SxS or whatever is desired. > > -- > HLS
From: David Ching on 26 May 2010 01:09 "Liviu" <lab2k1(a)gmail.c0m> wrote in message news:exIVQCH$KHA.1888(a)TK2MSFTNGP05.phx.gbl... > I'll disagree with the "less control" part, on grounds that DLL hell > will at least start the app (except for borderline exotic cases), thus > giving it a chance to check the versions of the loaded modules and > decide on the appropriate course of action in case of mismatches, > be that a warning, auto-repair, or immediate shutdown. The manifest > hell on the other hand always chooses the latter with no recourse. > Isn't that the purpose of the manifest? To specify exactly which DLL versions are required and fail if they are not there? And why wouldn't they be there? Only if your installer didn't do it right or your build was messed up. I've never heard of anyone doing a version check from within their app once it was started up. I can't believe anyone would ever do that. Anyway, Microsoft has chosen for us, for better or worse. I think they also got fed up with people not being able to get manifests working well, and they exacerbated the problem by issuing all manner of ATL Security updates that broke everyone without even doing the courtesy of telling developers if they rebuilt after their Visual Studio was patched, it would really screw it up. Frankly, I don't think they trusted even themselves to do the right thing, so they disabled the manifests. -- David
From: David Ching on 26 May 2010 01:16 "Hector Santos" <sant9442(a)nospam.gmail.com> wrote in message news:OgWhkPH$KHA.4316(a)TK2MSFTNGP04.phx.gbl... > +1, unless you are "master" in understanding manifest, and that means > using them, you can get really lost just trying to get applications > running probably without extensive debugging and tracing and not even that > will help sometimes, unless you know what you doing. > What does it mean to "master" manifests? It doesn't require (much) more than mastering DLL versioning. If you don't understand either, you don't deserve to be using DLL's period, you should be static linking and that's all there is to it. > The old school way - UNDERSTANDING basic DLL loading - in my view is far > easier and less distruptive. > I dare say understanding basic DLL loading is as misunderstood as manifests. Win9x looked in different paths for DLL's than WinNT, for example. Bottom line is people think loading DLL's should be as automatic as loading EXE's, it should just work, and they are unwilling to put forth any thought process to make it foolproof. DLL Hell "works" more often than manifests, and people would rather bury their heads in the sand even though it yields subtle problems like unresolved externals in the DLL or bad behavior due to breaking changes of using the wrong manifest, in addition you are at the mercy of whatever Joe Blow's installer was run last that installed who knows what version of the DLL! But I am glad at least for app local deployments, the basic rule that your local DLL will always be the one used for your app still rules supreme no matter for manifests or not. I stick to app local deployment, or static linking. -- David
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 4 5 Prev: Resource Leak Next: Questions about vcredist_x86.exe, (VS2008 redist). |