Search code examples
.netasp-classiccom

.NET COM+ Object can't be used from ASP Classic

TL;DR: Why would a COM+ Component by successfully activated from .NET but fail to load from ASP?

My scenario:

  • I've created a COM+ object using C#/.NET (Framework 4.0).

  • I'm deploying it to the server using a Visual Studio Installer project, which both install the DLL to GAC and also register it to COM.

  • Browsing C:\Windows\Microsoft.NET\assembly\GAC_MSIL, I can successfully find the DLL I've registered.

  • Looking at the Component Services add-in I can create an application and add the component that I've registered. Note that the names are different (between the DLL/namespace and the ProgId) which does give me confidence that both things occurred correctly.

However, I'm trying to create a new instance of this COM from ASP Classic. This means that there's a single line calling CreateObject("PROGID") in the program., which is throwing.

I've already done the following:

  • I've created a VBS file with a single line, CreateObject("PROGID"), and called it. It also fails, so the issue isn't restricted to ASP.
  • I've used Powershell 2.0 (the only one available on the machine) and called New-Object -ComObject "PROGID", and it also fails.
  • I've copied LinqPad to the machine and used Type.GetTypeFromProgID together with Activator.CreateInstance. I had success calling the instance.

The error, which seems pretty common, is 80070002. This is supposed to indicate that COM couldn't find the assembly file. Upon checking the registry, I can see that the Assembly name (the FQ Assembly Name) of the COM record does corresponds to the Assembly that I've installed. The runtime is the new CLR (v4.0.30319) and the class name is also correct.

I'm completely baffled by the fact that .NET can instantiate the COM object without any issues whereas VB6/ASP is aborting.

To make matters worse, the DLL was sucessfully deployed last week and I'm just installing a new version, so I should be having any troubles.

Is there any difference how COM's are loaded between ASP and .NET that can lead to such a scenario? What I'm thinking:

  • Any kind of permissions that must be set and haven't.
  • A dependency from any .NET DLL that, running from .NET, is found but running from VBS isn't.
  • The core runtime version may be to great for ASP/VBS.

The last item should be true since I've done this successfully just last week and I didn't changed anything about the runtime.

Solution

  • It seems this was much less of an elusive problem as it seems. I will still document it here as some people might run into this question on the exact same situation, although that's unlikely.

    The reason why ASP, VBScript and PowerShell weren't seeing the changes I applied and for some reason not finding the component (80070002) was that either an IIS reset or a complete shutdown/restart cycle of the server was necessary.

    What led me to this scenario was both the fact that the server admin forgot to perform the reset - something I didn't consider - and the fact that .NET was able to obtain the COM instance.

    I do not know the details that would explain why this is so - maybe .NET hadn't shadowed the assembly yet and whatever runs COM (yeah, I have no idea, sorry) did had. Certainly, something to that effect was going on.

    A clean reboot of the server completely solved the issue.

    A final point - just shutting down the application on Component Services wasn't enough.