Some Background

I am working on a large project that is going to be deployed to SharePoint Online (i.e. Office 365), so all of my SharePoint projects have to be created as sandbox solutions.

As part of this, I've also created a single class library project in Visual Studio which contains some common SharePoint code (mainly extension methods and the like). This project is referenced by all my SharePoint projects in my Visual Studio solution.

The Problem

This setup works great provided my "common" class library project explicitly references the Microsoft.SharePoint.dll assembly in the "../14/ISAPI" directory. Of course the down side to this is that Visual Studio compiles my "common" classes against the full-featured object model and not the sandbox version (again, ALL of my SharePoint projects are sandbox solutions).

If I replace my "common" project's assembly reference with the Microsoft.SharePoint.dll assembly found in the "../14/UserCode/assemblies" directory instead (i.e. the sandbox version) then I get the following compilation error in Visual Studio 2012:

The error is fairly self-explanantory: the SharePoint assembly names in my "common" project is the same as those inside my SharePoint projects, however the version numbers now don't match. When marking a SharePoint project as a sandbox solution, the reference to the SharePoint dll isn't changed. It always compiles against the full-featured farm version! I've read some posts that say you should ALSO replace the default assembly reference in each of the SharePoint projects with the sandbox version -- but that you have to change it back before you do any release builds.

-- That's quite a lot of overhead and sounds very prone to error!

The Question

How can I get my "common" Visual Studio 2012 class library project to complile against the sandbox-version of the SharePoint 2010 assemblies?

UPDATE: Converting my "common" class library to a SharePoint project and then changing it to a sandbox solution does fix this problem, however it doesn't make any sense for this project to have it's own package and features as it can't ever be deployed on it's own. For one thing, sandbox solutions are not even able to call / be called by external assemblies (i.e. assemblies deployed by a different solution).

Thanks for your feddback, and for confirming my same thoughts (unfortunately!). I've had to change my references back to the regular SharePoint assembly, but we do periodically replace it with the sandbox version just to verify we don't have any bugs before we do a build / release.
–
Nick LarterAug 10 '12 at 17:45