SharePoint 2007 and the Thin .NET 3.5 Development Model Merge your SharePoint development with WCF to work around some of SharePoint 2007's problems and enable the thin .NET development model.
hile flying back home over the Atlantic, I thought about how much better developing for SharePoint has become after the introduction of .NET 3.5. I have repeatedly insisted that one of the reasons behind SharePoint 2007's huge success is the application of ASP.NET 2.0 concepts to SharePoint.
This article provides a brief introduction to the specific improvements that .NET 3.5 brings to the SharePoint 2007 platform, and how those have improved my development life.
I was just one of many scratching their heads when Soma announced that Indigo, Avalon, etc. would be named .NET 3.5. I've said it before, and I'll say it again: I am convinced that there is a department at Microsoft whose sole job is to give bad names to good products. Count me firmly entrenched in the camp of people who feel .NET 3.5 is a misnomer. .NET 3.5 is based on CLR 2.0, so it is really .NET 2.0 with a whole bunch on top. But, history cannot be rewritten, so we're stuck with that name.
Since SharePoint 2007 is really built on ASP.NET 2.0, SharePoint 2007 suddenly got a whole lot better with the introduction of .NET 3.5.
WCF in SharePoint
SharePoint 2007 doesn't support WCF out of the box, and as of the writing of this article, Microsoft hasn't introduced official support for WCF in SharePoint, either. But often, the true beauty of Microsoft products lies in their extensibility. Using a combination of a custom VirtualPathProvider and an HttpModule, you can easily add WCF support to any SharePoint web site (see more information here).
Alternatively, you can simply download the Winsmarts.WCFSupport feature. This is a web-site-level feature that you can activate on any web site, and voila—you have WCF support—just that simply!
What do you get by enabling WCF support? I am not sure what came first, shrinking IT budgets, crazy deadlines, or the thin .NET 3.5 development model. But with WCF, you have the ability to encapsulate logic in a true SOA form, and then expose and consume it using various technologies, including thick clients, ASPX code behind, Silverlight clients, or even—believe it or not—JavaScript. This is the thin .NET 3.5 development model, which greatly increases your productivity. But applying it to SharePoint greatly increases productivity, code reliability, and the quality of your development experience.
The Old SharePoint 2007 Development Story
Let me make my case with an example. Suppose you wanted to author an ASPX, and put it in the layouts folder; otherwise known as an Application Page.
What are your choices?
You could author the page using an ASPX and a code-behind class. You could put the code-behind class in the bin directory where the DLL is running under some sort of CAS (code access security) policy that you create. This sounds textbook-perfect—until you actually try crafting a CAS policy yourself. It takes a lot of trial and error to come up with a CAS policy that contains exactly what your page needs and absolutely no more. (And you know what "Trial and Error" means: That if hackers try hard enough, they will expose an error.)
So, putting the DLL in the bin directory isn't such a great choice. You could put the code-behind DLL in the GAC. But to develop such a DLL, you would have to develop on a machine that had SharePoint running, and debug a GAC DLL inside the SharePoint context. To do that, you'd attach to the w3wp.exe process, but then you have the problem of knowing whether the DLL you compiled is the same version that exists in SharePoint, and whether it's the same version that IIS is using. You have to do some work to discover why your breakpoints aren't getting hit, and why the SharePoint context seems to time out so mysteriously.
Okay, so code-behind in either DLLs or the GAC isn't an ideal choice. You could use inline code in the ASPX file. Yes, I know this isn't classic ASP, but it stinks terribly of it. Inline C# in an ASPX will require you to deploy C# code in production, makes it difficult to see all your code, and IntelliSense in ASPX files sometimes goes for a walk.
These problems, while not insurmountable, are exactly the types of problems that make development tough. So far, you have three choices, none of which are good. What should a SharePoint developer do? Simple—embrace the thin .NET 3.5 development model.
This article provides a brief introduction to the specific improvements that .NET 3.5 brings to the SharePoint 2007 platform, and how those have improved my development life.
I was just one of many scratching their heads when Soma announced that Indigo, Avalon, etc. would be named .NET 3.5. I've said it before, and I'll say it again: I am convinced that there is a department at Microsoft whose sole job is to give bad names to good products. Count me firmly entrenched in the camp of people who feel .NET 3.5 is a misnomer. .NET 3.5 is based on CLR 2.0, so it is really .NET 2.0 with a whole bunch on top. But, history cannot be rewritten, so we're stuck with that name.
Since SharePoint 2007 is really built on ASP.NET 2.0, SharePoint 2007 suddenly got a whole lot better with the introduction of .NET 3.5.
WCF in SharePoint
|
Alternatively, you can simply download the Winsmarts.WCFSupport feature. This is a web-site-level feature that you can activate on any web site, and voila—you have WCF support—just that simply!
What do you get by enabling WCF support? I am not sure what came first, shrinking IT budgets, crazy deadlines, or the thin .NET 3.5 development model. But with WCF, you have the ability to encapsulate logic in a true SOA form, and then expose and consume it using various technologies, including thick clients, ASPX code behind, Silverlight clients, or even—believe it or not—JavaScript. This is the thin .NET 3.5 development model, which greatly increases your productivity. But applying it to SharePoint greatly increases productivity, code reliability, and the quality of your development experience.
The Old SharePoint 2007 Development Story
Let me make my case with an example. Suppose you wanted to author an ASPX, and put it in the layouts folder; otherwise known as an Application Page.
What are your choices?
You could author the page using an ASPX and a code-behind class. You could put the code-behind class in the bin directory where the DLL is running under some sort of CAS (code access security) policy that you create. This sounds textbook-perfect—until you actually try crafting a CAS policy yourself. It takes a lot of trial and error to come up with a CAS policy that contains exactly what your page needs and absolutely no more. (And you know what "Trial and Error" means: That if hackers try hard enough, they will expose an error.)
So, putting the DLL in the bin directory isn't such a great choice. You could put the code-behind DLL in the GAC. But to develop such a DLL, you would have to develop on a machine that had SharePoint running, and debug a GAC DLL inside the SharePoint context. To do that, you'd attach to the w3wp.exe process, but then you have the problem of knowing whether the DLL you compiled is the same version that exists in SharePoint, and whether it's the same version that IIS is using. You have to do some work to discover why your breakpoints aren't getting hit, and why the SharePoint context seems to time out so mysteriously.
Okay, so code-behind in either DLLs or the GAC isn't an ideal choice. You could use inline code in the ASPX file. Yes, I know this isn't classic ASP, but it stinks terribly of it. Inline C# in an ASPX will require you to deploy C# code in production, makes it difficult to see all your code, and IntelliSense in ASPX files sometimes goes for a walk.
These problems, while not insurmountable, are exactly the types of problems that make development tough. So far, you have three choices, none of which are good. What should a SharePoint developer do? Simple—embrace the thin .NET 3.5 development model.
No comments
Post a Comment