SharePoint — Integration with ASP.NET
Introduction:
We’ve seen integration with IIS, now let’s take a look at integration with ASP.NET. SharePoint 2013 is built on top of the .NET framework 4.5 and ASP.NET WebForms. We’ll cover ASP.NET integration from two viewpoints. We’ll start by looking at how IIS websites are extended to become SharePoint web applications. Later in this module and also in the modules where we cover SharePoint development, we’ll see how the other features of ASP.NET are used within SharePoint. In this module, we’ll be building site and application pages, these are ASPX pages and we’ll see how SharePoint uses master pages, server controls, and data binding. One final note before we move on, one question I get asked quite regularly, particularly when I mention that SharePoint is built on top of WebForms, is what about ASP.NET MVC? You may have heard that you can use MVC with SharePoint 2013 and that’s sort of true, but not really true. SharePoint is built on top of WebForms, so anything you build using the traditional solutions model like pages, web parts, user controls, and so on, those all have to be built on top of WebForms. But with the new SharePoint 2013 app model, you can integrate external sites with SharePoint and those external sites can be built using any web technology you want including ASP.NET MVC. So yes you can use MVC with SharePoint, but again, that site lives external to the SharePoint server. Alright, so now let’s move on to the demo of ASP.NET integration with SharePoint 2013.
Integration with ASP.NET:
we’ll take a partial look at the integration between SharePoint and ASP.NET. We’ll just be looking at the global.asax file and web.config file for the web application.
Now we will open Visual Studio and then start with the global.asax file for the web application we just created, that’s this guy here, and there’s not a lot to see in this file. Basically what SharePoint does is it tells ASP.NET not to use the default application object, but to use the one defined by this type in the SharePoint server object model.
Now open up the web.config file and there’s a lot of stuff in here. This section sets up a bunch of custom configuration sections in the web.config file that are specific for SharePoint.
we’ll see this section here called SharePoint and that’s where the settings for those configuration sections are set. And what I want to call out is SafeControls. So basically any assembly that has the code-behind for pages or the implementation of controls or web parts, has to be marked as Save before it can execute inside of SharePoint and we do that by adding a SafeControl entry.
So basically any assembly that has the code-behind for pages or the implementation of controls or web parts, has to be marked as Save before it can execute inside of SharePoint and we do that by adding a SafeControl entry. Now I call this out, because in your Visual Studio projects, if you create a user control or you create a web part, a SafeControl entry has to get added to the web.config. Now normally, Visual Studio and the SharePoint Solutions Deployment model handle this for you automatically, but as with everything else that gets handled for you automatically, sometimes things don’t work. So you might have to go into the web.config file and take a look at the SafeControl entries and see if the one that you need has been properly added, so that’s why I called that out here.
Now scroll down to system.web, and now come down to system.web and we will see three things here and in the previous section. So here we see the settings for production server and customErrors are marked as On and then under compilation, debug is marked as false and then up here further in SharePoint under SafeMode, CallStack is marked as false.
1- CustomErrors
2- Debug
3- Call Stack
So with this configuration, you’re going to get the standard SharePoint error pages and these pages are designed to be very nonthreatening to users and part of them being nonthreatening is that they don’t contain CallStacks and they don’t contain cryptic error messages and that means they’re not really that valuable to developers.
Our Modification:
So one of the first things that you want to do in your developer environment is configure the web.config for debugging and to do that, it’s three changes. You set CallStack here to be true, that’s in SafeMode under SharePoint, and in the system.web you change custom Errors from On to Off, and under compilation you set debug to true. And once you do that, for a lot of Runtime errors in SharePoint you’ll get the sort of standard ASP.NET error page. Now there will be times, particularly when there’s an error in page load, that you don’t really get any valuable information, but for a lot of the standard cases you will. And there are a couple more things I want to point out.
If we scroll down here, notice the trust level is set to Full, so basically all .NET code that executes on the server is running under full trust, and let’s finish up looking at the modules and handlers. So we see there’s no handlers set here.
For modules under system.web, there are four all related to authentication and then if we scroll down to the system.web server, there are some additional modules configured here. Several of them are specific to SharePoint and there’s also some additional handlers set up here as well. So that’s a really quick look at the web.config and the global.asax files and as I mentioned at the beginning, the remainder of the integration with ASP.NET will be shown in the demos throughout the remainder of the course.
