1

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:

Assembly 'My.Common.SharePoint.Sandbox, Version=1.0.0.0, Culture=neutral, PublicKeyToken=0000000000000000' uses 'Microsoft.SharePoint, Version=14.900.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c' which has a higher version than referenced assembly 'Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c'

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).

Improve this question

1 Answer 1

Reset to default
0

You wan't Visual Studio to compile against the UserCode version of Microsoft.SharePoint.dll, but mark the assembly to use the standard one, because that's required by the UserCode service.

That functionality was introduced in "Visual Studio 2010 SharePoint Power Tools" and carried forward into Visual Studio 2012, but only for Sandboxed SharePoint projects.

As far as I see you have two options

  • Set visual studio to use the UserCode version, create postbuild event which builds using the real one, strong names, ...
  • Change your project to be a Sandboxed SharePoint project, but only use the dll and not the WSP package

My recommendation would be the latter.

Improve this answer
1
  • 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.
    – user4545
    Commented Aug 10, 2012 at 17:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.