Longstanding WinForms bug: System.ComponentModel.Win32Exception: Class already exists

  • Thread starter Thread starter Bern McCarty
  • Start date Start date
B

Bern McCarty

http://groups-beta.google.com/group...already+exists"&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.
 
There is a property on a Form called CreateParams. You can override this
property to provide your own values for such properties of CreateParams as
ClassName and ClassStyle.
Now, let's do the following trick. Each plug-in has an associated class name
for dialog windows. All plug-ins share a derived Form which accepts the
class name in the constructor.
Each plug-in registers and unregisters its own window class and upon showing
the dialog box, configures the derived Form to use the class name associated
with the plug-in.
 
Back
Top