Re: regsvr32 error code 0x80004002

it is not easy to find out which Microsoft service pack is breaking the
app, or even if it is a service pack at all or some other
machine-dependent configuration;

Double-Bingo.

The same problem started occuring on my boss's machine in January 2008, and
the cause is not .Net Framework 3 SP1. My boss installed .Net Framework 2
SP1 on that date. He has not installed any version higher than 2. (And the
DLL doesn't use any .Net Framework.)

Now by coincidence, with a previous version of this same DLL, I was able to
get private assemblies working in Windows XP SP2 and Vista, but not Windows
2000 SP4. So in a client application in C#, I try to "new" an object, if
that fails then I shell out to regsvr32, and if that also fails then I give
up. In Windows 2000 SP4 (and XP SP2 and Vista), prior to the December .Net
service packs, regsrv32 had no problem. On XP and Vista I can repeat the
effort to avoid needing regsrv32 at run time.

Regardless, Visual Studio 2005 SP1 knows that I'm compiling a DLL, so it
still tries to register the resulting DLL, irritating me and confusing my
boss. I already had to repeat the same explanation to him twice, and I get
dinged for being insufficiently communicative.


"David Ching" <dc@xxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:FmeAj.4784$fX7.1121@xxxxxxxxxxxxxxxxxxxxxxx
"Charles Wang[MSFT]" <changliw@xxxxxxxxxxxxxxxxxxxx> wrote in message
news:7P$z4GDgIHA.6844@xxxxxxxxxxxxxxxxxxxxxxxxx
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.


Hi Charles, well this puts us app developers in a bind. Because we cannot
look into a crystal ball to see the future and what manner of newer
versions of libraries Microsoft will deploy in the future, let alone
whether our app is going to be compatible with those new versions or not.
We take it on faith Microsoft will not break anything major in these
service releases, so by default we do not use private assemblies or
per-application configuration to lock into the version we have tested
with. So if Microsoft does release a service pack that breaks our app, we
now have to a) find out about this from angry customers and as Norman's
experience highlights, it is not easy to find out which Microsoft service
pack is breaking the app, or even if it is a service pack at all or some
other machine-dependent configuration; b) scurry to release a
per-application configuration update for our app or re-deploy our app with
private assemblies. I think you will agree that Microsoft is putting an
undue burdan on app developers to drop everything to fix a fire that
Microsoft caused by releasing a service pack or hotfix without warning.



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


This is a great new feature, essentially it is private assemblies for COM
objects.



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.



What now? We need to tell our customers running our apps on Windows
Server 2003 that they need to install this App Compat Toolkit and
configure it to allow our app to use a non-default version of a library?
What kind of nonsense is this? We app developers bend over backwards to
give our customers a trouble free deployment, and the best Microsoft comes
up with is force them to install some toolkit and configure it? Maybe MS
can afford that kind of tech support, but most of us can't.



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.


Thanks for all the useful info, Charles, but this is far too difficult.

-- David


.

Quantcast