As the latest .net framework is officially out you are definitely getting more determined to put your latest experiments out in the wild. No doubt it`d be beneficial to make use of those new features, optimizations and capabilities, but just not yet. SharePoint 2010 is close to official but even so - migration is to be faced in long term. We have to deal with existing setups on SharePoint 2007. So - does porting to .net 4 runtime worth it and how to achieve it.
Prerequisites
- Visual Stidio 2010 - the official release is free for evaluation, you can download it and give it a try
- .NET 4 framework runtime - obviously ..
- WSPBuilder ver 1.4 beta - a well known tool, pretty helpful if you want to leverage and speed-up working with SharePoint solutions
A small remark here goes to note that VS 2010 is targeted for SP 2010 solutions. You still have 2 projects for SP 2007 but they only consolidate building workflows. So inevitably we`ll have to rely on 3rd party tools. WSPBuilder is fairly useful and stable even in beta mode for the VS 2010 support. It`ll be used here after.
SharePoint solution example
Create new WSPBuilder project. Add new project item - visual web part. VS 2010 already have that template for SP 2010. It prepares for you a new webpart that loads a custom user control and a feature to deploy and setup all of that.
At this point you can succesfully package WSP, deploy and make use of your solution as usual. You`ve achieved usage of VS 2010. But we aim higher. So reach project properties and switch to .net version 4 compilation. At this point a web.config file will appear among the project files.
Once CLR 4 is targeted, you`ll get all the version 4 framework capabilities and extensions complied in .net 4 assemblies. Let`s take for our sample the Chart control, part of the asp.net 4 package. Place it on your user control and hook it up to a data source (alternatively you can download the source files provided).
And so we have our .net 4 solution ready. Lets face the configuration changes that will make it running.
At first of course we need to get the solution deployed. Fastest way goes through the "deploy" commant of WSPBuilder. But you can always deploy it the way you want. Just keep in mind that WSPBuilder (if you are using it) wont include in the output package any .net 4 assemblies, as it recognizes them as "unmanaged" code. So you`ll have to take care of assemblies deployment manually (eigher GAC or local bin folder of your web app)
"Copy to CAG" option works fine, just make a note that CLR 4 GAC is no longer at the same location, so verify for your deployed assmeblies in C:\Windows\Microsoft.NET\assembly\. The subfolder depends on the build type you are using - x86, x64 or MSIL for Any CPU.
When verifying for correct deployment, we`ll notice that the solution has been installed properly and even the feature may have been deployed, but not activated. That`s due to the fact that CLR 4 has totally different runtime engine than the present CLR 2. The legacy one cannot load assemblies compiled for version 4. Therefore on our current setup, SharePoint running on CLR 2 application pools cannot find the assembly pointed to contain the feature event receiver. Therefore feature fails to activate. If execution goes through the Central Admin application, even the feature deployment will fail. To overcome this, a SharePoint webapplication must be configured to run on the latest CLR version 4. For IIS 7 that goes through the application pool settings.
Once we switch an existing SharePoint web application to CLR 4, few additional settings are required in order to get it running.
Examining the web.config, there are few must have attributes that instruct the new runtime engine how to deal with a legacy application.
<compilation debug="true" targetFramework="4.0"><pages controlRenderingCompatibilityVersion="3.5" clientIDMode="AutoID"><trust level="Full" originUrl="" /> - other security levels lead to issues, so this one is to be used temporarily
Browser support happens to be another issue stacked on the incompatibility list. Launching the site with the properly configured web.config will get you to a error screen, describing a weird configuration error. To prevent this for a tryout you can remove the compatibility descriptor file at ..\inetpub\wwwroot\wss\VirtualDirectories\xx\App_Browsers .. Of course it`ll leave you only on IE support.
Including the Chart control in out solution brings few more complexities marked in the web.config. Usually in practice those changes go through code, but for that sample you can manually merge the web.config file in your solution with the one of your web application. Few additional changes are also made in the provided solution files, in oder to allow sql data source to bind to a visual control through integrated security.
Once you have the configuration file properly extended, your site will load up same as before. CLR 4 would be in charge, and the freshly provided webpart that includes a chart control will load up smoothly.
At this point it`s up to you to decide whether to upgrade your existing solutions to .net framework version 4 and accordingly your SharePoint environments. Justification is quite subjective, as the most important change that must take place is the web application (pool) switch to CLR 4.
The solution sample is available for download (free registration required).
No comments:
Post a Comment