Packaging and Deployment – ‘missing types’ compiler errors using Visual Studio 2012 and SharePoint 2010 tools

For a while now, the team and I have been dealing with a odd behavior in Visual Studio 2012 and SharePoint 2010, disruptive to the point that I actually scripted out the whole build and packaging process from the command line just to package up our WSPs (SharePoint packages).  Basically it happened like this… we has a solution with a combination of Class Library projects and SharePoint projects, and were able to compile the projects individually or as a solution in Visual Studio, but when trying to package or deploy them to SharePoint via Visual Studio we would receive a variety of errors about missing types.  These missing types were all part of the class projects that were referenced by the SharePoint projects, providing a variety of utility classes and such, which all compiled fine when simply doing a build, but were reported as missing when we attempted to create SharePoint packages.

Well with no useful information from Visual Studio, the issue just sat on the side lines until either time or frustration found me.  The fact that we could compile from the command line using MSBUILD only added to the confusion, but gave us an opportunity to ignore the issue as long as possible.  But alas, all good things must come to an end, and I found myself in a situation where I needed to actually deploy from within Visual Studio, and so I looked again at the issue.

Well with a bit of speculation, and some criticism of the SharePoint tools for Visual Studio, here’s what seemed to be going on.  The SharePoint project templates and tools are designed for moving forward, and are not friendly to changes or reworking.  This is obvious in the management of features and packages, with the unfriendly two column UI for adding and removing items.  An important thing in SharePoint packages is sequence, however only one of the many item list in the SharePoint tool UIs provides buttons for reordering and unfortunately this is not the one.  In the case of this issue, it appears to be the package additional assemblies.  As time went by and code was refactored and moved to enhance reuse and organization, more project assemblies were added to the various packages.  However, the sequence of the assemblies isn’t easy to manipulate and can intermittently cause issues packaging issues when code a lower level project is changed, as the project additional assemblies appear to be recompiled during packaging either in a weird order or with weird references.

Without spending an inordinate amount of time looking into exactly why, what seemed to help mitigate the issue, was to open the package files in notepad and reorder the additional assemblies such that they would be added in the same order that they would naturally be compiled.  This seemed to clear up the issue, allowing to the SharePoint package projects to be published and deployed again.

So the lesson here would seem to be, make sure you monitor and reorder your package additional assemblies…

Feature contents is another one to watch for order, but that’s a different story.