Using the .NET framework in Powershell

When using Powershell, every now and then I need to exploit the fact that is is Integrated with the .NET framework.
Recently I had to convert a value, and knowing that the DateTime class in .NET is capable of this, if sought to find a way to use it. I found this easy Little trick!

Say that we want to convert a datetime value that has been stored as a float.
This would be the solution

$result = [DateTime]::FromFileTime(130674339390635017)
$Result will then become : 03-02-2015 11:45:39

This can also be used with nested namespaces as shown below.

Udklip

CallerMemberName

When I develop applications for the Windows environment, my pattern of choice is of course the MVVM ( Model-View-ViewModel ).

But every pattern has drawbacks, and one of the drawbacks on MVVM is that, when you raise a change on a property, it would be done like below.

string _Name;
public string Name
{
get { return _Name; }

set {
_Name = value;
Raise("Name");
}
}

This sample is very sober, but since you are parsing a string with the name of the property that you intend to update, you are setting yourself in the risk of misspelling it without the debugger telling you that anything is wrong. Because a string is a string, it refers to a property for the sake of the PropertyChangedEventHandler. So that it is aware of what property to update. But if that string would for instance be “Naaame” – then the event handler would look for a property of that name, and upon not finding it, it would not update the property that you desire to update. And then starts the troubleshooting.

And in some cases, you could probably end up checking a lot of things that are not relevant, change a lot of code that does not need changing, before realizing, that this word was misspelled.

So, to make this easier on ourselves, we should update the way our method for the PropertyChangedEventHandler looks like.

In the past, it would be written like so.

public void Raise(string PropertyName)
{
if(PropertyChanged != null)
PropertyChanged(this, new PropertyChangedEventArgs(PropertyName));
}

So, it is as explained above. It takes the string that we entered in the Setter of the property, and then we parse that to the PropertyChanged event, only, it won’t update anything since “Naaame” does not exist.

Queue, the [CallerMemberName] - Which is a little golden nugget in the world of MVVM.

What it does, is what the name states, it includes the Callers (The Property) MemberName (PropertyName) and sets the PropertyName to that value.

Before using it though, we need to add a using statement for it. In the ViewModel, the following using statement must be added.

using System.Runtime.CompilerServices;

Which means, that we get to do this.

public void Raise([CallerMemberName] string PropertyName = null)
{
if(PropertyChanged != null)
PropertyChanged(this, new PropertyChangedEventArgs(PropertyName));
}

We have now added the [CallerMemberName] to the method, and now it will do the job of writing the Property’s membername whenever the method is called from the within property.

So now, we can do this to all of our properties.

string _Name;
public string Name
{
get { return _Name; }

set {
_Name = value;
Raise();
}
}

No more possibilities for sneaky string errors ! Unless there is reason for using the strings. Because, you can still parse the string and have it work. Which is good, in case you need to update a property from another method.

Executing Powershell Script as a Task

Having fiddled around with Powershell every now and then, I have figured out that Powershell scripts are very powerful and efficient. For instance for monitoring, which has been my latest case.

I had a looping script that would monitor services, and every time it saw a service that was not running, it would start the service, write a log and continue the loop.

The script was working perfectly, and then it was time to put it into production. I didn’t look for long before i decided to use the script in a Task. I had the Whole thing set up, the task was running, but no logging would be done. And it would not start up the services that was Down.

Having experienced something like this before, I remembered that Microsoft has introduced execution policies to their powershell environment, ensuring that no unintended scripts are running and doing stuff they should not.

So the fix was easy!

All i had to do, was open the task, go to actions and change the action so it would look like this.

Action: Start an application
Program/Script: Powershell
Add arguements: -executionpolicy bypass -file “FullPathToMyScriptHere”
Start Path: Empty

After this, my script would run beautifully.

Introduction to MVVM

Having helped quite some people on the MSDN WPF Forum, i figure i might as well add a code sample in the code.MSDN gallery for future reference when people want to get to know MVVM and Databinding a little better. So i added this.
http://code.msdn.microsoft.com/Basic-MVVM-Setup-12e5d46c

I might elborate the sample if the demand should be there some day, and add CommandRelays and SelectedItem logic. But that depends on people actually reading and benefiting from the sample.