SharePoint 2013/SharePoint 15 to run on .NET 4.0 Runtime

I’ve been keeping hundreds of subscribers updated on what’s going on in the SharePoint 2013 news scene over the past few months. In addition, I’ve been deep diving into the released protocol documentation to describe new features of SharePoint 15.

If you’re interested in obtaining a subscription, priced at $14.95 for the entire series (monthly issues, 25-35 pages each), head over to

Regardless of the paid options, I’ve been posting information on SharePoint 2013 on my blog too, so feel free to check out the SharePoint 2013 tagged articles for updates.

This excerpt appeared in issue 4, published in early April 2012.

SharePoint 2013 uses .NET 4.0 Runtime – Prepare Yourself!

In the previous issue, I wrote about my thoughts and findings around the .NET version of SharePoint 2013. As you may remember, my conclusion was that I thought Microsoft would leave the current .NET version alone and go with the 2.0 runtime.

(Web note: In the March issue, I speculated that Microsoft would want to maintain a single .NET runtime version for all its SharePoint versions. At the time, I did not have any hard facts, so I elaborated on the reasoning behind the argument)

Right after I published the previous issue, a reader tipped me that, although the reader thought my reasoning was correct, the conclusion was wrong. According to the tip, SharePoint 15 runs on .NET 4.0.

Now, I considered emailing all subscribers immediately, but I wanted to verify the claims of the tipper. Sadly, I haven’t been able to accurately do so, and the people who know are keeping their lips more tightly sealed than ever.

Note: Since publishing the April issue, several other readers have said the same thing, including one person ‘in-the-know’ confirming that SharePoint 2013 is based on .NET 4.0 Runtime.

Assuming that my reader is correct, and I have no doubt that this is the case, this is a huge deal for SharePoint developers, both for those that work on projects and for component developers.

If you’re completely foreign to development, you can view the following discussion as one of compatibility between two versions of the .NET runtime. The .NET runtime is responsible for executing the code that developers write to interact with SharePoint.

Despite there being numerous .NET Framework versions, there are only two runtime versions, .NET 2.0 and .NET 4.0. The problem arises from the fact that .NET 4.0 is backward compatible, with some major caveats for SharePoint developers, and that .NET 2.0 is not forward compatible.

Let’s look at what this means for future developers.

First, because SharePoint 2013 requires .NET 4.0, and .NET 2.0 won’t run .NET 4.0 code, this means that any code written to interact with SharePoint 2013 will not work on previous versions. This means that developers who want to support both current and future versions of SharePoint will need to maintain two sets of code.

So, why can’t you just run the current .NET 2.0 code in the .NET 4.0 runtime? After all, I did mention that .NET 4.0 is backwards compatible. If you write your code for .NET 2.0, you could simply load that code into the .NET 4.0 runtime and you’d be set, right?

It’s not that simple, I’m afraid. Microsoft, in its infinite wisdom, has added code to explicitly prevent SharePoint 2010 to work with .NET 4.0 runtime. SharePoint 2007 simply won’t work and you will not be able to connect to any site if you use .NET 4.0.

Finally, because .NET 2.0 can’t load .NET 4.0 code (it’s not forward compatible, remember?) you also cannot write.NET 2.0 code to connect to SharePoint 2013.

These conditions mean that you will have two distinct development platforms; one that targets SharePoint 2010 and 2007, and one that targets 2013 and future versions. (At least until Microsoft puts a new runtime version out and upgrades SharePoint 2016 to that 🙂 )

Obviously, this impacts the cost of development of new code that attempts to work on both SharePoint 2013 and earlier versions. Technically, you can write code that is simple to switch between .NET 2.0 and .NET 4.0. If you wrote only code that worked in both versions, it would simply be a matter of changing the target framework in Visual Studio and recompile.

However, reality won’t be that easy. If you start doing development on .NET 4.0, you want to take advantage of the added benefits of that version. Otherwise, what would be the point? Well, if you do, you’ll have to maintain two different versions of your codebase and make sure that any changes you make are added to both versions. Although there definitely are methods you can use to make your code more portable, it will still increase the burden on developers and ultimately the cost to customers.

Of course, it may be that Microsoft has some tricks up their sleeves, but considering the minor but significant incompatibilities between the various .NET runtimes and SharePoint, I’d much rather prepare for the worst and assume it will be two separate target environments from now.


This has been an excerpt from the SharePoint 2013 Beta series of USP Journal. To pick up a subscription that costs $14.95, including access to all back issues, head over to

As always, treat any unofficial information as pure speculation and don’t make any important decisions based on this.

Found this article valuable? Want to show your appreciation? Here are some options:

a) Click on the banners anywhere on the site to visit my blog's sponsors. They are all hand-picked and are selected based on providing great products and services to the SharePoint community.

b) Donate Bitcoins! I love Bitcoins, and you can donate if you'd like by clicking the button below.

c) Spread the word! Below, you should find links to sharing this article on your favorite social media sites. I'm an attention junkie, so sharing is caring in my book!

Pin It

Published by

Bjørn Furuknap

I previously did SharePoint. These days, I try new things to see where I can find the passion. If you have great ideas, cool projects, or is in general an awesome person, get in touch and we might find out together.

