How to Extend SharePoint 2007 with .NET 3.5
There are several solutions in web that deal with this problem, but they all seem to point you to use SPWebConfigModification (like in here and here) or are just giving manual editing instructions (like in here). We feel that this is all too complex and repetitive process. There is fortunately “a better” way to do this.
First of all, you have to install .NET Framework 3.5 on every SharePoint machine on a farm. (Download Microsoft .NET Framework 3.5 Service Pack 1).
(Optional) Next create a wsp-package with a following manifest:
<Solution SolutionId="{ID}" xmlns="http://schemas.microsoft.com/sharepoint/">
<RootFiles>
<RootFile Location="CONFIG\webconfig.net35.xml" />
</RootFiles>
</Solution>
Download the needed webconfig.net35.xml file.
Then you just install your wsp-package and that’s about it. If you skipped packaging part of this, you can copy the webconfig.net35.xml file directly to 12\CONFIG directory.
To activate the modifications you can run this command:
C:\stsadm -o copyappbincontent
If you want to activate the modifications by a Feature, you can add the following code to your feature receiver:
var localContent = SPWebServiceInstance.LocalContent;
if ((localContent != null) && (localContent.Status == SPObjectStatus.Online))
{
SPWebService.ContentService.ApplyApplicationContentToLocalServer();
}
// Code for SharePoint Central Administration Web Application
// (not needed here):
/*
localContent = SPWebServiceInstance.LocalAdministration;
if ((localContent != null) && (localContent.Status == SPObjectStatus.Online))
{
SPWebService.AdministrationService.ApplyApplicationContentToLocalServer();
}
*/
Easy? I think so.
Of course you can use this same technique to push whatever changes you need to push to your web.configs without reverting to ugly SPWebConfigModification code. But beware, this method does make the change global. I.e. the changes are made to all your web applications. I think that it is just fine for common technology like .NET 3.5 to have it globally applied, but YMMV.
UPDATE: See this article if you also need your inline code compiled with .NET 3.5.
Any comments?
Popularity: 1% [?]
Nice article! A few issues I’d like point out here – first, using copyappbincontent is a nice approach but it has two ramifications: First, if you run multiple upgrades to your solution with a batch file it fills your web.config file with duplicate entries and this might cause problems. This is painstakingly obvious when someone else is actually doing deployment for you. Secondly, copyappbincontent has to be executed on each WFE in the farm – kind of defeating the purpose of using an all-around WSP to deploy stuff globally
Finally, I’ve seen so many issues in customer environments where developers have tried to modify web.config files programmatically either in a feature receiver or via a custom vehicle such as a Windows installer. This tends to put cached copies of web.config to the config database and will often cause ridiculous problems in later phases.
Thanks for the reply! According to our test, this method should not create duplicate entries. But you are right that the command has to be run on each WFE in the farm – that is a drawback. However, it seems that using ApplyApplicationContentToLocalServer() web service call might do it globally. Maybe Aapo can comment on that?
Cached copies of web.config is generally a bad thing. However, in this case if the solution depends on .NET 3.5 so it would be elegant to add only the required lines to web.config somehow, but not to store the whole web.config somewhere.
Agreed. I’ve had some serious issues with several environments with SP2 but not the latest CU’s with copyappbincontent. Web.config works fine with multiple entries but custom features often encounter problems that are hard to catch.
Didn’t try this yet. But I suppose it would work, assuming / hoping that it would not do multiple entries but function as a “checkpoint” to ensure the entries. One would have to test for that then.
Personally, I have used a manual approach and winmerge with a sample webconfig file for servers of each role. Thus, it is actually interesting to see the differences in servers versus the expected contents of web.config, as this gives insight into what different servers set up by different customers / vendors actually contain before adding the information.
Frequently, I find erroneous configs left behind telerik and other components installations that require .net 3.5, but apparently do not require every single setting. And the telerik chm files contain lots of manually copiable content for your web.configs, which I would agree is quite dangerous.
On the plus hand, manually using winmerge gives insight into the differences and what was actually done to change the file.
On the minus side, winmerge is not good if the files differ too much. And, it is still partially manual labor.
I guess if this solution actually works 100%, and is reliable not to produce duplicates, then I would perhaps even lean towards it.
Interestingly, especially, Microsoft has not made any statements towards best practices, and this is an area where a standardized means of going reliably from “any web.config” where all the farm servers have .net3.5[.1?] installed, to “reliably having the web config settings for 3.5 framework” installed, would be greatly beneficial.
Does the uninstall work reliably as in producing a webconfig that is rolled back regarding the changes, under june2010 CU?
[...] can also use WebConfigModification classes or server-wide web.config merging to make this change in [...]