Last Saturday I attended Leetspeak. Among many awesome speeches and presentations I discovered scriptcs. scriptcs lets you write C# code directly in the console, or execute scripts written with just your favourite editor. Please see more about it on the site. What I thought during Justin Rusbatch’s session at Leetspeak:
Can we use scriptcs in SharePoint?
Technically there is no limitations in SharePoint for scriptcs. Any .NET code can be registered, imported and invoked in a console or in a standalone script. Here is the simple code for instantiating a site collection and disposing it: [code language=“csharp”] #r Microsoft.SharePoint; using Microsoft.SharePoint; var site = new SPSite(“http://dev”); site.Url site.Dispose(); [/code] The code above does not do anything, it is just there to demonstrate how you can register the SharePoint assembly (“Microsoft.SharePoint”) and import it into the script: [code language=“csharp”] using Microsoft.SharePoint; [/code] The example shows even that you in scriptcs no longer need the necessary “boilerplate” (compared to a console application): namespace, Program, Main()… You can just directly write your code. The rest is the same as in a C# application. The code samples for scriptcs can be any code written in C# for SharePoint, code from custom console applications, from feature receivers, you name it. So my next question is:
How can SharePoint development benefit from scriptcs
I can think about these advantages with scriptcs in SharePoint:
- Less need of PowerShell. As a developer you can use one language for creating SharePoint solutions and server configurations.
- You don’t need to rewrite your C# code to PowerShell. It saves time. Often one can see two solutions: one for C#, one for PowerShell, example.
- You can freely move code from feature receivers to scripts, like timer job installation, without rewriting code, example.
- You can use scriptcs to discover the SharePoint API, site columns, sites, fields and so on. PowerShell can be used as well. But scriptcs lets you use the same syntax. PowerShell is much different. It is not case sensitive. It often doesn’t throw NullReferenceException, it just doesn’t output anything. So if you use PowerShell as an exploratory tool, then you still will need to verify it in a C# code to verify, that your code works. With scriptcs you can directly copy the code from console directly to your code solution.
Of course, if there are advantages, then it must be some disantvantages.
Shortcomings of scriptcs in SharePoint?
I have found these shortcomings
- Missing powerful cmdlets for SharePoint (special “shortcuts” for configuration steps of SharePoint like New-SPWeb, Set-SPEnterpriseSearchService…)
- Missing native functionality in PowerShell for parsing xml, importing and exporting to csv and xml, a very easy way to read and write files on disk.
- There are already tons of PowerShell scripts written for SharePoint in companies and in the community. Mixing a huge amount of PowerShell with little scriptcs can increase complexity.
- scriptcs is still new. It is not adopted by Microsoft and maybe will not be approved in your project.
So what do you think about scriptcs and SharePoint?
Would you use scriptcs in your SharePoint project? Leave a comment or send me a tweet.
Scott Brickey - Oct 2, 2013
IMHO, this is silly… PowerShell gives you C#… the only real annoyances I have with PowerShell are due to being an early language… no (direct) support for generics or for lamda expressions. But even with those limitations, I find myself writing C# code in PowerShell on a very regular basis.
Thanks for the honest comment, Scott. What exactly do you mean by “writing C# code in PowerShell”?
sorry for the late response… see the following http://sbrickey.com/Tech/Blog/Post/Boldly_going_where_few_PowerShell_scripts_have_gone_before http://sbrickey.com/Tech/Blog/Post/Mission_Impossible_Remotely_terminating_a_SharePoint_Workflow http://sbrickey.com/Tech/Blog/Post/Recovering_SharePoint_Managed_Accounts
I don’t think that he even knows what he means