Jean G

On on clean x86 Vista (no VS2005 installed), I deploy a VS2005 project that includes a DLL which requires MSVCR80.DLL & MFC80.DLL. That DLL is to be registed as

COMSelfReg. The setup includes the following merge modules:

Microsoft_VC80_CTR_x86.msm
Microsoft_VC80_MFC_x86.msm

When running the .msi, the error -2147010895 (0x800736B1) pops up. A quick DEPENDS look (on Vista) of that DLL confirms that all that is missing is MFC80.DLL and MSVCR80.DLL.

It's as if MSI tries to register that DLL *before* the merge modules are properly processed (i.e. before the MFC80.DLL and MSVCR80.DLL files are in place), which fails. Can anyone from the MSI team confirm that

If I install vcredist_x86 prior to run the .msi, the installation is succesful (i.e. the DLL successfully self-registers). But I would rather not have users having to download and install that.

If I do not self register, the installation goes through, and I can after REGSVR32 that DLL, meaning that the merge modules are sufficent for that DLL to load. I can possibly live with that because at the end of the installation, an .EXE that initializes a database is launched, and it can invoke REGSVR32 in silent mode. The only drawback is that I'm not sure what REGSCR32's exit codes are in case of an error. Btw, that EXE also has dependencies on MSVCR80.DLL and MFC80.DLL, but it loads and runs because the merge modules have been processed by the time it is run.

My question is: how do I self-register under MSI a DLL that has some dependencies that would normally be addressed by the merge modules If that cannot be done (because DLL are registered *before* merge modules are processed), what are the options

Thanks

Jean



Re: Visual C++ General DLL deployment error -2147010895 (0x800736B1)

Simple Samples

If you are using REGSVR32 in your setup, then that is likely part of the problem, or a symptom of a problem. REGSVR32 does not do much; you can look at the source code for it; it is a sample Windows program.

How did you create the deployment project I am not sure, but probably if your DLL is a valid COM object and you use the setup wizard in VS, the setup project that is created from that will work.






Re: Visual C++ General DLL deployment error -2147010895 (0x800736B1)

Jean G

I do not use RegSvr32 in the project. What I meant is that if omit the self-registration, proceed with the install (along the merge modules), and then manually use RegSvr32 to manually install the DLL, it loads fine.

Since my first post, I've been experimenting and what I found (that may be useful for some) is that on a clean system without the C++ runtime and MFC, a self-registering DLL with dependencies on the C++ runtime and MFC will not load despite using the appropriate merge modules, resulting in an installation failure.

This has been true on both XP and Vista. The only workaround I found is to install vcredist_x86, then run the installer. The self-registering DLL then loads fine and the installer properly terminates.

Also on Vista, a self-registering DLL run with elevated privileges (provided the user has Administrator rights or if not, has entered the admin credentials), but an app launched by the installer will not have such rights. In my installer, I need to launch an app that updates some information in HKLM, but that fails because it doesn't have the rights. If I put the same exact code in a self-registering DLL, the code runs fine. I concluded that on Vista, a self-registering DLL is invoked with the elevated privileges, but any app launched during the installation does not have those privileges (if run from a standard account with admin credentials).

That'd be great that the MSI folks at MS can comment on this. Thanks





Re: Visual C++ General DLL deployment error -2147010895 (0x800736B1)

crescens2k

Well, IIRC you are running into user account control problems with these apps. So you are going to have to deal with it appropriately in Vista.

For the self registering, I think there was a post on here before saying that the copying of the vcredist is actually done after the registering of the COM libraries. If this is the case then you have two options, put your DLL registration code into a reg file and merge that, or provide a custom action later in the installer to run the registration. Well, in theory any process of writing the values to the registry after/without depending on the CRT would work.






Re: Visual C++ General DLL deployment error -2147010895 (0x800736B1)

Jean G

I found out that that on Vista, an app launched by an MSI installer (itself launched from a standard account that provides the admin credentials) won't run with elevated privileges. There's no way around this as far as I can tell (unless the MSI installer is directly run from an admin account). So if some installation code is required to run at elevated privilege, I have concluded that it must be in a self-registering DLL (as it runs with elevated privileges). But since the DLL will be loaded before the merge modules are installed, then it will fail to load (hence the error 0x800736B1) because the CRT and MFC DLLs are not present yet.

So all in all, I need to run some MFC 8.0 code that requires elevated privileges (not only to register a COM object, but to do some other installation chores), and I haven't found the way to that in MSI unless vcredist_x86 is run beforehand.





Re: Visual C++ General DLL deployment error -2147010895 (0x800736B1)

Simple Samples

I have seen questions such as this in the microsoft.public.platformsdk.msi newsgroup. If you search the archives, you might find answers that already exist; otherwise, you can get answers from highly qualified experts.