http://groups-beta.google.com/group/microsoft.public.vsnet.vstools.office/browse
_frm/thread/35b4a645edcfbc3b/07f785365ada27b7?q=System.ComponentModel.Win32Excep
tion+%22Class+already+exists%22&rnum=3&hl=en#07f785365ada27b7

We are encountering this bug in our .NET 1.1 (SP1) application when loading
our own concept of an "AddIn" into non-default application domains.  We
desperately need this bug fixed.  The alternative seems to be to give up on
running AddIns in their own application domain and instead forcing them to
all run in the default application domain with the host application itself.
The disadvantages of that are obvious enough - we lose the nice isolation
and we lose the ability to unload the AddIn's assemblies until host process
exit.  We lose the ability to ensure that all of the resources being held by
the AddIn are let go.

I've done a lot of googling around to try to find out more about this
problem and the above link is the only case where I found any kind of
Microsoft response.  That workaround wouldn't fly for us and, though there
is really no follow-up in the thread once the workaround code was posted, I
really doubt it did the job for most VSTO developers either.  Just disposing
of ALL controls seems to assume there is only one AddIn that has created any
controls on the thread.  Not our model.  Also, I think that there are HWND
backed comnponents that are not controls aren't there?  Like ContextMenus,
etc.?

When googling around I found a handful of people reporting that they'd
encountered this bug over the last couple of years.  If anyone knows of an
approach to solving or working around this problem please share it.

Can someone from Microsoft comment on whether this bug is fixed in .NET 2?
Might a hotfix or something be forthcoming for .NET 1.1?  Has the bug been
acknowledged/logged by Microsoft yet?

Bern McCarty

Bentley Systems, Inc.