With every new version of SharePoint, we need to upgrade our Visual Studio solution. There’s no easy way or tool out there that can automate these upgrade. So I’ll just describe few points you need to consider when you’ll upgrade the Visual Studio 2010 project for SharePoint 2010 to Visual Studio 2012 project for SharePoint 2013. First of all, you need to upgrade your Visual Studio pre-VS2012 solution to Visual Studio 2012.
Change Target .NET Framework
SharePoint 2010 uses .Net Framework 3.5 with SharePoint 2013 uses .Net Framework 4.5. So you need to change the target framework for the project. To change the target framework version, unload the project and then edit the project file in Visual Studio and change the property as shown below:
<TargetFrameworkVersion>v4.5</TargetFrameworkVersion>
Change SharePoint Version
Unload the project and edit in Visual Studio, then add/edit the section to ensure the following entry near to the <TargetFrameworkVersion>
<TargetOfficeVersion>15.0</TargetOfficeVersion>
Then load the project and replace all SharePoint 2010 specific DLLs with SharePoint 2013 specific DLLs (version 15). Also find out any reference of SharePoint 2010 DLLs/Controls version ‘14.0.0.0’ and replace with ‘15.0.0.0’
Change Generic Setup Path in code
In SharePoint 2013, you can deploy your solution in SharePoint 2010 more or SharePoint 2013 mode or both. For example to deploy your solution to both 2010 and 2013 mode, you can use the following command:
Install-SPSolution -Identity my_solution.wsp -GACDeployment -CompatibilityLevel {14,15}
If you skip the CompatibilityLevel (and we usually skip), then the solution is deployed default compatibility level included in the WSP manifest file – which is based on Visual Studio project’s target SharePoint Version. But since we are targeting to upgrade Visual Studio solution to SharePoint 2013, we need to make sure code looks for artifacts in 15 hive, instead of 14 hive. To ensure that code looks in 15 hive, we need to find all use of ‘SPUtility.GetGenericSetupPath()’ and need to replace it with ‘SPUtility.GetVersionedGenericSetupPath()’ passing parameter 15 as shown below:
SPUtility.GetVersionedGenericSetupPath(‘/_Layouts/myproject/script/test.js’,15)
Note – If you are still deploying your solution in compatibility 14 mode, then you should also replace the ‘GetGenericSetupPath()’ with ‘GetVersionedGenericSetupPath()’ passing parameter 14, but instead of hardcoding the version inline, you can use a constant so that you can replace the version number in one place to change it to 15. You can use constant ‘Microsoft.SharePoint.Utilities.SPUtility.ContextCompatibilityLevel’ which returns the current compatibility level of the SPSite. Your code then will look like:
SPUtility.GetVersionedGenericSetupPath(‘/_Layouts/myproject/script/test.js’,Microsoft.SharePoint.Utilities.SPUtility.ContextCompatibilityLevel)
However, if you want to use the same code both for SharePoint 2010 and SharePoint 2013, then you can code block like below to run code in different version of SharePoint:
//if SharePoint site collection is running in 2013 (15) mode if (SPUtility.ContextCompatibilityLevel==SPUtility.CompatibilityLevel15) { //Code needs to be executed in SharePoint 2013 } else if (SPUtility.ContextCompatibilityLevel==14) { // Code needs to executed in SharePoint 2010 } //You can also use SPSite.CompatibilityLevel to find out site collection compatibiltiy mode
Change Reference to Layouts, ControlTemplates
Finally all references to ‘_Layouts/’ and ‘_ControlTemplates/’ needs to be changed to ‘_Layouts/15/’ and ‘_ControlTemplates/15/’ to ensure the artifacts are loaded from 15 hive. Either SharePoint will try to load files from 14 hive. However if you deploying the solution in SharePoint 2010 mode, (compatibility level is 14), then you don’t need to update the reference.
Conclusion
After making all the above changes, finally compile the solution. However, my suggestion would be to deploy the WSP in SharePoint 2010 mode first, test the deployment and adjust/modify code to comply with SharePoint 2010 object model. Once you are comfortable with changes, then upgrade code as described in the post and then deploy/test.
Hi Sohel, we have recently migrated SharePoint 2010 SP1 from Server 2008 to SharePoint 2010 SP2 on Server 2012 R2. The site works fine. We were also successful in deploying the solution to the new servers. But one of the solution does not work and we suspect that its the .net framework compatibility causing the issue. We dont have the Project Files to target the wsp to 3.5. Do you know if there is any workaround ? Thanks
ReplyDelete