One solution to rule them all

My prezi is ready for SharePoint Saturday LA!
This session will be heavy on the visual studio live demo, hope that part goes well :)
But for the first part of the talk I thought I could use prezi to explain the challenge in building a solution that can be deployed on both SharePoint 2010 and 2013, without doubling the R&D efforts, QA efforts and overall maintenance.
We had a very long discussion about this in house, and we are still not entirely convinced this is the best solution to this problem, but it is the best we’ve got so far.
In the past we used to have 2 different solutions for each version of the product. This forced us to constantly sync code between the two versions, having to fix and retest every issue on both versions, which of course wasn’t done perfectly so we ended up with bugs that were fixed in one version only, features that were missing from the other version and basically it was very hard to maintain them.
Now, with the introduction of versioned root folders in SharePoint 2013 this have become a bit more challenging since the code would be different and target different folders in 2010 and 2013. While in server code its rather simple to test the version and use the right path, doing it in config xml files (like web part gallery icon, feature icon for example) is not something we can change in runtime.
This is why we came up with a set of tools that allows us to keep working on one solution, and producing 2 packages from the same source code in one build. One for SharePoint 2010 and the other for SharePoint 2013.
It didn’t take a long time before we then learned about the challenges in trying to debug this code on the SharePoint 2013 machine. Since it wasn’t build on that machine, and didn’t target the .NET framework 4 – this proved to be a bit more complex than what we expected.
To find out more on how we got everything working – come see my session!

Please feel free to leave a comment here if you want more info, or if you been to my session and would like me to add or change something.
Code sample:
http://sdrv.ms/14kRdt3

More info on deferred site collection upgrade:
http://kwizcom.blogspot.ca/2014/03/sharepoint-2010-deferred-site.html

Since I get asked a lot during this session, "are FTC solutions dead?"
Here is a short presentation with points to consider:

SharePoint 2010 Replaceable Parameters

Replaceable parameters is one of the nicest new features implemented for Visual Studio 2010 Tools for SharePoint 2010. I won't go into elaborate detail because this feature is well documented here, here, here and here, just to name a few places. What I do want to do is point out a few things that may help you avoid frustrations.

1. In a standard SharePoint 2010 project, ASMX files do not get parsed. What this means is that you would have to hardcode your assembly information in these files. But, as MSDN has pointed out here you can edit your csproj to include new file extensions.

GREAT! Now we can have files other than ASPX, XML etc. Our ASMX files, amongst others, are now parsed and the tokens are replaced.

2. When using the following parameters:

• $SharePoint.Type.<guid>.AssemblyQualifiedName$


• $SharePoint.Type.<guid>.FullName$

always ensure that the GUID is lower case. I spent hours trying to figure out why this parameter wasn't being replaced. This problem came about because most people, including myself, just used the GUID Generator. The GUID Generator returns uppercase GUIDS. Here is something that will save you time. In Visual Studio you can select the inserted GUID, hit CTRL + U and voila, you now have a lower case GUID. For example

<Assembly>$SharePoint.Project.AssemblyFullName$</Assembly>

<Class>$SharePoint.Type.cd59ef5a-3bc8-409d-ab43-d0a166168f9d.FullName$</Class>

[Guid("cd59ef5a-3bc8-409d-ab43-d0a166168f9d")]

3. SNIPPETS are an amazing feature when used in conjunction with the replaceable parameters. If you go here, download and install the snippets package, you can now right click and insert any of the replaceable parameters directly into your files. No need to look up or remember any of them! SWEET!

I'm not saying anything I've said here is ground breaking, but I'm just trying to save you some time. For me, being able to insert a GUID, make it lower case and then use a snippet to insert the token into my file makes my SharePoint development easier.