How to deploy private Assemblies with VC2005 SP1

[Joerg Toellner]

Dear Group,

i develop an app with MSVC++ 2005 pro. My app should not use any
installation. It's only a "packing out the zip and run it"-installation.

So i use private assemblies with manifests and DLLs in the app directory
itself.

All works fine with MSVC2005 Pro PRE SP1. I packed into my app-zip also the
Microsoft.VC80.CRT.manifest file and the redist-dll msvcr80.dll (i got them
from C:\Programme\Microsoft Visual Studio
8\VC\redist\x86\Microsoft.VC80.CRT\) and my app runs out of the box even if
the target pc has not installed any MSVC or sth. like that.

This week i installed the SP1 final for MSVC2005. And after that i cannot
deploy any program compiled with that SP1-updated compiler with private
assemblies anymore.

The app runs well on pc's which have MSVC installed. But on "clean" pcs the
app won't start and display an "component is missing. Re-install the
application" error dialog.

depends.exe, on the target machine, reports only "There were problems while
loading the application" but there are no errors (red lines, missing files
or whatever) in the log.

I checked the versioning of the CRT DLL and the versionnumbers in the
manifests (the CRT Manifest and the app embedded manifest), but can't figure
out whats going wrong there. Of course i use the new installed SP1 CRT-DLL
with version number 8.0.50727.762. And this number is also in the manifests.

Linking statically the CRT is not an option as i have to use third party
libs as well, that are build in /MD compiler mode and cant be rebuild in
/MT. And mixing up /MD and /MT compiles end up in a error hell (undefined
externals). The app, compiled with the pre SP1 version of MSVC uses this
libs also, and this libs havent changed in between. So the error hasn't
anything to do with this libs.

My question is, which dlls and manifests with wich version numbers i have to
ship together with my application so that a MSVC++ SP1 compiled app would
run with private assemblies in the local app directory.

Any hint appreciated. TIA very much!
Joerg

 

[Holger Grund]

This week i installed the SP1 final for MSVC2005. And after that i cannot
deploy any program compiled with that SP1-updated compiler with private
assemblies anymore.

The app runs well on pc's which have MSVC installed. But on "clean" pcs
the app won't start and display an "component is missing. Re-install the
application" error dialog.
[..]

I checked the versioning of the CRT DLL and the versionnumbers in the
manifests (the CRT Manifest and the app embedded manifest), but can't
figure out whats going wrong there. Of course i use the new installed SP1
CRT-DLL with version number 8.0.50727.762. And this number is also in the
manifests.

Linking statically the CRT is not an option as i have to use third party
libs as well, that are build in /MD compiler mode and cant be rebuild in
/MT. And mixing up /MD and /MT compiles end up in a error hell (undefined
externals). The app, compiled with the pre SP1 version of MSVC uses this
libs also, and this libs havent changed in between. So the error hasn't
anything to do with this libs.

What's in the manifests of these third-party DLLs? I guess they still bind
against
the RTM DLLs. I guess, there shouldn't be any binary incompatibilities
between
the RTM and SP1 DLLs, so it should just work with the new DLLs. To
redirect the binding to the new SP1 DLLs you would typically use a
configuration file. I take it, VC8 SP1 installs a publisher configuration (I
haven't
taken a look at SP1 one yet).

I have never needed to do anything like that but I believe you would
probably
need an application configuration and redirect to the SP1 one version. I am
not sure, however, whether that works from the EXE or whether you have
to make the third-party DLL a private assembly (by providing an external
assembly manifest) and redirect the DLL binding there.

From the docs I read a while ago, I'd say the latter is the way to go - but
then
the documentation certainly isn't exactly exhaustive.

-hg

 

[Joerg Toellner]

Hi Group,

To keep you up-to-date and for later searching when others have a similar
problem.

Holger was right....recompiling all the third party libs and dlls solved the
problem. After that i can ship the CRT and the manifest with my app in the
appdir again and the app runs without any prerequisites on the target
machine.

Thanks to all for reading and Holger for solving my problem.

CU all
Joerg

This week i installed the SP1 final for MSVC2005. And after that i cannot
deploy any program compiled with that SP1-updated compiler with private
assemblies anymore.

The app runs well on pc's which have MSVC installed. But on "clean" pcs
the app won't start and display an "component is missing. Re-install the
application" error dialog.
[..]

I checked the versioning of the CRT DLL and the versionnumbers in the
manifests (the CRT Manifest and the app embedded manifest), but can't
figure out whats going wrong there. Of course i use the new installed SP1
CRT-DLL with version number 8.0.50727.762. And this number is also in the
manifests.

Linking statically the CRT is not an option as i have to use third party
libs as well, that are build in /MD compiler mode and cant be rebuild in
/MT. And mixing up /MD and /MT compiles end up in a error hell (undefined
externals). The app, compiled with the pre SP1 version of MSVC uses this
libs also, and this libs havent changed in between. So the error hasn't
anything to do with this libs.

What's in the manifests of these third-party DLLs? I guess they still bind
against
the RTM DLLs. I guess, there shouldn't be any binary incompatibilities
between
the RTM and SP1 DLLs, so it should just work with the new DLLs. To
redirect the binding to the new SP1 DLLs you would typically use a
configuration file. I take it, VC8 SP1 installs a publisher configuration
(I haven't
taken a look at SP1 one yet).

I have never needed to do anything like that but I believe you would
probably
need an application configuration and redirect to the SP1 one version. I
am
not sure, however, whether that works from the EXE or whether you have
to make the third-party DLL a private assembly (by providing an external
assembly manifest) and redirect the DLL binding there.

From the docs I read a while ago, I'd say the latter is the way to go -
but then
the documentation certainly isn't exactly exhaustive.

-hg