Using Regsvr32 to register a inproc dll

I have created an com inproc dll and when I use Regsvr32 to register
it, none of the interfaces in it are registered at all.  When I run
"IPDolphin current RegisterServer" from a development image,
everything registers correctly for the development environment.  Any
ideas, tricks or techniques that I can do to debug this problem.

I have created another sample dll and when registered works as
expected so I am at a loss at why one works and the other does not.
Any help would be greatly appreciated.

Thanks,
Scott

"Scott" <[hidden email]> wrote in message
news:[hidden email]...
> I have created an com inproc dll and when I use Regsvr32 to register
> it, none of the interfaces in it are registered at all.  When I run
> "IPDolphin current RegisterServer" from a development image,
> everything registers correctly for the development environment.  Any
> ideas, tricks or techniques that I can do to debug this problem.
>
> I have created another sample dll and when registered works as
> expected so I am at a loss at why one works and the other does not.
> Any help would be greatly appreciated.

Have you forgotten to set up the type library path? Or attempting to deploy
on Win9x (which doesn't support the resource updating APIs we use to put the
typelib into the executable)?

The registration of coclasses is performed in Smalltalk, so you can put
tracing code (e.g. use the Trace global, which is a stream connected to
OutputDebugString) in the registration code, the entry point for which is
IPDolphin>>RegisterServer. You'll have to run a debug monitor such as
dbgview.exe from sysinternals.com.

Regards

Blair

"Blair McGlashan" <[hidden email]> wrote in message news:<al9rd2$1oqh8o$[hidden email]>...
I have set the type library path under custom options and am trying to
deploy on Win2000.  Good points to remember though.  I was able to get
a smaller sample one to work fine, but cannot get this to work.

> The registration of coclasses is performed in Smalltalk, so you can put
> tracing code (e.g. use the Trace global, which is a stream connected to
> OutputDebugString) in the registration code, the entry point for which is
> IPDolphin>>RegisterServer. You'll have to run a debug monitor such as
> dbgview.exe from sysinternals.com.

I was wondering where OutputDebugString is writing to.  I will try the
dbgview.exe for further debugging.  Thanks alot.

Scott

>
> Regards
>
> Blair

> The registration of coclasses is performed in Smalltalk, so you can put
> tracing code (e.g. use the Trace global, which is a stream connected to
> OutputDebugString) in the registration code, the entry point for which is
> IPDolphin>>RegisterServer. You'll have to run a debug monitor such as
> dbgview.exe from sysinternals.com.

When I "regsvr32 sample.dll", I get the following message in
dbgview.exe:

[1508] UnitOfMeasure class does not understand #progID

UnitOfMeasure is a class I am deploying, but it is a subclass Object
and is not intended to be a COM object.

When I put the code 'Trace nextPutAll: 'RegisterServer'; cr.' at the
beginning of the IPDolphin>>RegisterServer method, redeploy the dll
(it is built ok), and run "regsvr32 sample.dll" on the new dll.  I get
a message from RegSvr32 that 'DllRegisterServer in sample.dll
succeeded.' and only get the above error message in dbpview.exe and
not my message of 'RegisterServer'.

What is going wrong?

Thanks,
Scott

"Scott" <[hidden email]> wrote in message
news:[hidden email]...
> > The registration of coclasses is performed in Smalltalk, so you can put
> > tracing code (e.g. use the Trace global, which is a stream connected to
> > OutputDebugString) in the registration code, the entry point for which
is
COM objects in Dolphin are not limited to being under particular point in
the hierarchy - any class can be a COM object. If you look at the
IPDolphin>>coclasses method you will see that it locates COM object classes
(coclasses) in the image based on whether they conform to the #COMObject
protocol. Conformance to a protocol is something that is explicitly set, so
this would suggest that at some point you have deliberately or inadvertantly
added that protocol to UnitOfMeasure.

BTW: If you have a coclass which is noncreatable (i.e., not intended to be
instantiated directly by external clients), then you can implement its class
side #clsid method to return CLSID null, in which case the registration code
will ignore it.

> When I put the code 'Trace nextPutAll: 'RegisterServer'; cr.' at the
> beginning of the IPDolphin>>RegisterServer method, redeploy the dll
> (it is built ok), and run "regsvr32 sample.dll" on the new dll.  I get
> a message from RegSvr32 that 'DllRegisterServer in sample.dll
> succeeded.' and only get the above error message in dbpview.exe and
> not my message of 'RegisterServer'.
>
> What is going wrong?

Hmmm, not sure. The method would appear to have been invoked when you
previously ran it, since the error trace probably came from the handler in
that method.

Regards

Blair

> COM objects in Dolphin are not limited to being under particular point in
> the hierarchy - any class can be a COM object. If you look at the
> IPDolphin>>coclasses method you will see that it locates COM object classes
> (coclasses) in the image based on whether they conform to the #COMObject
> protocol. Conformance to a protocol is something that is explicitly set, so
> this would suggest that at some point you have deliberately or inadvertantly
> added that protocol to UnitOfMeasure.

When I run 'IPDolphin current coclasses' (when the coclasses instance
variable is nil), the UnitOfMeasure class does NOT appear in the
coclasses collection.  This would indicate to me that the
UnitOfMeasure class does not comform to the COMObject portocol.
(Which I have verified in a development image) (I start with a clean
image for each build and only load the required packages).

> BTW: If you have a coclass which is noncreatable (i.e., not intended to be
> instantiated directly by external clients), then you can implement its class
> side #clsid method to return CLSID null, in which case the registration code
> will ignore it.

Thanks for the tip, I will give this a try.

When I put "Trace nextPutAll: 'something'; cr" in some of the other
IPDolphin methods, and use these to build my small sample dll, all the
messages appear just fine.  When I use these same methods with the
problem dll, none of the messages appear at all.  (OnStartup,
RegisterServer, UnregisterServer, OnShutdown, OnInitialize [not sure
of the exact method names right now])

> Hmmm, not sure. The method would appear to have been invoked when you
> previously ran it, since the error trace probably came from the handler in
> that method.

But my Trace call was before all the rest of code.  This is very
strange to me.

I am going to try and remove the problem class from the build and
start smaller and see where that gets me.  Any other ideas would be
great.

Thanks,
Scott

I removed the UnitOfMeasure from my package.  I started with a clean
image, reloaded my code, verified that the class UnitOfMeasure is not
in the image, rebuilt the dll (new timestamp on the file and
UnitOfMeasure is not listed in the build log file), ran "regsvr32.exe
sample.dll", got a message box "RegSvr32", DllRegisterServer in
uom.dll succeeded, but in the dbgview.exe program I get the error,
"[1856] UnitOfMeasure class does not understand #progID".  What is
going on?  The class is not in the image.  But I can build the
ComRandomStream and a light weight example without any problems.

This is mind boggling.

Help?

Scott

After 3 days of constant trial and error, I finally figured out the
problem.
It was another copy of the dll in windows system directory.  Once I
deleted that one, the newly deployed dll was used and everything now
works as expected.

Sorry for all the posts, but I was really stumped as to what was going
on.

Thanks for all the help Blair,
Scott