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 http://sharepoint2013beta.com/.
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 http://sharepoint2013beta.com/
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!