PowerShell scripting for Microsoft Dynamics CRM – Requirements

PowerShell scripting for Microsoft Dynamics CRM – Requirements
4 (80%) 4 votes

On my previous blog post, I wrote about the benefits of using PowerShell as the missing link between two worlds: development and operations. PowerShell is definitively a great asset considering the current DevOps trend. By the way, this trend will be widely represented in the incoming TechDays 2015 sessions in Paris next February. Can’t wait to be there!

Requirements

As a first requirement, I assume that you are a .NET developer and that you have a Visual Studio development environment at disposal. You should be fine using a Windows 7 SP1 or a Windows 2008 SP1 operating system or higher. For information, the following examples uses Visual Studio 2012 Professional edition, on a Windows 8 Professional desktop.

There are also some requirements that you should consider first, as it will prevent you from restarting your computer later.

Windows .NET Framework 4.0

Dynamics CRM 2011 components are built on .NET Framework 4.0, so I choose to develop my extensions using the same Framework version. Implementing extensions using .NET Framework 4.5 as a target version could also be a great choice in order to enable latest features or targeting Dynamics CRM 2013, 2015 and Online. Windows .NET Framework 4.0 is available here: http://www.microsoft.com/en-US/download/details.aspx?id=17851

Windows Management Framework 4.0

The Windows Management Framework will install PowerShell 4.0 on the computer if necessary. This update includes types required to create custom PowerShell commands. Windows Management Framework 4.0 is available here: http://www.microsoft.com/en-us/download/details.aspx?id=40855

Windows Identity Foundation 3.5

The Windows Identity Foundation is a must have while developing for Dynamics CRM platform. It provides, among others features, pre-built security logic in order to connect to Dynamics CRM organizations implementing claims-based authentication. Windows Identity Foundation 3.5 is available here: http://www.microsoft.com/en-US/download/details.aspx?id=17331

Set-up the IDE environment

PowerShell Integrated Scripting Environment (ISE)

Windows PowerShell ISE is a graphic integrated development environment (IDE) edited by Microsoft. This IDE allows developers to write and run commands, debug scripts and support standard but yet mandatory features such as multiline editing, tab completion, syntax coloring and selective execution. I choose to use this PowerShell IDE in this tutorial.

Other PowerShell users may recommend you PowerGUI as a PowerShell IDE: http://www.quest.com/powergui-freeware/. PowerGUI handles more complete and complex features than PowerShell ISE. But since we will deal with the basis first, I would like to keep it simple and use the integrated and standard PowerShell IDE.

On Windows 8 and Windows Server 2012, PowerShell Integrated Scripting Environment (ISE) is installed and enabled. On Windows 2008 R2, PowerShell ISE is not enabled by default. You can use… PowerShell (!) as Administrator in order to activate this feature:

Import-Module ServerManager Add-Windowsfeature PowerShell-ISE

On Windows 7 and Windows Server 2008 SP1, PowerShell ISE must be installed through the Windows Management Framework. Since it’s already a prerequisite, that should not be a problem.

Script Browser and Script Analyzer

As a PowerShell beginner, it is useful to have access to real world scripts or snippets coded by dedicated developers. The Script Browser allows to search a particular implementation directly from ISE. This is a great way to discover PowerShell implementations and possibilities ; and also essential in order to not reinvent the wheel.

The Script Analyzer is useful as it highlight parts of the script which do not respect best practices. All the proposed rules are more or less relevant, but it is really a great start for making your own opinion about what best practices should be implemented in your context. I will propose the rules I decided to follow later in this article, as an example. The two extensions are available here: http://www.microsoft.com/en-us/download/details.aspx?id=42525

Common Language Runtime 4.0

These blog posts has been written using PowerShell version 4.0. If you wish to keep using version 3.0, that should not be a problem as your PowerShell can use the CLR version 4.0. More information about .NET Framework CLR: http://msdn.microsoft.com/en-us/library/8bs2ecf4%28v=vs.110%29.aspx

To check your PowerShell version, run the command following command on a PowerShell prompt and then look for the CLRVersion property. If the property starts with 4.0, then you are good to go. Otherwise, you will not be able to run types contained in .NET library compiled under the .NET 4.0 Framework, such as the Dynamics CRM 2011 SDK libraries. In order to use the CLR 4.0, please follow the steps describes in this StackOverflow post: How can I run PowerShell with the .NET 4 runtime?

Visual Studio 2012 (NuGet for CRM SDK)

I would not recommend any particular set-up for your favourite .NET IDE.

You can use NuGet in order to manage the required CRM SDK libraries we will need in our project. NuGet is a Visual Studio extension which provide an easier way to manage .NET projects dependencies. The NuGet documentation is available here: http://docs.nuget.org/

The Microsoft Dynamics CRM SDK team releases and maintains packages containing the official Microsoft CRM Dynamics 2013 assemblies. The CRM 2011 assemblies are also available.

Unlock restricted execution Policies

In order to enforce security, PowerShell scripts executions are blocked by default. This policy is relevant since PowerShell main purpose is to provide administrative features. You will want to unblock PowerShell scripts execution through command line as Administrator. For example:

Set-ExecutionPolicy Unrestricted -Scope CurrentUser

For more information about Execution Policies: http://technet.microsoft.com/library/hh847748.aspx

Best practices

It seems that there is no absolute best practices regarding PowerShell development. Every rule is debated among the community and the rule are mostly based on the script objective and the writer background. The following propositions are my own rules, which I would like you to consider in order to improve your scripts readability and meaningfulness. Please do not hesitate to share your own rules in the comments!

  • PowerShell commands are formed using a verb-noun construction. It is recommended to use this construction instead of aliases to improve code readability. You can find the standard verbs by typing the following command at the command line:
Get-Verb
  • PowerShell pipeline, as other command line interpretors, is a great feature as it allows to pass the result of a command to another command. Nevertheless, using too much pipelines decreases the code readability. Moreover, the debug process is more difficult. For example, please compare the two following commands:
Get-Content computer-names.txt |
ForEach-Object -Process {
Get-WmiObject -Class Win32_BIOS -ComputerName $_
}
$computers = Get-Content computer-names.txt 
foreach ($computer in $computers) {
Get-WmiObject -Class Win32_BIOS -ComputerName $computer
}
  • Do not write comments for every instruction: doing so will obfuscate the logic of your code. The three previous rules are meant to improve readability and allow the reader to understand the code’s logic. For example, the following instruction is self explanatory and the comment provided states the obvious:
# Get the WMI BIOS object from the computer
Get-WmiObject -Class Win32_BIOS -ComputerName $computer
  • Regarding the documentation, documenting specific instructions by writing the MSDN URL in comment for further reference is very useful if you are a newbie with PowerShell. Providing working example in your code documentation helps a lot too.
  • Of course, indenting your code is a well followed best practice. Considering this point, it seems that my WordPress skills need improvement too. :)

Here is a bonus tip for you:

  • Remind to often close ISE or the command line between scripts executions: variables and types are always accessible in the current session once the execution is finished. This caused me quite a headache during my first debugging session!

For more reading about PowerShell best practices, I recommend you The Community Book of PowerShell Practices, available at http://PowerShell.org in the ebooks section (I got the inspiration and examples from there).

Following the requirements and best practices, next time, we will start coding – at last!

Leave a Reply

Your email address will not be published.