Unable to access .Net component from COM+ VB based application

Tech-Archive recommends: Fix windows errors by optimizing your registry

From: Paul Martissa via .NET 247 (anonymous_at_dotnet247.com)
Date: 08/04/04 

Date: Wed, 04 Aug 2004 05:34:08 -0700

(Type your message here)
Hello All,

We have this design.....an existing VB6 Windows client DCOMs via a proxy to a Win2003 server hosting a COM+ server application whose components are written in VB6. One of these COM+ VB6 components uses a .NET Class Library object referenced through an interop'ed .tlb reference. The .NET component, and all of it's referenced assemblies were strongly named and loaded in the the server's GAC.

That being said, when I execute a testharness from the server's COM+ application's directory, all works great (of course). However, when I try to run the harness from any DCOM'ed client, I recieve the dreaded "Error:429-ActiveX component can't create object" error message. The ActiveX object is in fact within the correct DCOM'ed VB6 COM+ application and the object that fails initialization is the .NET interop'ed assembly.

We also tried to uninstall from the GAC and place the .NET assemblies in the same directory that contains the COM+ application's component, but to no avail.

I probobly missed something simple here and am getting frustrated that we have not found anything on Google that looks like this........We could really use any help!

Eagerly awaiting the calvary!
Paul
--------------------------------
From: Paul Martissa

-----------------------
Posted by a user from .NET 247 (http://www.dotnet247.com/)

<Id>uJS0UIJkMEy1d4RsWkgCBg==</Id>

Relevant Pages

  • Re: App.path - equivalent - in an interop DLL
    ... .NET assemblies by default do not rely on the Registry for calling applications to identify their location so that they can be ... So if the dll isn't in the same location as the exe, there's no way for the exe to know where that dll resides so that it can be ... The GAC allows you to install .net assemblies in a common location so that essentially the assembly can be shared. ...
    (microsoft.public.dotnet.framework)
  • Re: App.path - equivalent - in an interop DLL
    ... > loaded in the calling program's process space. ... > So if the dll isn't in the same location as the exe, there's no way for the exe to know where that dll resides so that it can be ... The GAC allows you to install .net assemblies in a common location so that essentially the assembly can be shared. ...
    (microsoft.public.dotnet.framework)
  • Re: Moving a policy file into GAC
    ... CLR will briefly read the publisher policy, ... unlikely it will lock the file. ... For the uninstall, usually it means you are not passing the right parameters ... > We are having an issue with policy files and the GAC. ...
    (microsoft.public.dotnet.framework.clr)
  • Re: Functoid scripts - referenced assembly caching in VS.NET
    ... Sounds like a common problem people have with .net assemblies in the GAC. ... Any running process that has a reference to a component in the GAC will ... > I have a biztalk project and a VB class project within a given solution. ...
    (microsoft.public.biztalk.general)
  • Re: I really hate .NET especially inside Delphi
    ... Bob Swart wrote: ... for .NET assemblies have been registered in the GAC (on the web ... server.. ...
    (borland.public.delphi.non-technical)