9 thoughts on “SharePoint 2013/SharePoint 15 to run on .NET 4.0 Runtime”

  1. Are you sure about ‘stuff’ compiled in .NET2 for 2010 not working on .NET4 under 201X?

    It’s very unusual for MS not to make things backwardly compatible (obviously with caveats for breaking changes). For example even today you can take a webpart compiled against .NET 1.1 for SharePoint 2003 and have it run OK on 2010.

    1. I think you read it the wrong way. .NET 4.0 is backwards compatible, but .NET 2.0 isn’t forwards compatible. You can build .NET 2.0 stuff and run it in .NET 4.0.

      However, you can’t take advantage of .NET 4.0 features if you want an easy (swap DLL references) way of supporting .NET 2.0 (like SP 2010 and 2007).


      1. Thats exactly what I thought – but not what I get from your article.

        Read the paras starting “So, why can’t you just run the current .NET 2.0 code in the .NET 4.0 runtime?” and ending “you also cannot write.NET 2.0 code to connect to SharePoint 2013”

        Maybe its late for me but I think it isn’t clear what you’re saying there.

        All the best…Ryan

        1. Well, it’s the intricate details of the .NET framework. Code written for .NET 2.0 can run in the .NET 4.0 runtime, but the .NET runtime 2.0 cannot run the code required to connect to SP2013. In other words, if you want to write for SP2013, you need to use the .NET 4.0 runtime, but that means you cannot connect to SP2010.

          You can write .NET 2.0 code to run in the .NET 4.0 runtime and use the same code to connect to SP2010/2007, but it would essentially mean you give up on all the benefits of .NET 4.0, so the point of upgrading the runtime would be lost.


          PS: It’s not known whether SP2013 will even allow you to connect to it with .NET 2.0 assemblies. SP2010 explicitly denies .NET 4.0 runtime, so it’s not inconceivable that Microsoft pulls a similar stunt this time and bans .NET 2.0 access completely.

  2. Wow, I’ve never been called out on Twitter to coment on a blog before. I said that reading things like this make me shake my head. I didn’t post that comment here, becasue I really don’t develop in or against SharePoint in a way that is affected by this. Most of my development is in the form of fat or fatter client applications running against SQL Server. Today, I am using Smalltalk, and if I need to access SharePoint, I do it with web services. We own Visual Studio, and I’ve come close to embracing it several times, but each time, some Microsoft decsion scared me away. I haven’t worked in the environemnt enought to speak with anything close to authority, but articles I’ve read seem to indicate that for the past 12-14 years, maybe longer, version compatibility is a weak spot that Microsoft doesn’t care to address, It also seems that they are reluctant to define a clea roadmap. On the other hand, I habe large complex systems that were developed in VisualAge Smalltalk v4 on Windows 95 that run well on Windows 7 and can be edited, maintained and enhanced by VisualAge v8. I know, it’s an obscure language, but I seriously wonder if something I wrote in 1998 in Visual Whatever would still be running today or if I could even access the code.

    I read this post and the word that comes to minde first is “arbitrary”. Maybe I’m ignorant, but is sounds to me like there may not be specific reasons why the problems you describe have to be. the last time I returned to Visual Studio was when SharePoint was 2007. The version of Visual Studio that shipped to me cou;dn’t work with SP 2007, and I was told to load the earlier version. We actually bought a 2nd copy of SQL Server, so the version running SharePoint would never be the version we store our structured data in. I never wanted to face having to make a decision to upgrade or not based on what SharePoint needed vs. what the new version of Visual Studio needed (or have to sacrifice features I wanted to use). It bothers me that developers get treated this way and it scares me because I have to make promises for a future that I don’t control. Hence the head-shaking.

    Feel free to tell me I am wrong, calm me down and pull me back from the ledge,

    1. D,

      Please, calm down. Come down from the ledge, it’s not worth it. Think about your family!

      On a more serious note, it sounds to me likeyou’ve gotten som pretty bad advice easlier. Unless you were using Visual Studio 2003, you can build .NET assemblies for any current version of SharePoint. I touched briefly on this in my post on why versions and tools do not matter:

      There’s a major difference between the tool that builds the code and the compiled code itself. All Visual Studio does is make it easier for you to produce code, but compiling it is not related to Visual Studio at all. You can easily build code in any version of any program (althoug I’d stay away from Excel and Photoshop) and simply compile it yourself.

      I’m sure that technically you could even get Visual Studio.NET to build for SP nowadays, but it would probably be more of a hassle to set up than you’d actually save by not upgrading.

      It seems to me that you’ve fallen into the pitfall that I describe in the above article; your tasks have been so tied into the tool you use that without the tool (and the right version of the tool) you are powerless.

      Don’t be! It’s just three years ago that I upgraded from Visual Studio 2005 to 2008, and I still haven’t upgraded my SP dev environments to VS 2010. I will have to when I build SP2013 solutions, but that’s only because VS2008 won’t work with .NET 4.0.

      Ultimately, though, I know how to make stuff work without VS, so all VS offers at this point is convenience, not a dialysis machine on which I’m completely and utterly dependent.


  3. Hi,

    If they are using .NET 4.0, which I hope, then most likely they are using the new Workflow engine inside that too.
    If they do not allow .NET 3.5 (.NET 2) access then all the Workflows will have to be rebuilt.

    I remember in 2009, when SP2010 was in beta and .NET 4.0 was RC, when I asked them why we use VS2010 for development which requires .NET 4 but SP2010 does not support it the response was that they had to choose a stable framework and they could not take the risk to use .NET 4 which was in beta just few weeks before.

  4. hi
    will we be able to run sharepoint 2010 custom solution in sharepoint 2013? i.e. be able to deploy the same wsp files into the 2013 farm and expect it to work assuming the api’s all are still valid.

    1. Although we can’t say for certain, because .NET 4.0 can load .NET 2.0 code, I am thinking that it is very likely that you will be able to run existing code. What you will need to do is recompile the assembly with the new SharePoint DLLs if you use it. For straight .NET webparts (ie not SharePoint web parts), you may be able to get away without any recompilation.


Leave a Reply

Your email address will not be published.