(0x80040154): Class not registered

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

Hagus - 12 Jan 2005 19:15 GMT

I'm hoping that someone could point me to the cause of this problem and
suggest a solution.

I have a C# program that dies with the following:
System.Runtime.InteropServices.COMException (0x80040154): Class not registered
at System.RuntimeType.CreateInstanceImpl(Boolean publicOnly)
at System.Activator.CreateInstance(Type type, Boolean nonPublic)
at System.Activator.CreateInstance(Type type)
at csnof.CsNof.Main(String[] args) in c:\projects\csnof\class1.cs:line 75

The code involved is:
if (targetServer.Length > 0)
objClassType = Type.GetTypeFromProgID(targetProgID, targetServer, true);
else
objClassType = Type.GetTypeFromProgID(targetProgID, null, true);
try
{
objApp_Late = Activator.CreateInstance(objClassType);
....

The code fails only when the targetServer.Lenght is > 0. I've tried this
with the targetServer value equal my own computer name. If fails when the
targetServer is a remote computer, which is the ultimate goal.

Since the program runs when I take the else path and the second parameter of
GetTypeFromProgID is null, the error does not make sense to me.

Thanks,
Mike

Reply to this Message

Phil Wilson - 13 Jan 2005 17:02 GMT

Whether or not that ProgId is at the other system, you might not have access
rights to read it from there. Note also that GetTypeFromProgId is documented
as throwing a COMException when that 3rd parameter bool is true, and that's
what you got alright.

Signature

Phil Wilson
[Microsoft MVP-Windows Installer]
Definitive Guide to Windows Installer
http://apress.com/book/bookDisplay.html?bID=280

> I'm hoping that someone could point me to the cause of this problem and
> suggest a solution.
[quoted text clipped - 29 lines]
> Thanks,
> Mike

Reply to this Message

Hagus - 13 Jan 2005 17:21 GMT

Phil,

Thanks for your response. Even if the 3rd parameter of GetTypeFromProgId is
false, I still get the 80040154 returned by the call to
Activator.CreateInstance. I assume there is something different about the
type returned from GetTypeFromProgId when the host parameter is not null,
even if the host is the local computer. I haven't found the difference
though. Why wouldn't I have access rights to read for my own computer when I
can successfully call Activator.CreateInstance with the 2nd parameter set to
null? How do the two differ? I would appreciate any thoughts you might have
on that.

Mike

> Whether or not that ProgId is at the other system, you might not have access
> rights to read it from there. Note also that GetTypeFromProgId is documented
[quoted text clipped - 33 lines]
> > Thanks,
> > Mike

Reply to this Message

Phil Wilson - 14 Jan 2005 17:36 GMT

I think that what you're effectively doing is DCOM, and there are a number
of things that need setting up at the remote system. Is there anything in
the event log at the other system?

Signature

Phil Wilson
[Microsoft MVP-Windows Installer]
Definitive Guide to Windows Installer
http://apress.com/book/bookDisplay.html?bID=280

> Phil,
>
[quoted text clipped - 58 lines]
>> > Thanks,
>> > Mike

Reply to this Message

Hagus - 14 Jan 2005 18:43 GMT

Phil,

The targetServer is the same computer executing the program. If it is set
to "localhost" or my computer name (Environment.MachineName) nothing turns up
in either the system or application eventlog.

If I set targetServer to ".", I get different results. First, the system
log contains an entry with:
Event Type:    Error
Event Source:    DCOM
Event Category:    None
Event ID:    10009
...
Computer:    <my computer>
Description:
DCOM was unable to communicate with the computer . using any of the
configured protocols.

In this case, the exception is also different. It is:
System.Runtime.InteropServices.COMException (0x800706BA): The RPC server is
unavailable.

Lastly, I've ran RegMon while I ran the problem with and without a value in
targetServer. Without a value, I see what would appear to be the problem.
When I execute GetTypeFromProgID with the targetServer null, I see it access
HKCR\CLSID\<clsid for my ProgID>\InProcServer32. When I have ".",
"localhost" or Evnironment.ComputerName in targetServer, it never accesses
HKCR\CLSID much less drill further to InProcServer32.

I guessing that I need to do something before GetTypeFromProgID to get it to
drill the registry further or that I need to do something afterwards but
before the call to Activator.CreateInstance. Nothing has jumped out of the
documentation at me though.

Thanks,
Mike

> I think that what you're effectively doing is DCOM, and there are a number
> of things that need setting up at the remote system. Is there anything in
[quoted text clipped - 61 lines]
> >> > Thanks,
> >> > Mike

Reply to this Message

Hagus - 22 Jan 2005 03:27 GMT

All,

I opened a case with Microsoft on this topic. One of the things I had not
specifically noted in my earlier posts is that the COM object was in-process.
When I called Activator.CreateInstance with the server parameter of
GetTypeFromProdID = null, the COM object's dll loaded into my program; my
program became its server.

Microsoft pointed out that when the type was created with a server name,
either my own computername or that of an actual remote computer, the COM
object needed a server program on the "remote" computer. So Microsoft's
solution to my problem was to have me add a DllSurrogate value under the key
HKCR\AppID\{<AppID_Guid>}. The DllSurrogate value needs to be specified in
the registry of the "remote" computer. In my case, I had to add the AppID
key as well as the DllSurrogate value, which I let the value defaut to blank.
Now when I run my client so that it calls GetTypeFromProgID with a non-null
server, I see the COM object load under dllhost when the client executes
Activator.CreateInstance.

Mike

> Phil,
>
[quoted text clipped - 98 lines]
> > >> > Thanks,
> > >> > Mike

Reply to this Message

(0x80040154): Class not registered

Free Magazines