--- title: "User Group notes: WMI, CLR hosting and AppDomains" url: "https://osherove.com/blog/2003/8/20/user-group-notes-wmi-clr-hosting-and-appdomains.md" canonical: "https://osherove.com/blog/2003/8/20/user-group-notes-wmi-clr-hosting-and-appdomains.html" published: "2003-08-20T18:42:00" updated: "2003-08-20T18:42:00" tags: [".Net Original"] author: "Roy Osherove" description: "If you missed it. Today was the monthly group meeting of the Israel visual C++ users group (I’ve been meaning to add a list of Israel’s .Net user groups to my blog links but somehow I always end up doing something…" 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/" --- # User Group notes: WMI, CLR hosting and AppDomains By Roy Osherove August 20, 2003 In [.Net Original](https://osherove.com/blog/category/net-original) **Historical article** · Originally published August 20, 2003; technical details may be outdated. If you missed it. Today was the monthly group meeting of the [Israel visual C++ users group](http://www.comconix.com/ivcug/) (I’ve been meaning to add a list of [Israel’s .Net user groups](http://www.microsoft.com/israel/communities/usergroups.mspx) to my blog links but somehow I always end up doing something else..). The meeting was supposed to be a continuation of a previous meeting, that concerned “CLR plumbing”. Basically it talked about several subjects. Some more interesting than others. I’ll list what I remember with a short description of the most important stuff. **WMI(Windows management instrumentation)** Actually this is a subject that in the past 2 weeks or so has become near and dear to my heart. In fact, I’m planning to write an article on my experiences with it, and with active directory programming. WMI is a technology that allows you to literally query the insides of your computer(or a remote machine) for various system information. For example – to get the list of all directories on your disk you can literally execute a query such as “_Select \* from Win32\_Directory_”. You can then work against an extensive and complex object model that can pretty much get you anywhere you want and do whatever you like. This is also supported in .Net (via the _System.Management_ namespace). One of the things that the .Net framework adds to the machine on which it is installed is an additional set of classes that allow you to query for various performance counters that are specific for .Net [WMI administrative tools](http://www.microsoft.com/downloads/details.aspx?FamilyId=6430F853-1120-48DB-8CC5-F2ABDC3ED314&displaylang=en) package is a small setup program that deploys several utilities that allow easier work and learning with the WMI classes. Mainly, the CIM studio is **the** tool to learn exactly what exists and what can be done with this amazing technology, and is installed using this setup program. Another cool tool for the VS.Net: [Management (WMI) Extensions for Visual Studio .NET 2003 Server Explorer](http://www.microsoft.com/downloads/details.aspx?FamilyID=62d91a63-1253-4ea6-8599-68fb3ef77de1&DisplayLang=en) **CLR hosting and AppDomains** For each process that loads a managed application, a new and unique instance of the CLR is loaded and hosted via that process. That means that if you double click 100 times on a managed exe, you’ll have 100 instances of the CLR running on your system. Performance wise, if any of those applications wanted to talk to each , since each of them resides in a separate AppDomain, they are actually talking via Remoting. Remoting between different Process is very expansive for performance. One way to overcome this limitation is to have a single AppDomain host other AppDomains within its own process, each AppDomain running the managed assembly on its own. The basic idea is that you will have one “loader” program, that all that it does is perform code such as the following:     Private Sub HostExternalCode()         Dim app As AppDomain         Dim app1 As AppDomain         app = AppDomain.CreateDomain("Domain1")         app.ExecuteAssembly("MyProgram11.exe")         app1 = AppDomain.CreateDomain("Domain2")         app1.ExecuteAssembly("MyProgram22.exe")     End Sub Now what you have here are actually 3 AppDomains. 1 for the current AppDomain, and 2 more that are running inside the current Process. Actually, they are running inside the current thread. They can actually block this thread from processing. The better way to do this is to create a multi threaded implementation of this program that runs each assembly on a separate thread. Now. All this hassle still does not mean these Applications have solved the problems of speaking to each other. Still, each application message to another application has to cross the AppDomain boundary. However, now these boundaries reside **in the same process space** and thus performance suffers much less. The CLR actually exposes both unmanaged APIs and COM interfaces. This allows you to easily instantiate a CLR instance in any COM language (even in Excel VBA) and make it do some cool stuff. The cooler stuff, however resides (as always) in the unmanaged native APIs. You can write a C/C++ application that uses those APIs and really customize the way in which the CLR instance loads. You can set whether it will run optimized for a single(workstation) or multi processor(server) machine .The difference?  Optimizations. Points about “server” mode: - if you set “server” and are running on a single processor machine you’ll automatically get the “workstation” behavior minus one caveat: “server” mode does not let you run garbage collection on a separate thread, unlike “workstation” mode. But since you are running as “server” in default, you’ll get the “server” threading behavior. - The default run mode is “workstation” More things you can set when you host your own CLR via native APIs: - You can set the Domain model to “Domain Neutral” meaning your AppDomains won’t have to deal with any security contexts when speaking to each other. You simply will have full trust on everything running in that CLR instance. - One other thing I can’t remember **Perf counters** New Performance counters are added to the Perfmon when installing the framework. One important point was that all perf counters in .Net framework are “always on” meaning you get perf counters running even if you’re no using perfmon or other means to track them. This causes a performance hit, but was worth the code, because have “#if”s everywhere in the native code was much more a performance hit. You can use WMI to access all the perf counters on the machine as well! ## More in .Net Original [All posts in .Net Original](https://osherove.com/blog/category/net-original) - Aug 24, 2003 ### [Some debugging tips](https://osherove.com/blog/2003/8/24/some-debugging-tips.html) - Aug 21, 2003 ### [Make your app support plugins - Part II](https://osherove.com/blog/2003/8/21/make-your-app-support-plugins-part-ii.html) - Aug 20, 2003 ### [Make your app support plugins](https://osherove.com/blog/2003/8/20/make-your-app-support-plugins.html) - Aug 17, 2003 ### [CodeSmart.Net](https://osherove.com/blog/2003/8/17/codesmartnet.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/