REGASM interop bug

  • Thread starter Thread starter Kevin Flanagan
  • Start date Start date
K

Kevin Flanagan

This can be reproduced with VS.NET as follows. Create a new ATL
project with default wizard settings (dll, attributed). To the
'module' attribute, add a specifier 'version = "1.10" ' alongside the
name, uuid etc. specifiers. Build the dll. Use tlbimp to create a
primary interop assembly for it. Register that assembly using regasm.
The registry entries for the primary interop dll are inserted wrongly.
The original DLL has its typelib correctly registered under a registry
sub-key "1.a". Regasm incorrectly inserts a new registry sub-key
"1.10" under the same parent key. Regasm is formatting the sub-key
name in decimal, when it should be in hex. This breaks typelib loading
in some circumstances.

I've been looking for information on this bug, on workarounds or
fixes, and for places to report it to MS. Any help?

Kevin Flanagan.
 
Regasm incorrectly inserts a new registry sub-key "1.10" under the same
parent key.

If you're referring to a 1.10 key under the InprocServer32 key, that is correct
behavior, new on 1.1. Look at the .NET Framework Development topic
"Version-Dependent Registry Keys"
 
I think you may have misconstrued my message. I'm not saying that regasm
should not place anything like that in the registry (as you rightly say,
the topic you mentioned explains that it does). The problem is that it
formats it wrong. If you try it with type libraries numbered 1.0 to 1.9,
regasm puts its primary interop details in the same sub-key as COM's
details for the type library. If you try it with a type library numbered
1.10 (or above), COM registration for the original typelib stores
details under sub-key '1.a' while regasm inserts a parallel sub-key
'1.10'. This then stops some COM clients from being able to load the
type library (I imagine they look for the highest entry in the registry,
and consider '1.10' to be higher than '1.a', since the entries are meant
to be in hex, but regasm inserts them in decimal). This breaks two of
our type libraries under repeatable (though complex) circumstances, but
we can 'hack' it back again if we manually insert details under the
erroneous '1.10' sub-key for COM, i.e. the same details as under the
'1.a' sub-key. I can't see anything in the topic you've mentioned that
could make regasm's behaviour 'correct', plus in any case it does
actually break systems, but do tell me if you do know of some reason for
this being correct (and if so, how to stop it breaking COM clients as
described above). Thanks for the feedback so far.

Kevin Flanagan.
 
Kevin,
I've been looking for information on this bug, on workarounds or
fixes, and for places to report it to MS. Any help?
Click to expand...

Yes it's a bug, and it was fixed in v1.1 of the framework. It might
also be fixed by some of the v1.0 Service Packs, I don't remember for
sure.



Mattias
 
Well - that's odd, it's v1.1 I have installed (I never installed 1.0)
... VC++ 'About' dialog reports "Microsoft .NET Framework 1.1 Version
1.1.4322". Do you happen to have any references to MS information on
this bug and what versions/downloads/etc. fixes it? I've been looking
for such info with no luck so far. Thanks for your help and any more
info.

Kevin Flanagan.
 
Kevin,
Well - that's odd, it's v1.1 I have installed (I never installed 1.0)
Click to expand...

Sorry, my bad, it was not fixed in v1.1, I must have been thinking of
some other bug.

But it is fixed in v1.2/v2.0 alpha release, I actually verified it
this time.

Do you happen to have any references to MS information on
this bug and what versions/downloads/etc. fixes it? I've been looking
for such info with no luck so far.
Click to expand...

Here's at least a confirmation that it is indeed a known bug.

http://discuss.develop.com/archives/wa.exe?A2=ind0211C&L=DOTNET-CLR&P=R4472



Mattias
 
Back
Top