In certain situation you want to allow that your SharePoint can utilize the new .NET 4.5 functions – this includes WebSockets for instance. In order to get his running, you have to change the web.config of the corresponding Web Application.
Disclaimer: Use this on your own risk and try it in a TEST or DEV environment first – the change can take down your SharePoint Farm or break core functions!
Manual approach
This is a step by step manual how to set the values that your SharePoint targets .NET 4.5 framework.
- Open the web.config with a text editor of your choice.
- Navigate to the element with the path /configuration/system.web/httpRuntime
- Add the attribute: TargetFramework=”4.5” to the httpRuntime element
- Save and don’t close the web.config yet.
After saving, your app pool reloads – everything should be fine by now.
Then try to open the Term Store Management on a site – AND BAM! Broken. At least the Term Store Management is a place I found that this change breaks – there could be others.
Did I mention that this manual approach is totally unsupported? An automated approach with the SPWebConfigModification class would be much better. But this is an example for the readers who made it this far (please leave a comment with your solution, thanks!)
A fix for the Term Store Management Tool
In order to get the not so unimportant Term Store Management Tool up and running, open the web.config again:
- Locate the element with the path: /configuration/appSettings
- Add this tag: UnobtrusiveValidationMode" value=“None” />
- Save and close the web.config
What happens is that the .NET 4.5 Framework introduces some handy ways to tell ASP that it should use unobtrusive validation – in other words html5 validation on input fields – and not validation with a postback/javascript.
How did I notice this?
Actually this was a coincidence. I tried to enable WebSockets for SharePoint 2013 and IIS 8 – and read that I had to change the TargetFramework to 4.5. Luckily I had the Term Store Management Tool open and coincidently refreshed the page – so the error had something to do with my previous change. In addition there is a quite useful error in the event log, so I found the fix rather easily.
Why bother?
So why do I write this? I think I will face this issue again in the future and someone has to write it down, right? And most importantly WebSockets in combination are pretty cool with SignalR – but that’s another story (or blog post for that matter!).
Issues with this?
Feedback or problems occurred after this change? Scroll down until you see the neat, little comment box!
Update 1: 6/19/2013: Apparently Target Framework 4.5 breaks Office Web Apps - currently I have no fix for this.
Share this post
Twitter
Facebook
LinkedIn
Email