Kategoriarkiv: Powershel

PowerShell: Get version and ProductId from an .app package

In my project I deploy some apps directly through the ObjectModel directly with PowerShell. The apps are built with TFS

I have a script that installs or updates apps if there is a new version of the app. Previously I used Import-SPAppPackage to compare the version and productid with an existing app instance, but often I get this error:

The provided App differs from another App with the same version and product ID.

Here you have the issue. Now the solution is to read the AppManifest.xml. But first the .app package has to be extracted like a usual zip file. This is the powershell function for that:

Count lines of code with PowerShell

Today I got a question:

How many lines of code are there in our SharePoint solution?

After a little search, I found that PowerShell is really a nice tool to count lines of code:

I wanted to count lines for different types of code:

  1. Code Behind written in C#, the files have .cs file extension
  2. JavaScript code (except jQuery, angular or knockout frameworks)
  3. PowerShell files (.ps1 and psm1)
  4. Xml files (all the SharePoint .xml files)

Here is the powershell code that counts lines of code:

# go to the solution folder
cd <solution directory>

#count lines in .cs files
ls -include *.cs -recurse | select-string . | measure | select count

#count lines in our .js files
ls -include *.js -recurse `
    -exclude *min.js, jquery*, _*, jsrender*, CamlBuilder*, knockout* `
  | select-string . `
  | measure `
  | select Count

#count lines in our powershell scripts
ls -include *.xml -recurse | select-string . | measure | select count

#count lines in our powershell scripts
ls -include *.ps1, *.psm1 -recurse | select-string . | measure | select count

Just a curious fact, I can’t tell you how many lines of code we have in our solution, but I can reveal the proportions. If I used the flexible box model in css3, it would look like this:

lines of code

There are as many lines of code written in javascript as it is in C#. The main reason that for the big js code base are the SharePoint hosted apps. The PowerShell scripts are as big the javascript code base. Xml files are 4 times bigger than C# code, and it is even bigger than the sum of all lines of code written in C#, JavaScript and PowerShell. It isn’t strange that xml is dominating, almost everything in SharePoint is defined in xml.

Fortunately, there are less cases where you have to write raw xml in Visual Studio 2012/2013 and SharePoint 2013.

How does it look in your project? What language is dominating in your SharePoint project?

scriptcs and SharePoint. How SharePoint can benefit?



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:

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:

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.