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 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 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

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!