Re: regsvr32 error code 0x80004002

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

We can determine if CRT/ATL SxS is the cause of the regsvr32 failure or
not by looking into the Event Viewer. There should be entries saying which
VC assembly failed to load (if that is the cause).

Oh yeah, how could I forget. OK, just now I reproed the bug with a version
of the DLL that was built in October 2007 and could be regsvr32'd then, but
which has yielded this bug ever since December 2007. It did repro again
just now, but there are no relevant events in the Event Viewer.

If I recall correctly, this kind of event was obscurely located in the
System log instead of the Application log. But just now I checked both, and
there's no event. So the problem isn't that an assembly failed to load,
it's that a current assembly is failing at something that an older version
was succeeding at.


<georgeraafat@xxxxxxxxx> wrote in message
news:3233cff6-3681-4d50-9619-37b7c1566ece@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
On Mar 6, 4:09 pm, "Norman Diamond" <ndiam...@xxxxxxxxxxxxxxxx> wrote:
My understanding now is as follows:

If a DLL was built with Visual Studio 2005 SP1 and was compiled to use the
corresponding version of the CRT and ATL libraries, then distribution of
the
DLL must be accompanied by redistribution of the corresponding CRT and ATL
libraries. Private assemblies must be used. There is no other way.

Furthermore, this solution must be applied to DLLs that were already built
and distributed, even when we thought we had finished their development.

The reason is:

The creator of the DLL cannot predict which end users' machines will have
.Net Framework 3.0 SP1 installed. Even though the DLL does not use .Net,
the DLL will be affected on an end user's machine if .Net Framework 3.0
SP1
is installed on the end user's machine.

It is time to add to my previous observation:

DLL Hell .Net is worse than DLL Hell Classic -- even for DLLs that do not
use .Net.

"Charles Wang[MSFT]" <chang...@xxxxxxxxxxxxxxxxxxxx> wrote in message

news:AYh40D4fIHA.6844@xxxxxxxxxxxxxxxxxxxxxxxxx



> Hi Norman,
> Thanks for your response.

> I think that this issue was caused by assembly redirection. Since .NET
> 3.0
> SP1 was installed, the Microsoft.VC80.CRT assembly was redirected to the
> newest version according to policy file which you can find in
> %Windir%\WinSxS folder, however according to your DLL manifest, your
> assembly should reference the old version. This may caused thiserror.

> I recommend that you first try using private assemblies to see if it
> helps.
> Manually copy the related DLLs and manifests to your COM application
> folder
> and rename the manifest file according to this article:
> Private Assemblies
>http://msdn2.microsoft.com/en-us/library/aa375674.aspx

> Regarding redistributing VC++ DLL as private assemblies, you can also
> refer
> to the following articles:
> Redistributing Visual C++ Files
>http://msdn2.microsoft.com/en-us/library/ms235299(VS.80).aspx
> Choosing a Deployment Method
>http://msdn2.microsoft.com/en-us/library/ms235316(VS.80).aspx

> Hope this helps. If you have any other questions or concerns, please
> feel
> free to let me know.

> Best regards,
> Charles Wang
> Microsoft Online Community Support
> =====================================================
> When responding to posts, please "Reply to Group" via
> your newsreader so that others may learn and benefit
> from this issue.
> ======================================================
> This posting is provided "AS IS" with no warranties, and confers no
> rights.
> ======================================================- Hide quoted
> text -

- Show quoted text -

Hi Norman,

We can determine if CRT/ATL SxS is the cause of the regsvr32 failure
or not by looking into the Event Viewer. There should be entries
saying which VC assembly failed to load (if that is the cause).
Absence of such entries indicate that there is no problem with loading
CRT/ATL.

I installed the Microsoft .NET Framework 3.0 Service Pack 1 on a
machine with VS2005+SP1 and things seem to working fine.

Please, let us know how this goes. We are very interested in
understanding this scenario.

Thanks,
Visual C++ Libraries
George Mileka

.

Relevant Pages

  • Another super fun problem
    ... I've been playing around with assemblies and I've run into quite the little ... if you load your .dll up into a bytearray, ... if this file you're loading into byte arrays, loads up another dll in the ...
    (microsoft.public.dotnet.general)
  • Re: application domain
    ... be run in an application domain do I then have to load this dll into ... I mean if the exe file and the dll is located in the same folder will ... foreach (string assembly in Directory.GetFiles (@"C:\My Assemblies", ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: application domain
    ... be run in an application domain do I then have to load this dll into ... I mean if the exe file and the dll is located in the same folder will ... foreach (string assembly in Directory.GetFiles (@"C:\My Assemblies", ...
    (microsoft.public.dotnet.languages.csharp)
  • Dynamically Loading Assemblies in ASP.NET
    ... I want to load assemblies dynamically in ASP.NET application. ... have a dll for each database that my application is supporting. ...
    (microsoft.public.dotnet.faqs)
  • Re: .NET dll config file
    ... > application has some other .NET dll references. ... assemblies to a separate folder you create problems because you have to tell ... So if your library is called by a "third party application" ... You cannot create a config file just for your DLL. ...
    (microsoft.public.dotnet.framework)