Posts Tagged ‘ASP.NET’
SP 2010: Developing for performance Part 8 – Control that ViewState
August 16th, 2011 by Tobias Zimmergren
Author: Tobias Zimmergren
http://www.zimmergren.net | http://www.tozit.com | @zimmergren
Introduction
SharePoint 2010 developing for performance article series:
In this series of articles I will briefly introduce you to some key concepts when it comes to developing for performance in our SharePoint 2010 applications.
Related articles in this article series
Part 1 – SP 2010: Developing for performance Part 1 – Developer Dashboard
Part 2 – SP 2010: Developing for performance Part 2 – SPMonitoredScope
Part 3 – SP 2010: Developing for performance Part 3 – Caching in SharePoint 2010
Part 4 – SP 2010: Developing for performance Part 4 – Logging
Part 5 – SP 2010: Developing for performance Part 5 – Disposal patterns and tools
Part 6 – SP 2010: Developing for performance Part 6 – CSS Sprites
Part 7 – SP 2010: Developing for performance Part 7 – Crunching those scripts
Part 8 – SP 2010: Developing for performance Part 8 – Control that ViewState
Part 8 (this article):
As most of you know, in any ASP.NET project (SharePoint included) there’s something you know as ViewState. With the ViewState we can persist state of our properties in the page controls and objects across postbacks that happen in our solutions. If we are not careful and plan the usage of ViewState properly, we can end up with a performance hit that will slightly decrease the performance in the page rendering process.
In this article we will take a look at what impact the ViewState can have if we “forget about it”, and of course how we can prevent our pages from being unnecessarily big in page size.
ViewState in our SharePoint projects
If you’ve been developing SharePoint projects of any type, you’ve most certainly been doing some kind of asp.net UI development as well. (Application Pages, Web Parts, User Controls and so on) that are inheriting the asp.net capabilities and hence the ViewState.
What you should know as an ASP.NET developer: Be sure to know when you should, or shouldn’t use the ViewState. You can disable the usage of ViewState for certain components, or the entire page.
Performance considerations
With an increased ViewState you get an increased Page Size which in turn obviously means that the page will take a bit longer to render.
We’ll take a quick look at how the performance can differ when we’re using ViewState and when we’re disabling the ViewState in a SharePoint project.
Taking a look: ViewState
In order for us to really understand what impact the ViewState can have on the page rendering process, we’ll dig into the details of the what the ViewState looks like. To do this we can check out the source of the rendered page, and of course we’ll rely on our faithful squire; Fiddler2.
Before we’ll start digging with the Fiddler2-application, we can simply check the Page Source of any given page being rendered and we’ll most likely find a heap of ViewState madness going on in there.
In my sample application that only consist of a simple GridView control and a few rows of data – the ViewState is turned into this:
<input type= "hidden "
name= "__VIEWSTATE "
id= "__VIEWSTATE "
value= "/wEPDwULLTE5NjIxMzI1MDIPZBYCZg9kFgICAQ9kFgQCAQ9kFgICDw9kFgJmD2QWAgIBD
w8WAh4HVmlzaWJsZWdkZAIDD2QWBgIRD2QWBGYPZBYEAgEPZBYCZg9kFgQCAg9kFgYCAQ8WAh8Aa
GQCAw8WCB4TQ2xpZW50T25DbGlja1NjcmlwdAVdamF2YVNjcmlwdDpDb3JlSW52b2tlKCdUYWtlT
2ZmbGluZVRvQ2xpZW50UmVhbCcsMSwgMSwgJ2h0dHA6XHUwMDJmXHUwMDJmc3BmJywgLTEsIC0xL
CAnJywgJycpHhhDbGllbnRPbkNsaWNrTmF2aWdhdGVVcmxkHihDbGllbnRPbkNsaWNrU2NyaXB0Q
29udGFpbmluZ1ByZWZpeGVkVXJsZB4MSGlkZGVuU2NyaXB0BSFUYWtlT2ZmbGluZURpc2FibGVkK
DEsIDEsIC0xLCAtMSlkAhUPFgIfAGhkAgMPDxYKHglBY2Nlc3NLZXkFAS8eD0Fycm93SW1hZ2VXa
WR0aAIFHhBBcnJvd0ltYWdlSGVpZ2h0AgMeEUFycm93SW1hZ2VPZmZzZXRYZh4RQXJyb3dJbWFnZ
U9mZnNldFkC6wNkZAIDD2QWAgIBD2QWAgIDD2QWAgIBDzwrAAUBAA8WAh4PU2l0ZU1hcFByb3ZpZ
GVyBRFTUFNpdGVNYXBQcm92aWRlcmRkAgEPZBYCAgUPZBYCAgEPEBYCHwBoZBQrAQBkAjMPZBYCA
gcPZBYCAgEPDxYCHwBoZBYCAgMPZBYCAgMPZBYCAgEPPCsACQEADxYCHg1OZXZlckV4cGFuZGVkZ
2RkAkcPZBYCAgEPZBYCAgEPPCsADQIADxYEHgtfIURhdGFCb3VuZGceC18hSXRlbUNvdW50AukHZ
AEQFgNmAgECAhYDPCsABQEAFgQeCkhlYWRlclRleHQFAklEHglEYXRhRmllbGQFAklEPCsABQEAF
gQfDgUFVGl0bGUfDwUFVGl0bGU8KwAFAQAWBB8OBQtEZXNjcmlwdGlvbh8PBQtEZXNjcmlwdGlvb
hYDZmZmFgJmD2QWNAIBD2QWBmYPDxYCHgRUZXh0BQEwZGQCAQ8PFgIfEAUNU2FtcGxlIEl0ZW0gM
GRkAgIPDxYCHxAFIVppbW1lcmdyZW4ncyBQZXJmb3JtYW5jZSBTYW1wbGUgMGRkAgIPZBYGZg8PF
gIfEAUBMWRkAgEPDxYCHxAFDVNhbXBsZSBJdGVtIDFkZAICDw8WAh8QBSFaaW1tZXJncmVuJ3MgU
GVyZm9ybWFuY2UgU2FtcGxlIDFkZAIDD2QWBmYPDxYCHxAFATJkZAIBDw8WAh8QBQ1TYW1wbGUgS
XRlbSAyZGQCAg8PFgIfEAUhWmltbWVyZ3JlbidzIFBlcmZvcm1hbmNlIFNhbXBsZSAyZGQCBA9kF
gZmDw8WAh8QBQEzZGQCAQ8PFgIfEAUNU2FtcGxlIEl0ZW0gM2RkAgIPDxYCHxAFIVppbW1lcmdyZ
W4ncyBQZXJmb3JtYW5jZSBTYW1wbGUgM2RkAgUPZBYGZg8PFgIfEAUBNGRkAgEPDxYCHxAFDVNhb
XBsZSBJdGVtIDRkZAICDw8WAh8QBSFaaW1tZXJncmVuJ3MgUGVyZm9ybWFuY2UgU2FtcGxlIDRkZ
AIGD2QWBmYPDxYCHxAFATVkZAIBDw8WAh8QBQ1TYW1wbGUgSXRlbSA1ZGQCAg8PFgIfEAUhWmltb
WVyZ3JlbidzIFBlcmZvcm1hbmNlIFNhbXBsZSA1ZGQCBw9kFgZmDw8WAh8QBQE2ZGQCAQ8PFgIfE
AUNU2FtcGxlIEl0ZW0gNmRkAgIPDxYCHxAFIVppbW1lcmdyZW4ncyBQZXJmb3JtYW5jZSBTYW1wb
GUgNmRkAggPZBYGZg8PFgIfEAUBN2RkAgEPDxYCHxAFDVNhbXBsZSBJdGVtIDdkZAICDw8WAh8QB
SFaaW1tZXJncmVuJ3MgUGVyZm9ybWFuY2UgU2FtcGxlIDdkZAIJD2QWBmYPDxYCHxAFAThkZAIBD
w8WAh8QBQ1TYW1wbGUgSXRlbSA4ZGQCAg8PFgIfEAUhWmltbWVyZ3JlbidzIFBlcmZvcm1hbmNlI
FNhbXBsZSA4ZGQCCg9kFgZmDw8WAh8QBQE5ZGQCAQ8PFgIfEAUNU2FtcGxlIEl0ZW0gOWRkAgIPD
xYCHxAFIVppbW1lcmdyZW4ncyBQZXJmb3JtYW5jZSBTYW1wbGUgOWRkAgsPZBYGZg8PFgIfEAUCM
TBkZAIBDw8WAh8QBQ5TYW1wbGUgSXRlbSAxMGRkAgIPDxYCHxAFIlppbW1lcmdyZW4ncyBQZXJmb
3JtYW5jZSBTYW1wbGUgMTBkZAIMD2QWBmYPDxYCHxAFAjExZGQCAQ8PFgIfEAUOU2FtcGxlIEl0Z
W0gMTFkZAICDw8WAh8QBSJaaW1tZXJncmVuJ3MgUGVyZm9ybWFuY2UgU2FtcGxlIDExZGQCDQ9kF
gZmDw8WAh8QBQIxMmRkAgEPDxYCHxAFDlNhbXBsZSBJdGVtIDEyZGQCAg8PFgIfEAUiWmltbWVyZ
3JlbidzIFBlcmZvcm1hbmNlIFNhbXBsZSAxMmRkAg4PZBYGZg8PFgIfEAUCMTNkZAIBDw8WAh8QB
Q5TYW1wbGUgSXRlbSAxM2RkAgIPDxYCHxAFIlppbW1lcmdyZW4ncyBQZXJmb3JtYW5jZSBTYW1wb
GUgMTNkZAIPD2QWBmYPDxYCHxAFAjE0ZGQCAQ8PFgIfEAUOU2FtcGxlIEl0ZW0gMTRkZAICDw8WA
h8QBSJaaW1tZXJncmVuJ3MgUGVyZm9ybWFuY2UgU2FtcGxlIDE0ZGQCEA9kFgZmDw8WAh8QBQIxN
WRkAgEPDxYCHxAFDlNhbXBsZSBJdGVtIDE1ZGQCAg8PFgIfEAUiWmltbWVyZ3JlbidzIFBlcmZvc
m1hbmNlIFNhbXBsZSAxNWRkAhEPZBYGZg8PFgIfEAUCMTZkZAIBDw8WAh8QBQ5TYW1wbGUgSXRlb
SAxNmRkAgIPDxYCHxAFIlppbW1lcmdyZW4ncyBQZXJmb3JtYW5jZSBTYW1wbGUgMTZkZAISD2QWB
mYPDxYCHxAFAjE3ZGQCAQ8PFgIfEAUOU2FtcGxlIEl0ZW0gMTdkZAICDw8WAh8QBSJaaW1tZXJnc
mVuJ3MgUGVyZm9ybWFuY2UgU2FtcGxlIDE3ZGQCEw9kFgZmDw8WAh8QBQIxOGRkAgEPDxYCHxAFD
lNhbXBsZSBJdGVtIDE4ZGQCAg8PFgIfEAUiWmltbWVyZ3JlbidzIFBlcmZvcm1hbmNlIFNhbXBsZ
SAxOGRkAhQPZBYGZg8PFgIfEAUCMTlkZAIBDw8WAh8QBQ5TYW1wbGUgSXRlbSAxOWRkAgIPDxYCH
xAFIlppbW1lcmdyZW4ncyBQZXJmb3JtYW5jZSBTYW1wbGUgMTlkZAIVD2QWBmYPDxYCHxAFAjIwZ
GQCAQ8PFgIfEAUOU2FtcGxlIEl0ZW0gMjBkZAICDw8WAh8QBSJaaW1tZXJncmVuJ3MgUGVyZm9yb
WFuY2UgU2FtcGxlIDIwZGQCFg9kFgZmDw8WAh8QBQIyMWRkAgEPDxYCHxAFDlNhbXBsZSBJdGVtI
DIxZGQCAg8PFgIfEAUiWmltbWVyZ3JlbidzIFBlcmZvcm1hbmNlIFNhbXBsZSAyMWRkAhcPZBYGZ
g8PFgIfEAUCMjJkZAIBDw8WAh8QBQ5TYW1wbGUgSXRlbSAyMmRkAgIPDxYCHxAFIlppbW1lcmdyZ
W4ncyBQZXJmb3JtYW5jZSBTYW1wbGUgMjJkZAIYD2QWBmYPDxYCHxAFAjIzZGQCAQ8PFgIfEAUOU
2FtcGxlIEl0ZW0gMjNkZAICDw8WAh8QBSJaaW1tZXJncmVuJ3MgUGVyZm9ybWFuY2UgU2FtcGxlI
DIzZGQCGQ9kFgZmDw8WAh8QBQIyNGRkAgEPDxYCHxAFDlNhbXBsZSBJdGVtIDI0ZGQCAg8PFgIfE
AUiWmltbWVyZ3JlbidzIFBlcmZvcm1hbmNlIFNhbXBsZSAyNGRkAhoPDxYCHwBoZGQYAgUfY3RsM
DAkUGxhY2VIb2xkZXJNYWluJEdyaWRWaWV3MQ88KwAKAQgCKWQFR2N0bDAwJFBsYWNlSG9sZGVyV
G9wTmF2QmFyJFBsYWNlSG9sZGVySG9yaXpvbnRhbE5hdiRUb3BOYXZpZ2F0aW9uTWVudVY0Dw9kB
QRIb21lZGnihW5zRhNmmnQef2E5KXJlKgIU" />
If you compare the aforementioned ViewState with the very same page but with the ViewState disabled, it would look like this:
<input type="hidden"
name="__VIEWSTATE"
id="__VIEWSTATE"
value="/wEPDwULLTE5NjIxMzI1MDJkGAIFH2N0bDAwJFBsYWNlSG9sZGVy
TWFpbiRHcmlkVmlldzEPPCsACgEIAilkBUdjdGwwMCRQbGFjZUhvbGRlclR
vcE5hdkJhciRQbGFjZUhvbGRlckhvcml6b250YWxOYXYkVG9wTmF2aWdhdG
lvbk1lbnVWNA8PZAUESG9tZWTEsK7AlAZmIZYt/bke1dmkbPKxhg=="/>
What impact can these few lines of markup have on the page rendering process anyway, you say? Well, in order to find out – let’s summon our good friend Fiddler2 and do a quick comparison.
|
ViewState Enabled |
ViewState Disabled |
|
| Body size (bytes) | 14 534 bytes | 12 883 bytes |
| Load time (seconds) | 0.3765430 seconds | 0.2031263 seconds |
A visual comparison of the same page with versus without ViewState enabled:
|
Body Size comparison (bytes) |
Load Time comparison (seconds) |
So what can I do to tune and tweak the ViewState?
There’s generally two good initial tips for tuning the ViewState.
- Disable ViewState for the entire page
- Disable ViewState for selected components
The first option is good if you don’t need to use ViewState in any of the components on your page. Then you can simply disable ViewState by setting the ViewStateEnabled property to false:
<%@ Page Language="C#"
AutoEventWireup="true"
CodeBehind="ViewStateSample.aspx.cs"
Inherits="Zimmergren.Samples.ViewState.ViewStateSample"
DynamicMasterPageFile="~masterurl/default.master"
EnableViewState="false" %>
The second option is good if you need the ViewState for certain components, but you want to disable it for others. You can disable the ViewState for specific components;
<asp:GridView ID="GridView1"
runat="server"
AutoGenerateColumns="False"
AllowSorting="true"
AllowPaging="true"
PageSize="25"
EnableViewState="false"
/>
Additional Tip: Take a look at HTTP compression
In addition to being aware of the ViewState in any asp.net project, you should take a look at HTTP Compression that you can enable in IIS.
Summary
Alright – the summer is officially over (at least of you take a look at the recent weather) and I’m back in the saddle. In this article I’ve been talking a bit about how the ViewState can impact your performance in any asp.net project (hence SharePoint project). The reason for talking about it is that I’ve seen quite the amount of projects as of late that doesn’t think about the impact a huge ViewState can have on the time it takes to download and render a page on the client.
An important consideration that I’ve learned throughout all our projects to create Internet-facing sites based on SharePoint (or plain old ASP.NET) is to measure the performance in different scenarios, including some stress testing and load tests. In most of these projects we’ve seen an increased performance if we take time to select what components or pages should disable ViewState. It might be worth considering.
Note that this is a minimal sample with minimal impact. Consider when you’ve got a huge page with 10+ Web Parts and all using the ViewState, even if they don’t really need to – can you imagine the page load times increasing? The answer is probably yes
Enjoy.
- Posted in Technical
- 8 Comments
- Tags: ASP.NET, Performance, SharePoint, SharePoint 2010
How to: Get up and running with .NET 3.5 in your SharePoint environment
September 22nd, 2008 by Tobias Zimmergren
Since I’ve been a bit on the lazy side when it comes to the blog (due to multiple reasons..), I’m thinking about writing up an article-series where I’ll talk about .NET 3.5 and what it has to offer when used in conjunction with SharePoint. Any input is welcome, of course
Introduction
In this article I will try to get you up and running with the .NET 3.5 framework in your SharePoint environment, just like I’ve previously described how you can get AJAX and Silverlight 2.0 up and running:
- MOSS 2007: Add support for AJAX in your SharePoint installation
- How to: Get up and running with the Silverlight 2.0 Blueprints for SharePoint 2007
I will now let .NET 3.5 be a part of some of my upcoming SharePoint projects, and because of that I thought it could be a good thing to blog about it if there’s anyone out there looking to do the same!
Prerequisites before we get started
In order to follow along, I assume the following few bulletpoints are in place:
- Microsoft .NET 3.5 Framework is installed on the front-end server
- You already have got a Web Application on which you want to do these changes
Add support for .NET 3.5 in SharePoint (WSS 3.0 or MOSS 2007 alike)
Here you will find a manual step by step instruction on what web.config values to set in order for .NET 3.5 to work properly with your SharePoint installation.
Note: I’ve added some linebreaks in order for the text to show up properly in my blog, you may remove them if you want your web.config to be pretty
Note2: All additions to any elements in the web.config file should be added at the bottom/end of each element unless excplicitly stated otherwise.
1) Add the following snippet inside the <configSections> element
<sectionGroup name="system.web.extensions"
type="System.Web.Configuration.SystemWebExtensionsSectionGroup,
System.Web.Extensions, Version=3.5.0.0, Culture=neutral,
PublicKeyToken=31BF3856AD364E35">
<sectionGroup name="scripting"
type="System.Web.Configuration.ScriptingSectionGroup,
System.Web.Extensions, Version=3.5.0.0, Culture=neutral,
PublicKeyToken=31BF3856AD364E35">
<section name="scriptResourceHandler"
type="System.Web.Configuration.ScriptingScriptResourceHandlerSection,
System.Web.Extensions, Version=3.5.0.0, Culture=neutral,
PublicKeyToken=31BF3856AD364E35" requirePermission="false"
allowDefinition="MachineToApplication"/>
<sectionGroup name="webServices"
type="System.Web.Configuration.ScriptingWebServicesSectionGroup,
System.Web.Extensions, Version=3.5.0.0, Culture=neutral,
PublicKeyToken=31BF3856AD364E35">
<section name="jsonSerialization"
type="System.Web.Configuration.ScriptingJsonSerializationSection,
System.Web.Extensions, Version=3.5.0.0, Culture=neutral,
PublicKeyToken=31BF3856AD364E35" requirePermission="false"
allowDefinition="Everywhere" />
<section name="profileService"
type="System.Web.Configuration.ScriptingProfileServiceSection,
System.Web.Extensions, Version=3.5.0.0, Culture=neutral,
PublicKeyToken=31BF3856AD364E35" requirePermission="false"
allowDefinition="MachineToApplication" />
<section name="authenticationService"
type="System.Web.Configuration.ScriptingAuthenticationServiceSection,
System.Web.Extensions, Version=3.5.0.0, Culture=neutral,
PublicKeyToken=31BF3856AD364E35" requirePermission="false"
allowDefinition="MachineToApplication" />
<section name="roleService"
type="System.Web.Configuration.ScriptingRoleServiceSection,
System.Web.Extensions, Version=3.5.0.0, Culture=neutral,
PublicKeyToken=31BF3856AD364E35" requirePermission="false"
allowDefinition="MachineToApplication" />
</sectionGroup>
</sectionGroup>
</sectionGroup>
2) Add the following snippet inside the <pages> element
<controls>
<add tagPrefix="asp" namespace="System.Web.UI"
assembly="System.Web.Extensions, Version=3.5.0.0, Culture=neutral,
PublicKeyToken=31BF3856AD364E35"/>
<add tagPrefix="asp" namespace="System.Web.UI.WebControls"
assembly="System.Web.Extensions, Version=3.5.0.0, Culture=neutral,
PublicKeyToken=31BF3856AD364E35"/>
</controls>
3) Add the following snippet inside the <assemblies> element
<add assembly="System.Core,
Version=3.5.0.0, Culture=neutral,
PublicKeyToken=B77A5C561934E089"/>
<add assembly="System.Web.Extensions,
Version=3.5.0.0, Culture=neutral,
PublicKeyToken=31BF3856AD364E35"/>
<add assembly="System.Data.DataSetExtensions,
Version=3.5.0.0, Culture=neutral,
PublicKeyToken=B77A5C561934E089"/>
<add assembly="System.Xml.Linq,
Version=3.5.0.0, Culture=neutral,
PublicKeyToken=B77A5C561934E089"/>
4) Add the following snippet inside the <httpHandlers> element
<add verb="*" path="*.asmx" validate="false"
type="System.Web.Script.Services.ScriptHandlerFactory,
System.Web.Extensions, Version=3.5.0.0, Culture=neutral,
PublicKeyToken=31BF3856AD364E35"/>
<add verb="*" path="*_AppService.axd" validate="false"
type="System.Web.Script.Services.ScriptHandlerFactory,
System.Web.Extensions, Version=3.5.0.0, Culture=neutral,
PublicKeyToken=31BF3856AD364E35"/>
<add verb="GET,HEAD" path="ScriptResource.axd"
type="System.Web.Handlers.ScriptResourceHandler,
System.Web.Extensions, Version=3.5.0.0, Culture=neutral,
PublicKeyToken=31BF3856AD364E35" validate="false"/>
5) Add the following snippet inside the <httpModules> element
<add name="ScriptModule"
type="System.Web.Handlers.ScriptModule,
System.Web.Extensions, Version=3.5.0.0, Culture=neutral,
PublicKeyToken=31BF3856AD364E35"/>
6) Add the following snippet inside the <SafeControls> element
<SafeControl Assembly="System.Web.Silverlight,
Version=2.0.5.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
Namespace="System.Web.UI.SilverlightControls" TypeName="*" Safe="True" />
<SafeControl Assembly="System.Web.Extensions,
Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
Namespace="System.Web.UI" TypeName="*" Safe="True" />
7) Add the following snippet inside the <configuration> element
<system.web.extensions>
<scripting>
<webServices>
</webServices>
</scripting>
</system.web.extensions>
<system.webServer>
<validation validateIntegratedModeConfiguration="false"/>
<modules>
<add name="ScriptModule" preCondition="integratedMode"
type="System.Web.Handlers.ScriptModule,
System.Web.Extensions, Version=1.0.61025.0, Culture=neutral,
PublicKeyToken=31bf3856ad364e35"/>
</modules>
<handlers>
<remove name="WebServiceHandlerFactory-Integrated" />
<add name="ScriptHandlerFactory" verb="*"
path="*.asmx" preCondition="integratedMode"
type="System.Web.Script.Services.ScriptHandlerFactory,
System.Web.Extensions, Version=1.0.61025.0, Culture=neutral,
PublicKeyToken=31bf3856ad364e35"/>
<add name="ScriptHandlerFactoryAppServices" verb="*"
path="*_AppService.axd" preCondition="integratedMode"
type="System.Web.Script.Services.ScriptHandlerFactory,
System.Web.Extensions, Version=1.0.61025.0, Culture=neutral,
PublicKeyToken=31bf3856ad364e35"/>
<add name="ScriptResource" preCondition="integratedMode"
verb="GET,HEAD" path="ScriptResource.axd"
type="System.Web.Handlers.ScriptResourceHandler,
System.Web.Extensions, Version=1.0.61025.0, Culture=neutral,
PublicKeyToken=31bf3856ad364e35" />
</handlers>
</system.webServer>
<system.webServer>
<validation validateIntegratedModeConfiguration="false"/>
<modules>
<remove name="ScriptModule" />
<add name="ScriptModule" preCondition="managedHandler"
type="System.Web.Handlers.ScriptModule,
System.Web.Extensions, Version=3.5.0.0, Culture=neutral,
PublicKeyToken=31BF3856AD364E35"/>
</modules>
<handlers>
<remove name="WebServiceHandlerFactory-Integrated"/>
<remove name="ScriptHandlerFactory" />
<remove name="ScriptHandlerFactoryAppServices" />
<remove name="ScriptResource" />
<add name="ScriptHandlerFactory" verb="*" path="*.asmx"
preCondition="integratedMode"
type="System.Web.Script.Services.ScriptHandlerFactory,
System.Web.Extensions, Version=3.5.0.0, Culture=neutral,
PublicKeyToken=31BF3856AD364E35"/>
<add name="ScriptHandlerFactoryAppServices" verb="*"
path="*_AppService.axd"
preCondition="integratedMode"
type="System.Web.Script.Services.ScriptHandlerFactory,
System.Web.Extensions, Version=3.5.0.0, Culture=neutral,
PublicKeyToken=31BF3856AD364E35"/>
<add name="ScriptResource" preCondition="integratedMode"
verb="GET,HEAD" path="ScriptResource.axd"
type="System.Web.Handlers.ScriptResourceHandler,
System.Web.Extensions, Version=3.5.0.0, Culture=neutral,
PublicKeyToken=31BF3856AD364E35" />
</handlers>
</system.webServer>
8) You’re done
When you’ve added the needed tags, you’re all set – you can now run your .NET 3.5 applications inside SharePoint (of course, this applies to the web application where you just added these settings.
To see that your site still works, do the following:
- IISRESET
- Launch your site where you’ve made the changes!
- Cross your fingers
Cool, what’s next?
Well, if you’ve managed to get your site up and running – you can now create webparts, features, controls or whatever you’d like to create and have them published to your site.
This article describes how you do these things manually, but what if you want to do these things automatically somehow? Is that possible?
- Yes, but that’s going to be covered in an upcoming blogpost
Please leave some comments
As you might know, I like to get feedback and usually answers all mails/comments when I’ve got the time. Please leave any feedback, suggestions or opinions in the comments below or mail me/use the MSN gadget.
Thanks for tuning in, now I’m feeling the blog-flow again – cheers
- Posted in Technical
- 5 Comments
- Tags: .NET 3.5, ASP.NET, How-To, MOSS, SharePoint, WSS
WSS v3.0: Import an ASP.NET Web Part to your Windows SharePoint Services Site
December 13th, 2006 by Tobias Zimmergren
It is possible to use your ASP.NET web parts in your Windows SharePoint Services (WSS) application simply by exporting them to create .webpart files.
.Webpart files are simply XML files that contains property values, state data, assembly or source file details about your Web Part (WP).
In order to be able to export your WP, you need to make some changes to your WP code and the configurationsettings.
Step by Step:
1) In your WP code, set the ExportMode property to allow properties to be exported, like this:
this.ExportMode = WebPartExportMode.All;
2) Locate and modify your system.web section in your web.config configuration file, like this:
<system.web>
<webparts enableExport="true" />
<sytem.web>
3) Choose export from the Web Part menu to create a .webpart file which you now can import into your WSS WP Page
- Posted in Technical
- No Comments
- Tags: ASP.NET, MOSS, SharePoint, WSS

