Is anyone successfully using registration-free COM with .NET components?

Question

Until recently, we were happily using registration-free COM for our native and .NET COM components. However, we ran into a weird issue where our application started crashing randomly on windows XP SP3 (but not on vista) after we only changed the version number of a .NET assembly to move from release candidate to release. (Don't you just hate Murphy's law?)

After many a lost man-day and teeth grinding, we discovered that the issue was a known bug in sxs.dll which causes heap corruption when retrieving information about a .NET class. There is a hot-fix which makes the issue disappear but hot-fixes are not intended to be redistributed.

We're kinda stumped that there is such a horrible bug in the registration-free COM implementation. Is anyone out there successfully using registration-free COM for .NET components? How did you work around this issue?

Answer 1

This issue is related to how SxS calculates the size of the class information. The version number of the assembly is part of this information.

Since it was working with the release candidate version number, perhaps the workaround for you is to make the version number of the release the same length as the RC release.

If this doesn't work for you, there is an established process for requesting redistribution rights for hotfixes. I would engage Microsoft customer support to pursue this route.

Answer 2

We're using registration-free COM for both native and .NET components. We decided to use a fixed assembly version number for these components (mainly to prevent cluttering the registry when repeatedly regasm-ing .NET components that had a dynamic build number/*). Not ideal but we have other ways of determining which version of a given component is being used (they're never patched individually).

That sounds like a very nasty issue indeed! That KB article almost makes it seem like using SxS is optional... As far as I know it's the only way to do reg-free COM?