As you might now, SharePoint 2013 comes with a native support of 2010 based solutions & user experience. It ships with two different paths such as:
- Two different GACs. 2010 packages still deploy to the .NET 2/3/3.5 GAC while 2013 packages deploy to the .NET 4 GAC
- Two physical locations for the TEMPLATE folder in 14 & 15
- Some extra virtual directories in IIS to target either 14 (default) either 15 (explicit inclusion)
It clearly means that some solutions can be reliably deployed “as is” in 2010 format onto a 2013 farm. For packages that deploy files to another location than TEMPLATE, the solution framework will deploy them in the 15 root…which is kind of mixing things and prooves that the 2010 mode isn’t completely isolated from 2013.
But let’s come back to the topic of this post, a tip regarding custom field types. Did you know that if you migrate a 2010 custom field type “as is”, so meaning, you didn’t even repackage the solution. Its files will be deployed to the 14 root and I’m more thinking of the FLDTYPES…kind of files.
However, despites of the fact that they are deployed against 14/TEMPLATE/XML, those field types will also show up for 2013 based sites and are unlikely to work since the rendering engine is now based on Display Templates.
I don’t know whether it’s a bug or a “by design” thing but it is kind of confusing and annoying. If you want to migrate “legacy sites” onto a new infrastructure just so that you don’t pay two different infrastructures but you don’t want to invest in adapting the old solutions, that kind of bad surprises is a bit annoying.
Moreover, the same does not apply to custom site definitions where SharePoint only shows up 2010 like definitions for 2010 like sites. Even with PowerShell you can’t create a site based on a 2010 definition within a 2013 parent site while it works fine within a 2010 parent site.