Just before Christmas I was tasked with the wonderful job of getting DocRead (our Policy Management Software for SharePoint) working on SharePoint 2013. I had actually tackled this a couple of weeks before when I reported this here : ‘DocRead’s first day on 2013’. At this point, although things appeared to be working, we encountered a few issues during testing. We also needed to make DocRead look and feel like a SharePoint 2013 application.

Some work had to be done!

Our set-up

Before I get started, it’s worthwhile understanding how we have things set-up at Collaboris. Our development team still use Visual Studio 2010 and TFS 2010. We would love to make the move to Visual Studio 2012 – but there’s no time and no compelling reasons to do so at the moment. DocRead currently runs on multiple versions of SharePoint as follows :

• SharePoint 2010 Foundation
• SharePoint 2010 Server (Standard and Enterprise)
• MOSS 2007

We also use Hyper V development machines.

Please also note – we do not intend to use any of the new ‘App’ functionality in SharePoint 2013. In the first version we are simply porting our 2007 / 2010 solution to work on 2013, which means ‘full fat’ (not sandboxed) Farm solutions.

SharePoint 2010 Farm solutions will run on 2013

If you take a SharePoint 2010 farm solution (as a WSP) and install it into 2013, it stands a really good chance of working. This is possible because Microsoft also deploys the 14 hive and all of the binaries needed to support 2010. When you deploy the solution if the Manifest.xml contains ‘SharePointVersion=”14.0″‘ then this will deploy layouts, features and so on to the older 14.0 hive. If it states ‘SharePointVersion=”15.0″‘ it will deploy to the new hive.

This is pretty useful if you want to just ‘get it working’ on 2013 and then perhaps migrate your application over to SharePoint 2013 at later date. If – like us – you want to fully support SharePoint 2013 and compile against .Net 4.0 you need to keep reading. After all, there’s some tasty features in 2013 you may want to take advantage of 😉

Upgrade Steps

So here we go – the following list outlines everything I had to do in order to get a build up and running. If you need to upgrade a farm solution to 2013 at the same time as supporting 2010 then you will find this useful. Please leave comments on anything else you have found so that we can share each other’s pain.

Support multiple versions in one Visual Studio Solution

There’s a lot of steps to getting this all up and running so I wrote it up in a separate blog post called ‘How to support multiple versions of SharePoint in a single Visual Studio solution‘. I recommend you read that then come back here to carry on.

Change the version of your solution package to ‘15.0’

The first thing you need to do is change your ‘SharePoint Product Version’ to “15.0“. Doing this causes your solution to be treated as a SharePoint 2013 solution and will deploy all of the components to the correct locations.

Who moved the GAC?

One of the biggest changes that will catch out SharePoint developers (who have spent their life in SharePoint 2007 and SharePoint 2010), is that Microsoft decided to move the GAC (Global Assembly Cache). If you are keen debugger and forever dropping in new versions of you assembly into the GAC, you need to know that it’s moved! Dropping it into C:\windows\assembly and then trying to ‘attach to process’ doesn’t work unless you drop it into the new location.

There is now one GAC for each version of Microsoft.Net (from v4.0 and on). The old GAC is still there, but it’s used for older versions of .Net.

For a more in-depth discussion on why there is a new GAC please read this post.

SPUtility.GetGenericSetupPath method is obsolete

This will probably catch you out. If you continue to callSPUtility.GetGenericSetupPath(), this will return a link to the 14 hive (SharePoint 2010), not the the new 15 hive (SharePoint 2013). So if you are programmatically getting handles to files using this approach, they will not longer be found. Instead of this you – use SPUtility.GetVersionedGenericSetupPath(). We support all 3 versions of SharePoint using conditional compilation statements like this :

 

The _layouts virtual directory now has a sneaky “15” in it

If you have any code that accesses the ‘_layouts’ folder using the virtual directory that gets added to every SharePoint IIS application, then you need to use the correct version. Look at the picture below, you will notice that’s there actually virtual directory inside of layouts called ’15’.

For an example of how this can effect you code – look below. This code is returning a Url to one of our pages that’s deployed to the layouts folder. If we had not made change to include the “15” it would have pointed to the 14 hive – which is good for a 2010 solution running on 2013, but not good for us.

What else has been deprecated in SharePoint 2013?

To see an extensive list of what’s deprecated in SharePoint 2013 – head on over to Technet

If you found this useful – I would be grateful if you could share it using the social buttons (at the top), or maybe even add a link to it.