Catalin Stavaru

Hello,

As far as I can see, most of the blog topics on this subject written by the Visual C++ team are "ideal world" topics, but I really need some real-world answers on this subject.

1. For example, I had my app compiled with Visual C++ 2005 and distributed it using MFC and CRT 8.0 in the app's directory. This worked fine (of course, I had to use the manifests from the WinSxs folder instead of the ones from Redist folder which did not work), until I have upgraded to Visual C++ 2005 SP1. I have rebuilt all binaries, replaced the CRT and MFC with the new ones (8.0.50727.762) and now I receive the ERROR_SXS_VERSION_CONFLICT in the event log, and nothing works. Why could this be I have studied the binaries with an editor and the embedded manifest is the new one supplied in the redist folder, with no other references to other versions of the libraries in it. Why could this happen Could it be that I link with  3-rd party dlls linked dynamically with other versions of MSVCR80 Shouldn't this scenario work flawlessly

The in-application-folder deployment of VC++ libraries no longer seems to work (at least on computers having other versions of the libraries in the WinSxS folder).

2. So, I have used the merge modules provided. This works, but not on all computers. Look what the error in the event log from a customer looks like: "Error generating activation context for C:\Windows\WinSxS\x86_Microsoft_VC80_MFC_1fc8b3b9a1e18e3b_8.0.50727.762_x-ww_3bf8fa05\MFC80U.DLL. Reference error message: The operation completed successfully".

After a year of deployment using Visual Studio 2005 (and I am no novice) I honestly think that trying to avoid the dll hell, you have just set the basis for an even bigger dll hell.

My suggestions for the Visual C++ libraries team:

1. Give very explanatory messages in the event log. What exactly went wrong What is mismatched exactly "Error generating activation context" is the most useless message you could give.

2. Be more active on the forums until the problems are solved and no one is complaining anymore. In my opinion, there are clearly issues with the SXS deployment of VC++ libraries ( in addition to in-application-folder deployment ).

 

 




Re: Visual C++ General Need real answers regarding deployment of VC++ Libraries

Holger Grund

You may want to a take a look at this thread http://groups.google.co.uk/group/microsoft.public.dotnet.languages.vc/browse_frm/thread/f6c95ff8892cccc9/cd573bcee59fd30

I'd suggest to activate NTLDR snaps for your exe, run it in the debugger and see if there's a useful hint on what's going on. If you can install with elevated privileges you might be able to install the publisher manifest (if that exists at all - still haven't downloaded SP1 yet).

FWIW, I do agree neither SxS nor how VC uses it, are aequately documented.

-hg





Re: Visual C++ General Need real answers regarding deployment of VC++ Libraries

Catalin Stavaru

Thank you.

Indeed, in the Google post there was a problem with 3rd party dll's. In my case, there is also this problem (I am using a 3rd party dll linked against the RTM version of CRT), but I can't figure out why it doesn't work since I have both CRT versions correctly installed on the target machine. This is the whole point of side-by-side, right

I think that you cannot have two different versions of the 8.0 CRT dlls loaded into the same process. Can somebody confirm this

If it's true, this means that I can no longer distribute commercial libraries linked dynamically with CRT 8.0, because there is no guarantee that customers will link their programs against the same version of the CRT.

 






Re: Visual C++ General Need real answers regarding deployment of VC++ Libraries

Holger Grund

One point of SxS is indeed, that you can have two different versions of the same assembly loaded into a process. But it might be a bit different for the CRT. I don't think you should expect to able to allocate an array via new from one VC version of the CRT and delete it from code with a different activation context bound to another CRT. Same goes for construction/destruction order, installed CRT callbacks etc. . But that really seems to be a runtime issue only.

The CRT code itself goes to great length to force you into using the correct manifest. Maybe it's one of its own checks (which are run after the OS binding process) which goes wrong - doesn't sound very likely with the error message you're seeing - but anyway.

Have you tried the workarounds I suggested I.e. install a publisher manifest for the CRT (which I presume exists and is installed as part of SP1) or wrap the third-party DLLs in assembly (via an external assembly manifest) and redirect the binding via an application manifest.

Again gflags.exe and "Show NTLDR loader snaps" might produce some useful information.

-hg





Re: Visual C++ General Need real answers regarding deployment of VC++ Libraries

Ted.

if you have other stuff still linking to the old libs, then another solution is _USE_RTM_VERSION (search for it on google)



Re: Visual C++ General Need real answers regarding deployment of VC++ Libraries

Catalin Stavaru

Hi,

Of course I do not expect to mix the heap managers and such. I have always regarded allocating objects in one logical module and directly deallocating them in another module as a design error, I always follow this rule.

I have always had the manifest provided with SP1 in the application's folder along with the VC dlls.

I will try your other suggestions, thank you. For now I managed to get a recompiled 3-rd party dll and used the merge modules provided with SP1, but there are still problems on some customers computers.

I suspect that a previously installed application can screw up the WinSxS configuration for the VC++ libraries (in fact for any side-by-side assemblies) by installing wrong manifests, wrong policy files, etc. Then even if my installation is supposedly ok, the application will still not work. I can't explain otherwise why the application works on most systems but not on some.






Re: Visual C++ General Need real answers regarding deployment of VC++ Libraries

Catalin Stavaru

Ted. wrote:
if you have other stuff still linking to the old libs, then another solution is _USE_RTM_VERSION (search for it on google)

Thank you for this useful tip, good to know :)