In yesterday’s blog post, I wrote about being able to use later versions of the .NET Framework with PowerShell. The trick was simple: create a config file, a small file of XML, to enable the use of, in my case, the .NET Framework Version 4 and the new namespace System.Numerics. That XML file tells PowerShell what version of the .NET Framework to load. You can see this if you display $psversiontable variable. By default, you’ll see something like this:
PSH [C:\foo]: $PSVersionTable
Name Value
---- -----
CLRVersion 2.0.50727.4200
BuildVersion 6.0.6002.18111
PSVersion 2.0
WSManStackVersion 2.0
PSCompatibleVersions {1.0, 2.0}
SerializationVersion 1.1.0.1
PSRemotingProtocolVersion 2.1
But with the .Config file in place, you’d now see this:
PSH [C:\foo]: $PSVersionTable
Name Value
---- -----
PSVersion 2.0
PSCompatibleVersions {1.0, 2.0}
BuildVersion 6.0.6002.18111
PSRemotingProtocolVersion 2.1
WSManStackVersion 2.0
CLRVersion 4.0.30319.1
SerializationVersion 1.1.0.1
Another key difference is that when you now load additional .NET namespaces using LoadWithPartialName, you will get later version of the dll (the exact version number loaded depends on what you put into the config file. So loading Windows Forms now looks like this:
PSH [C:\foo]: [system.Reflection.Assembly]::LoadWithPartialName("System.Windows.Forms")
GAC Version Location
--- ------- --------
True v4.0.30319 C:\Windows\Microsoft.Net\assembly\GAC_MSIL\System.Windows.Forms\v4.0_4.0.0.0__b77a5c…
By default, you got this:
PSH [C:\foo]: [system.Reflection.Assembly]::LoadWithPartialName("system.windows.forms")
GAC Version Location
--- ------- --------
True v2.0.50727 C:\Windows\assembly\GAC_MSIL\System.Windows.Forms\2.0.0.0__b77a5c…
It’s pretty easy to use later versions of the .NET Framework. These later versions provide new classes you may find useful.
PSH [C:\foo]: [system.Reflection.Assembly]::LoadWithPartialName("system.windows.forms")
GAC Version Location
--- ------- --------
True v2.0.50727 C:\Windows\assembly\GAC_MSIL\System.Windows.Forms\2.0.0.0__b77a5c561934e089\System.Windows.Forms.dll
But beware of doing this in a data centre without testing that your existing scripts are fully compatible with the later versions of the Framework. You shouldn’t have any problems as MS is pretty good about forward compatibility, but it never hurts to be careful. Just ensure you do thorough testing before rolling this out across the board.
No comments:
Post a Comment