This is where the ITPro is beginning to cross deeper into “The Dark Side” of Development.

Ok Developers aren’t actually “The Dark Side” but there is a reaction from Many ItPros when you say “Code” or “Compile” their eyes just roll deep inside their heads and their noses turn a unique shade of purple.  Some even back away as if you spoke of a greater evil.

Thus the joke “Dark Side”

So I started poking about MSDN.COM to try and learn the structure of what .NET is.  The technology as a whole isn’t that scary when you start to think about it.  It’s a framework.   A Framework is really what it sounds like.   A “Frame” to “Work” with the environment.

Maybe not the correct wording and if any of my Developer friends read this posting, I ‘d appreciate corrections to the wording or my interpretation of this.

Within this Framework are various pieces to allow to work with Windows on a programmatic level.   Simple concepts like a FileOpenDialog or as deep as Creation and interaction with the GUI via WPF (Windows Presentation Framework)

Will I learn all of this in 24 hours?  Probably not.  Development is a passion.   .NET is an even deeper passion.  With that passion comes a skillset as well as wisdom on it’s use.

But .NET is NOT something to be startled off from.  If you’re an IT Professional and trying to automate something, nowadays you’ll probably be using Windows Powershell which works in the .NET Framework natively.   It has many “Assemblies”  already loaded.   With .NET you’ll hear reference to two key terms.  Assemblies and Namespaces.   These are two different ways .NET code are organized.

Assemblies can be found in the C:WindowsAssemblies folders for their names.    Descriptions of what function each can perform are obtainable on .



To add an Assembly to Windows Powershell simply type in

ADD-TYPE -AssemblyName NameOfAssembly

So if the Assembly we needed contained features that were not presently loaded (LIKE Adodb) you would just enter in

ADD-TYPE -AssemblyName Adodb

With this loaded you could now access the


How you work with it, well I’m still figuring that part out Winking smile

The Actual assemblies, when you get down to are a .DLL file containing a Namespace.  Think of an Assembly like a Word document full of Macros.  The TITLE of the Word Document might be SwissCheese, the filename it’s saved under could ALSO be called SwissCheese.docx

As Assembly is really just a .DLL file containing a Namespace full of classes.   Think of that .DLL file like the Word Document, the Namespace is the TITLE in the Document and the various Classes as Macros.

Ok, this is REALLY oversimplifying it but I raise this point because when I went online trying to learn the difference between Namespaces and Assemblies, I also found they seemed to share the same name.  This is more of a standard many hold to.    Just know that when you’re trying to load a Namespace, you may hear the term “Assembly” intermixed with it.  This is normal.

Sometimes when you’re trying to extend a feature to Windows Powershell where a Cmdlet does not exist, you will load the Assembly of it’s .NET dll code, and reference the namespace.

If you’re curious about more of this, you should check into these excellent online posts from Richard Siddaway, Lee Holmes and  Doug Finke which I used as a reference to get started.

And just for fun, I took Richard’s one liner to show the Loaded Assemblies and cleaned to just list them by name. Smile

[appdomain]::CurrentDomain.GetAssemblies() | select-object FullName | Foreach { $-.FullName.split(“,”)[0] } | sort-object

Ok, the rest of you IT Pros can relax.  We’ll return away from the deeper levels of .NET for a bit.  Knowing a little bit of what an Assembly is and Namespaces are can help you extend .Net applications to Powershell that are not presently Powershell enabled.