Understanding .NET from the perspective of an IT Professional

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:\Windows\Assemblies folders for their names.    Descriptions of what function each can perform are obtainable on msdn.microsoft.com .



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.


2 thoughts on “Understanding .NET from the perspective of an IT Professional

  1. Great article as I am trying to do the same thing and make greater use of MSDN with Powershell. For example using the Exchange Web Services provider. MSDN has all the information but I don’t have the developer knowledge to translate into scripts.
    I assume that [Something.Something]::Property is calling an assembly and then a property of the assembly?

  2. @paul
    You are almost right! When you use:[Something.Something]::Property, the Something.Something is the full .Net class name for the class you are trying to access, including a namespace name.
    With your example, you probably have a namespace of Something, which contains a class called Something which in turn has a static property called Property.
    These classes are stored in assemblies but you must have loaded the assembly before you can makes use of the classes inside that assembly.
    One further thing, classes can have dynamic members and static members. A static member is one that exists irrespective of any occurrence. Dynamic members exist on individual instances of a class.
    [Something.Something}::property is a static property, some attribute of the class. For dynamic properties, you’d need to create a class instance then access the instance property, as follows:
    $obj1 = new-object something.something
    Hope this helps