Prev: Resource Leak
Next: Questions about vcredist_x86.exe, (VS2008 redist).
From: David Webber on 25 May 2010 18:33
I remember struggling to deploy a VS 2008 program, with MFC and CRT DLLs in
the program's own folder (until I got help here with what to put in the
manifest).

I had heard a rumour, and the help system *seems* to confirm it, that the
manifest is no longer necessary for this with VS 2010. The program will
find the DLLs if they're in its own folder, even if there is no manifest.
Just like in the old days! Can this be correct or am I dreaming?

Dave
--
David Webber
Mozart Music Software
http://www.mozart.co.uk
For discussion and support see
http://www.mozart.co.uk/mozartists/mailinglist.htm

From: David Ching on 25 May 2010 18:46
"David Webber" <dave(a)musical-dot-demon-dot-co.uk> wrote in message
news:u1u7ZpF$KHA.348(a)TK2MSFTNGP06.phx.gbl...
> I had heard a rumour, and the help system *seems* to confirm it, that the
> manifest is no longer necessary for this with VS 2010. The program will
> find the DLLs if they're in its own folder, even if there is no manifest.
> Just like in the old days! Can this be correct or am I dreaming?
>

Yup, for the VS 2010 DLL's, manifest hell is gone, and we are back to DLL
hell. But for app local deployment, the DLL's in the program's folder will
be used. This is not always a good thing; for one, updated service releases
will be ignored.

-- David

From: Tom Serface on 25 May 2010 18:59
I think DLL hell is slightly better than Manifest hell, but I guess that
remains to be seen. They may have been better off just beefing up the error
message that came up for an out of version runtime (the message that popped
up was pretty dumb). At least we have more control over what is distributed
and we can put the DLLs in our own folder like the old days.

Tom

"David Ching" <dc(a)remove-this.dcsoft.com> wrote in message
news:#tMohwF$KHA.3880(a)TK2MSFTNGP04.phx.gbl...
> "David Webber" <dave(a)musical-dot-demon-dot-co.uk> wrote in message
> news:u1u7ZpF$KHA.348(a)TK2MSFTNGP06.phx.gbl...
>> I had heard a rumour, and the help system *seems* to confirm it, that the
>> manifest is no longer necessary for this with VS 2010. The program will
>> find the DLLs if they're in its own folder, even if there is no manifest.
>> Just like in the old days! Can this be correct or am I dreaming?
>>
>
> Yup, for the VS 2010 DLL's, manifest hell is gone, and we are back to DLL
> hell. But for app local deployment, the DLL's in the program's folder
> will be used. This is not always a good thing; for one, updated service
> releases will be ignored.
>
> -- David

From: David Ching on 25 May 2010 20:02
"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: Liviu on 25 May 2010 21:12
"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



 |  Next  |  Last
Pages: 1 2 3 4 5
Prev: Resource Leak
Next: Questions about vcredist_x86.exe, (VS2008 redist).