Understanding .NET from the perspective of an IT Professional

| | Comments (3) | TrackBacks (0)

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 .

 

image

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

[ADODB.Connection]

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.

0 TrackBacks

Listed below are links to blogs that reference this entry: Understanding .NET from the perspective of an IT Professional.

TrackBack URL for this entry: http://www.energizedtech.com/cgi-sys/cgiwrap/jolyrogr/managed-mt/mt-tb.cgi/494

3 Comments

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?

Paul

Great article. I wrote an entire series of .NET for IT Pros some years ago - the above reference is the first article in the series. At some point, I really should re-publish it all! We even did two full day pre-conference runs of it in TechEd EMEA.

For me, understanding the .NET framework at least a bit is important for more advanced admins. There is a treasure trove of features that may make your life as as admin easier in places. Yes, you can spend your life just using cmdlets provided by Microsoft, but often, digging down into the framework will allow you to do things that you can't do with existing cmdlets.

Some points in your article.

First, An assembly can be just one DLL, but it can be more. For an Assembly, you need some code, and a manifest which describes the code to .NET. In most cases, this ends up being one file, one manifest and a bunch of classes. But it can be more.

Secondly, In your figure, you point to the Global Assembly cache, But the GAC is by no means the only place to get assemblies from.

When created by, say, Visual Studio, an assembly contains code in the Microsoft Intermediate Langues (IL or MSIL). To actually run, the assembly needs to be converted into native code by the just in time (JIT) compiler. This jitter process takes time and for large assemblies, i.e. those making up PowerShell itself, can slow down the initial loading of a .NET program. For that reason, you can pre-compile the assembly, using the Native Generate (NGEN.EXE) tool. Ngen stores the compiled assembly in the GAC which is what you are seeing in the above picture. But you can store your assemblies anywhere.

Third the name space is sort of like part of an index below which you find individual classes (and methods, properties, etc). The full name of a .NET Class includes it's namespace and you need that full name with PowerShell. In Visual Studio and C#, there is the using keyword which specifies namespaces. This allows you to use just the class name in your code. PowerShell has no such feature. :-)

For example, if I built an assembly I could use the namespace PSP.PowerShell which might create a .NET object (class) called GratefulDeadShow which, inter alia, has a static method 'Find()', I could use this in PowerShell as follows:

[PSP.PowerShell.GratefulDeadShow]::Find(...)

Hope the clarification and link helps!

Thomas


@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
$obj1.property

Hope this helps