With SharePoint 2013, Microsoft has introduced a small monkey wrench in where solution files get deployed when mapped to the LAYOUTS (/_layouts) folder. Files in SharePoint 2007 and 2010 would simply be deployed under the /_layouts folder. With SharePoint 2013, however, these same files are now deployed under /_layouts/15. Not really a big deal if you are writing a solution only for SharePoint 2013. However, if you are writing a solution for multiple versions of SharePoint, you may need to identify the version of SharePoint running so that you can reference files in their correct location. This is just one scenario in which you may want to identify which version of SharePoint you are running.
To identify the current version of SharePoint, you simply need to use the SPFarm BuildVersion. For example:
|
1 2 3 4 5 |
using Microsoft.SharePoint.Administration; ... var version = SPFarm.Local.BuildVersion; // Set the label to the Major version (12, 14, 15, etc). lblVersion.Text = version.Major.ToString() |
The Major version can be used to identify the version of SharePoint (12 = 2007, 14 = 2010, 15 = 2013). In addition, you can use the minor and build version numbers to identify what updates have been applied to the farm.
That’s it. Hopefully you find it useful.
Any logical reason for making this change do you think? Or is Microsoft just not content with keeping things the same…
My guess is that with 2007 (12) to 2010 (14) there were issues with compatibility for 2007 solutions running on 2010. And by leaving the normal /_layouts folder at the same content as 2010 with all the new 2013 stuff in /_layouts/15 the solutions for 2010 that rely on that content will continue to work as desired. In the projects I am working on I am actually seeing that nearly everything written for 2010 magically works on 2013.
What’s even more interesting is that a solution written for 2010 automatically gets deployed to the locations expected for 2010 when deployed to 2013. Whereas a solution set to a 2013 version (in the Package XML) automatically gets deployed to the 2013 locations. In addition, most 2013 solutions that get deployed to a 2010 environment get deployed to the 2010 locations. Thus why it is good to identify the current version so that you can set compatibility level to 2013 and still maintain the ability to deploy to 2010 by looking for resources in the correct location.
In a future post I will talk about many of the points to consider when writing solutions for both versions.