0

Let me start off by saying that I know you can't install SharePoint 2013 on a Windows 7 machine (confirmed here). However my situation is this:

I am in the process of upgrading a large SharePoint 2010 intranet solution to SharePoint 2013. The application is hosted in SharePoint Online / Office 365 so consists entirely of sandbox solutions. For the moment, we do not have the capacity to rewrite the sandbox solutions as 2013 apps.

My current development machine is running Windows 7 and SharePoint 2010 (which I still need for supporting / developing other applications) and I am after the quickest & easiest way to use it for building my SharePoint 2013 sandbox solutions too.

I realize that re-imaging or dual-booting my laptop with Windows Server 2012 and SharePoint 2013 would solve my problems, but it certainly doesn't seem like the path of least resistance here!

So, I figured that if I copied the SharePoint 2013 assemblies to my machine (as you would when setting up a 2013 build server) then I'd at least be able to build the 2013 solutions locally and deploy / run them on my free Office 365 developer site. Is this feasible? I followed these steps to get this going

After changing the references in all my Visual Studio projects to point to the SharePoint 2013 assembly (and all the other steps listed here), I'm still getting the following build errors in Visual Studio 2012:

Assembly 'Xxx, Version=1.0.0.0, Culture=neutral, PublicKeyToken=xxxxxxxx' uses 'Microsoft.SharePoint, Version=15.0.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'

I assume this is because I still have SharePoint 2010 installed on my system. Can anyone shed some light on what I need to do to get my SharePoint 2013 solutions to build on my 2010 development environment?

Improve this question

2 Answers 2

Reset to default
1

It will likely be a lot easier to develop these as 2010 sandboxed solutions and deploy them to the 2013 site. Almost all 2010 solutions still work in 2013 and it even still has the 14 hive. If you need to develop each as an app that will be a little more work but that is not required for it to work in 2013. Even then an app is mostly packaging around a solution.

Improve this answer
2
  • Couldn't agree more Ryan! Although we'd hoped to "future-proof" our solutions now while we're still in the main development phase (as opposed to deploying 2010 solutions to our 2013 production tenant and then kicking off a separate migration project down the track). Also, we ideally want our application to inherit the new 2013 look 'n feel so we didn't want to run our sites in 2010 mode.
    – user4545
    May 15, 2013 at 4:46
  • So far each 2010 solution I have deployed has been able to deploy to 2013. They use the 2013 code and all run in 2013 mode. There haven't been any errors because not that much has changed in terms of the object model or the deployment process.
    – Ryan Erickson
    May 15, 2013 at 17:04
0

The SharePoint Dlls are referenced into your solution from 14 hive ISAPI folder. Have you tried copying the SharePoint 2013 Dll (Version 15.0.0.0) to a local folder and referencing it in your solution? If that doesnt work, can you push the same in GAC as well. Give it a try. For the moment just forget about 14 hive. Your solution should build.

Improve this answer

Your Answer

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