---
title: "Loading Winform UI controls from a different AppDomain is problematic"
url: "https://osherove.com/blog/2003/8/25/loading-winform-ui-controls-from-a-different-appdomain-is-pr.md"
canonical: "https://osherove.com/blog/2003/8/25/loading-winform-ui-controls-from-a-different-appdomain-is-pr.html"
published: "2003-08-25T19:18:00"
updated: "2003-08-25T19:18:00"
tags: [".Net Original"]
author: "Roy Osherove"
description: "I recently got a question regarding a problem loading dynamic UI controls at runtime. Part of the solution that person tried to do was to try and load the controls in a separate AppDomain , so that they can later unload…"
usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)."
license: "https://creativecommons.org/licenses/by/4.0/"
---

# Loading Winform UI controls from a different AppDomain is problematic

By Roy Osherove August 25, 2003 In [.Net Original](https://osherove.com/blog/category/net-original)

**Historical article** · Originally published August 25, 2003; technical details may be outdated.

I recently got a question regarding a problem loading dynamic UI controls at runtime. Part of the solution that person tried to do was to try and load the controls in a separate _[AppDomain](http://www.dotnet247.com/247reference/System/AppDomain.aspx)_, so that they can later unload those AppDomains and release the memory that the controls occupied. However - this did not work:

\>We can create the usercontrols in a different appdomain but when we go
\>to add the usercontrol to the launcher's container (_Me.Controls.Add_) in
\>the default appdomain we get:
\>
\>"_Remoting cannot find field parent on type System.Windows.Forms.Control_"
\>
\>It does find events, the Tag property, and the Location property.
\>
\>It appears that the transparentproxy isn't exposing all of the
\>usercontrol properties, etc.  We are not using an interface because we
\>don't know what properties, methods, etc. the control container is
\>expecting at run-time.  Also, we are loading UserControls so we thought
\>they would expose any interfaces the container may be looking for
\>(although apparently not through remoting).  All of the controls inherit
\>MarshalByReference and we find no difference if we decorate them with
\>.

Here's the code to reproduce this:

    Public Sub New()

        MyBase.New()

        'This call is required by the Windows Form Designer.

        InitializeComponent()

        'Add any initialization after the InitializeComponent() call

        Dim \_appDomain As AppDomain

        Dim \_handle As System.Runtime.Remoting.ObjectHandle

        Dim \_control As System.Windows.Forms.TextBox

        \_appDomain = AppDomain.CreateDomain("TextBox")

        \_control = \_appDomain.CreateInstanceFromAndUnwrap("C:\\WINDOWS\\Microsoft.NET\\Framework\\v1.0.3705\\System.Windows.Forms.dll", "System.Windows.Forms.TextBox")

        Me.Controls.Add(\_control)

    End Sub

**So why does this happen?**

The problem stems from the fact that you are loading the control from a different AppDomain, and thus are essentially using remoting to talk to the control through the context boundery. Unfortunately, Remoting cannot access private members through context bounderies, which is exactly what '_parent_' is in this case(inside the _Control_ class).

## More in .Net Original

[All posts in .Net Original](https://osherove.com/blog/category/net-original)

- Sep 1, 2003

    ### [The \[Conditional\] Attribute](https://osherove.com/blog/2003/9/1/the-conditional-attribute.html)

- Sep 1, 2003

    ### [Asynchronous ASP.Net actions suck?](https://osherove.com/blog/2003/9/1/asynchronous-aspnet-actions-suck.html)

- Aug 25, 2003

    ### [The ultimate connection string reference](https://osherove.com/blog/2003/8/25/the-ultimate-connection-string-reference.html)

- Aug 25, 2003

    ### [Combobox binding trouble - with a solution](https://osherove.com/blog/2003/8/25/combobox-binding-trouble-with-a-solution.html)


---

## About the author

**Roy Osherove**: Senior Solutions Architect at AWS working on AI for production and AI-driven development; author of The Art of Unit Testing and Elastic Leadership, with about 20 years of consulting and training on unit testing, TDD, team leadership and continuous delivery.

### Sites

- [RobotPaper](https://robotpaper.ai/): This blog: AI patterns and anti-patterns, AI and coding agents, and engineering leadership.
- [osherove.com](https://osherove.com): Roy's personal site. Author of The Art of Unit Testing and Elastic Leadership; consulting and training on unit testing, TDD, team leadership and continuous delivery, plus about 20 years of blog posts.
- [The Art of Unit Testing](https://www.artofunittesting.com): The Art of Unit Testing, 3rd Edition (Manning): readable, maintainable, trustworthy unit tests, plus TDD workshops in C#, JavaScript, Java and Kotlin.
- [5whys.com](https://www.5whys.com): Roy's writing on software team leadership: self-organizing teams, surviving chaos, learning mode and the Elastic Leadership model.
- [Pipeline Driven](https://pipelinedriven.org): Continuous delivery and DevOps practices: build patterns, pipeline-friendly testing, DevOps metrics and enterprise DevOps.
- [Elastic Leadership](https://www.elasticleadership.com): Elastic Leadership, Roy's framework for software team leaders (survival, learning and self-organizing modes).

### Social

- X: https://x.com/royosherove
- LinkedIn: https://www.linkedin.com/in/osherove/

### Contact

- Contact form: https://forms.gle/jQSx5KoXvrVA1JCK7

### License

Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page). License: https://creativecommons.org/licenses/by/4.0/