Re: regsvr32 error code 0x80004002

Regarding DLL hell, I want to talk it from another perspective. It is very
important for a developer to choose a proper deployment method for his
target machine. You also need to make a decision of using private
assemblies or using shared assemblies before you deploy your applications
or DLLs. If you choose shared assemblies, you need to ensure that the
target machine will not install the newer VC++ redistributable libraries.
If you could not ensure this, you need to consider if you should use an
application configuration file for your application (.exe) or use private
assemblies instead.

Currently for those DLLs who need to be registered via regsvr32.exe, there
is no better way to work around the registering issue except using private
assemblies. However there is a new feature for creating COM in Visual
Studio 2005, you can create isolated COM which is no need to be registered
via regsvr32.exe. You may refer to:
Isolated COM
http://qualapps.blogspot.com/2007/06/isolated-com.html
Isolated COM Activation tutorial:
http://msdn.microsoft.com/msdnmag/issues/05/04/RegFreeCOM/
Isolated COM Activation sample project:
http://download.microsoft.com/download/2/e/9/2e9bde04-3af1-4814-9f1e-733f732
369a3/RegFreeCOM.exe

For applications (.exe), using private assemblies is not the only way to
work around assembly redirection, you can also use application
configuration file to define the redirection rule for your application.
There are two articles talking about this:
Per-application Configuration on Windows XP
http://msdn2.microsoft.com/en-us/library/aa375667(VS.85).aspx

Per-application Configuration on Windows Server 2003
http://msdn2.microsoft.com/en-us/library/aa375660(VS.85).aspx

I once resolved a customer's issue for using application configuration
file
and I would like to share the resolution here for you:
============================================================================
=======================
Application configuration file indeed works for unmanaged applications on
both Windows XP and Windows Server 2003, however they have some different
configuration settings.

On Windows XP, you need not to specify the publisherPolicy section. I used
the following configuration file (ManiConsTest.exe.config) for my test
program ManiConsTest.exe:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<configuration>
<windows>
 <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
  <assemblyIdentity type="win32" processorArchitecture="x86"
name="Microsoft.VC80.CRT" publicKeyToken="1fc8b3b9a1e18e3b"/>
               <bindingRedirect oldVersion="8.0.41204.256-8.0.50608.0"
newVersion="8.0.50727.42"/>
            <bindingRedirect oldVersion="8.0.50727.42-8.0.50727.1433"
newVersion="8.0.50727.42"/>
  </dependentAssembly>
 </assemblyBinding>
</windows>
</configuration>

This is enough for Windows XP. However on Windows Server 2003, the things
became more complex. To have it work, you must install Application
Compatibility Toolkit 5.0 (ACT 5.0) and configure the EnableAppConfig flag
for your application. Please refer to the following steps in detail:
1. Download and Install ACT 5.0 (Application Compatibility Toolkit.msi)
from this link:
http://www.microsoft.com/downloads/details.aspx?FamilyID=24da89e9-b581-47b0-
b45e-492dd6da2971&DisplayLang=en

2. Open Start->All Programs->Microsoft Application Compatibility Toolkit
5.0->Compatibility Administrator;
3. After Compatibility Administrator is opened, first click the Save
button
to save the database, rename it as AppCompatDB, input the file name as
appcompatdb and click Save.
4. Right click AppCompatDB database, select Create New->Application
Fix...;
input your application name to the field "Name of the program to be fixed"
(I input ManiConsText here for my program), select your Program file
location by clicking Browse button, and click Next;
5. Select None as Compatibility Modes, click Next, select EnableAppConfig,
click Next, click Finish, and then Save your database by first selecting
your database and clicking the Save button;
6. Right click your database, select Install and you will find that the
database will be installed under the Installed Databases folder.
7. After the above steps, you have successfully configured the
EnableAppConfig for your application, and now you just need one
application configuration file (xxx.exe.config) which is as following:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<configuration>
<windows>
 <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<publisherPolicy apply="no"/>
<dependentAssembly>
   <assemblyIdentity type="win32" processorArchitecture="x86"
name="Microsoft.VC80.CRT" publicKeyToken="1fc8b3b9a1e18e3b"/>
               <bindingRedirect oldVersion="8.0.41204.256-8.0.50608.0"
newVersion="8.0.50727.42"/>
            <bindingRedirect oldVersion="8.0.50727.42-8.0.50727.1433"
newVersion="8.0.50727.42"/>
  </dependentAssembly>
 </assemblyBinding>
</windows>
</configuration>

After the above steps finished, you can run your program and then you will
find that it only loads the assemblies with the version 8.0.50727.42.

I cannot say DLL hell is eliminated in every condition; however I think
that with manifest we eliminate the old fashion DLL hell problem.

You know DLL hell is not so frightful, because we always have methods to
work around it. :-) If you have any other questions or concerns, please
feel free to let me know. I am very glad to work with you for further
research.