1
2
3
4
5

SPSecurity.RunWithElevatedPrivileges( () => {
    using( var newSite = new SPSite( site.Url ) ) {
        // your stuff
    }
});

Is equivalent to :

1
2
3

using( var newSite = new SPSite( site.Url, site.SystemAccount.Token ) ) {
    // your stuff
}

So if this is just to open an elevated privilege SPSite, it will be equivalent. But if you do some more complex things, as soon as you load a new SPSite it will open it with the original UserToken. And you lose…

• The method used to launch the thread must have the “[STAThread]” attribute, it avoids some huge memory leaks.
• If you need to use an SPSite from the calling site, you should copy its URL and UserToken to build a new SPSite in the new thread. If you’re not using that “design pattern”, things will get really wrong.
• And of course you should dispose any sharepoint SPSite (SPWebs come from SPSite) allocated within the thread.

The truth is, .Net never leaks but you can sometimes make stupid conception mistakes, like forgetting to remove references of some objects (that may contains heavy references themselves).

The tool allows you to take snapshots of your running application and compare different snapshots. You can see the difference of memory consumption by some objets or the difference of class instance count.

I’ve used it at work to solve a Sharepoint memory leak. And I finally discovered that the memory leak is really coming from the .Net Sharepoint object model. I’ll talk about this later. Sharepoint is amazing both ways.

In the event logs, I had this error :

1

ISAPI Filter 'C:\Windows\Microsoft.NET\Framework\v4.0.21006\aspnet_filter.dll' could not be loaded due to a configuration problem. The current configuration only supports loading images built for a AMD64 processor architecture. The data field contains the error number. To learn more about this issue, including how to troubleshooting this kind of processor architecture mismatch error, see http://go.microsoft.com/fwlink/?LinkId=29349.

And then :

1

Could not load all ISAPI filters for site 'SHAREPOINT - 80'.  Therefore site startup aborted.

And the same of the “Central Administration” :

1

Could not load all ISAPI filters for site 'SHAREPOINT CENTRAL ADMINISTRATION V4'.  Therefore site startup aborted.

It seems to work fine, I’ll get back on it later. What I could see so far is that it’s more pretty, easier to use but it doesn’t seem more efficient or lighter than Sharepoint 2007, you can see the RAM consumption grow high speed with the page loading.

Totally unrelated note : I discovered I was one of the two guys to use the SVN version of WordPress and display it.

Using SPSite(s) and SPWeb(s)
If you do some timing on the SPWeb creation call (SPSite.OpenWeb), you will find out that it’s freaking fast (less then 1 ms on my server). The reason is that the most heavy object, the SPRequest class, is shared among SPWebs of a SPSite. The Dispose call only “Invalidate” the SPWeb, and if this SPWeb is the owner of the SPRequest (which is SPContext.Current.Web object in most of the cases), it releases it.

Personnaly, I like to have something like that when I use a particular SPWeb along my code in a WebPart :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

private SPWeb _rootWeb;
public SPWeb RootWeb {
    get {
        if ( _rootWeb == null ) {
            _rootWeb = SPContext.Current.Site.RootWeb;
            if ( _rootWeb != SPContext.Current.Web )
                _toDispose.Add( _rootWeb );  
        }
        return _rootWeb;
    }
}
 
private List<IDisposable> _toDispose = new List<IDisposable>();
protected override void OnUnLoad() {
    foreach( var disp in _toDispose )
        disp.Dispose();
}

But the code above won’t make you gain a 1 ms compared to this code (which is shorter and potentially safer, you don’t need to dispose everything) :

1
2
3
4
5
6
7
8

var rootWeb = SPContext.Current.Site;
try {
    // Your code
}
finally {
     if ( rootWeb != SPContext.Current.Web )
         rootWeb.Dispose();
}

If you had to access some more indirect objects, you certainly should keep the code showed earlier. For instance to use a SuperToken Web :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

private SPSite _stSite;
SPSite STSite {
    get {
        if ( _stSite == null ) {
            _stSite = new SPSite( SPContext.Current.Site.Url, SPContext.Current.Site.SystemAccount.UserToken );
            if ( _stSite != SPContext.Current.Site )
                _toDispose.Add( _stSite );
        }
        return _stSite;
    }
}
 
private SPWeb _stWeb;
SPWeb STWeb {
    get {
        if ( _stWeb == null ) {
            _stWeb = STSite.OpenWeb( SPContext.Current.Web.Url );
            if ( _stWeb != SPContext.Current.Web )
                _toDispose.Add( _stWeb );
        }
        return _stWeb;
    }
}
 
private List<IDisposable> _toDispose = new List<IDisposable>();
protected override void OnUnLoad() {
    foreach( var disp in _toDispose )
        disp.Dispose();
}

Here, opening these new SPSite and SPWeb takes 200 ms on my server. Making sure this only happen once per webpart (or better, per page) can really boost your performances.

The SPRequest object
Well… I was very disapointed, the SPRequest object references an SPRequestInternalClass from the Microsoft.Sharepoint.Library assembly which only uses interrop COM+ methods. So, it’s basically wrapping COM+ methods. The SPRequest does a lot of exception handling and it keeps track of where (with the stacktrace) it has been created and the size of the “unmanaged stack”.

Optimization
I like how they did their code. It’s pretty optimized (they even use a bunch of gotos). But sometimes there is some weird things and I don’t know if it’s the compiler’s or the developer’s fault. If you look at the code, they have an SPRequestManager.SPRequestsPerThreadWarning property, which gets (in the Registry, at “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\HeapSettings\LocalSPRequestWarnCount”) the max number of opened SPRequest objects opened before logging it (or 8 if this entry doesn’t exist), that takes twice the amount of code it would normaly require.

The limit of disassembling
The most frustrating part is there are tons of really important methods that are obfuscated (and that .Net reflector doesn’t disassemble, it could at least give the IL code in comments). I just have :

1
2
3

private static void xxx() {
    // This item is obfuscated and can not be translated.
}

For instance, I really would have liked to see how works the SPList.Update() method, but it’s also obfuscated.

You should explore it too
In the Microsoft.Office.Server.Search assembly, you will also find some pretty interesting things. If you look how works the standard search webparts, well you will be pretty disapointed. The advanced search uses an internal (in the C# meaning) shared object.

Before doing your own webpart, you should take a look at the overriden methods of some sharepoint webparts. It can show you, for instance, how to create your own toolparts. In my last project, I used a stupid text property instead of using a DropDownList in a ToolPart, I was very disappointed with myself when I discovered this.

In other word : In any SPList, you have some SPField fields and each of these SPField has the super power to create a BaseFieldControl. Each BaseFieldControl is a CompositeControl containing ASP.Net controls.

For a single line field, you will just have a wrapped TextBox. But for some more advanced fields like a multi-select lookup field (SPFieldLookup) or rich text field, it can generate some “complex” controls and their related javascript code.

The BaseFieldControl can be directly connected to your Sharepoint’s SPListItem and the BaseFieldControl.Value will match the format required to fill the SPListItem.

You can create your own BaseFieldControl controls, and you can directly mess up the BaseFieldControl.Controls property if you like to (that can be useful). I personally had to create a variation of the MultipleLookupField (that’s the BaseFieldControl used for a SPLookupField with the AllowMultipleValues property enabled) to create a CheckBoxList of selected items (that what the client wanted).

How to use them to display data ?
You can get it by accessing the SPField.FieldRenderingControl property. It gives you everything you need. Each BaseFieldControl has a ControlMode property (SPControlMode enum) which can be set to New, Edit, Display or Invalid (I don’t know why this third one exists).

Here is a stripped down version of the necessary code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

protected override CreateChildControls() {
 
     // The web used
     var web = SPContext.Current.Web;
 
     // This is the code you could have easily guessed :
     var list = web.Lists["MyList"];
     var item = list.GetItemById( 1 );
     var field = item["DateOfEvent"];
     var bfc = field.FieldRenderingControl;
 
     // This is when it becomes tricky :
     var renderContext = SPContext.GetContext( this.Context, 0, list.ID, web );
 
     bfc.ListId = list.ID;
     bfc.FieldName = field.InternalName;
     bfc.ID = field.InternalName;
     bfc.ControlMode = SPControlMode.Edit;
     bfc.RenderContext = renderContext;
     bfc.ItemContext = renderContext;
     bfc.EnableViewState = true;
     bfc.Visible = true;
 
     Controls.Add( bfc );
}

And if you want to use it as an input form, you have to get a non existing SPListItem :

1
2

var item = list.GetItemById( 1 );
var field = item["DateOfEvent"];

By this :

1
2

var item = list.Items.Add();
var field = list.Fields["DateOfEvent"];

And then later add this reflection code to force the render context to take into account the temporary created item :

1
2

var fiContextItem = ( typeof( SPContext ) ).GetField( "m_item", BindingFlags.Instance | BindingFlags.NonPublic );
fiContextItem.SetValue( renderContext, item );

If you use multiple SPWeb…
In your Sharepoint code, you might need to use more than one SPWeb. In that case, you must absolutely take care of creating the right SPContext (using the SPWeb of the SPList of the source SPField) for each BaseFieldControl used.

And if the SPWeb used doesn’t have the same language as your current site, you can change it easily by doing something like that :

1

web.Locale = SPContext.Current.Web.Locale;

If you create your own BaseFieldControl…
If you create your own BaseFieldControl, you should really take a look on the disassembled code of the default BaseFieldControls. It could make you save a lot of time and efforts. And please note that the LookupField (which directly inherits BaseFieldControl) isn’t sealed. Inheriting from it might be a good way to do your own custom lookup BaseFieldControl.

If you enable the ControlMode = SPControlMode.Display
If you want to use your BFC with the Display ControlMode and want to set a value, you must take care of setting the Value BEFORE setting the ControlMode. If you don’t do that it will work on the first render but fail on the first PostBack : Your value will not be used (and displayed) by the BFC.

If you check the value of the BFC
If you check the value of the BFC, you have to remember that each BFC create its value for the SPField from which it has been created. For instance, empty values can be returned as String.Empty, null or even the 0 integer.

1. Attaching to the process
It only applies to a debugging environnement.

This is the one that everybody knows (or should at least). You deploy your DLL in the GAC, restart your application pool, access your sharepoint web application in order to load the application pool and the DLL and then attach to the right w3wp.exe process (or every w3wp.exe process if you don’t really know which one to choose).

2. Displaying where the exception happens
It should be used everywhere.

Just after deploying your DLL into the GAC, you should deploy the PDB file with it. In your exception management code, you have the exact line where the exception was thrown. Wether your users report it (with the exact line number), you see it in the logs or you have an automatic reporting system, the point is : You will know exactly where it fails.

If you have a WSP deployment method, you will have :

1
2

rem This WSP File contains the MyCorp.MyApp.MyLib library with the 0x123456789 public key token
stsadm -o addsolution -filename %WSPFILE%

If you have a DLL deployment method, you will have :

1

gacutil /if GAC\MyCorp.MyApp.MyLib.dll

Either way, you need to add the PDB with this command :

1
2

subst X: c:\windows\assembly\gac_msil
copy GAC\MyCorp.MyApp.MyLib.pdb X:\MyCorp.MyApp.MyLib\1.0.0.0_123456789\

If you’re not willing to give away your PDB file (it contains you complete code source and consumes space), you can find out where you app exactly failed just from the offset of the stacktrace reported by Sharepoint (with the CustomError=”Off” and StackTrace=”true” in the web.config). Some people explain how to do it here. Answer “3″ allows you to get the IL offset like ASP.Net does in its (non customized) error page.

3. Launching the debugger from the code
This is very useful for features deactivation/uninstallation/installation/activation code.

You just have to add this line when you want to ask the debugger to attach to the assembly.

1

Debugger.Launch();

4. Other options
This article focuses on hardcore problems : Problems that occur inside sharepoint or weird problem that only appear on your production servers.

The WinDBG method seems a little bit overkill to me. Mostly because you still can’t analyze the state of the local variables with our current tools (but I hope it will be made available in a short future).

One good example is MOSS Faceted search 2.5 (I haven’t tested the 3.0). It takes at least 40 minutes to uninstall this crap. Why isn’t it just ONE WSP or at least one BAT file launching the WSP installation and the other steps ? Is there any real reason for that ?

The SPWebConfigModification solves this web.config modification problem. It’s a pretty interesting feature of Sharepoint. You can edit the web.config file without any complex XML parsing. It doesn’t even matter that you add XML or not. The SPWebConfigModification class manages your add/mod/del operations easily. The only restriction is that you have to add your first configuration elements using the SPWebConfigModification. You cannot modify existing elements this way.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45

// Source : http://sharethelearning.blogspot.com/2008/01/adding-bindingredirect-to-webconfig.html
public static void AddBindingRedirect( SPWebApplication webApp, string libraryName, string libraryPublicToken, string oldVersion, string newVersion ) {
	var ownerName = String.Format( "BindingRedirect.{0}", libraryName );
 
	{ // We delete last bindingRedirect
 
		var list = new List<SPWebConfigModification>();
		foreach ( SPWebConfigModification mod in webApp.WebConfigModifications ) {
			list.Add( mod );
		}
 
		foreach ( var mod in list ) {
			if ( mod.Owner == ownerName ) {
				LoggerCommon.LogVerbose( String.Format( "Deleting: \"{0}\"", mod.Value ) );
				webApp.WebConfigModifications.Remove( mod );
			}
		}
	}
 
	{ // We add our redirection
		String path = "configuration/runtime/*[namespace-uri()='urn:schemas-microsoft-com:asm.v1' and local-name()='assemblyBinding']";
		String name = String.Format( "*[namespace-uri()='urn:schemas-microsoft-com:asm.v1' and local-name()='dependentAssembly']/*[namespace-uri()='urn:schemas-microsoft-com:asm.v1' and local-name()='assemblyIdentity'][@name='{0}']/parent::*", libraryName );
		String webConfigValue = String.Format( @"
	<dependentAssembly>
		<!-- Added automatically at {4} -->
		<assemblyIdentity name='{0}' publicKeyToken='{1}' culture='neutral' />
		<bindingRedirect oldVersion='{2}' newVersion='{3}' />
	</dependentAssembly>
", libraryName, libraryPublicToken, oldVersion, newVersion, DateTime.Now );
 
		SPWebConfigModification mod = new SPWebConfigModification( name, path );
		mod.Value = webConfigValue;
		mod.Owner = ownerName;
		mod.Sequence = 0;
		mod.Type = SPWebConfigModification.SPWebConfigModificationType.EnsureChildNode;
 
		webApp.WebConfigModifications.Add( mod );
 
	}
 
	{ // We save our changes
		webApp.Update();
		SPFarm.Local.Services.GetValue<SPWebService>().ApplyWebConfigModifications();
	}
}

If you do a binding redirect from 1.0.0.0 to 1.0.1.0 and your .webpart file references the 1.0.0.0 version, sharepoint will store your webpart as referencing the 1.0.1.0 assembly (and not 1.0.0.0 as you told him). So if you then chose to change the binding redirect from 1.0.0.0 to 1.0.2.0, without redirecting 1.0.1.0 to 1.0.2.0, your webpart will still be the 1.0.1.0 version.

I haven’t tested this for event receivers, but the way they are registered (Sharepoint doesn’t check the assembly you add to the event receivers of a list), I would guess Sharepoint doesn’t change the assembly version.

To solve this webpart updating problem, you can use ranged binding redirect (.Net rules) :

1
2

var site = new SPSite("http://localhost");
AddBindingRedirect( site.WebApplication, "MyCorp.MyApp.MyLib", "0x123456789", "1.0.0.0-1.0.3.5", "1.0.3.5" );

That means that any webpart using a previous version of the “MyCorp.MyApp.MyLib” assembly between 1.0.0.0 and 1.0.3.5 will be redirected to the 1.0.3.5 version.

If your assembly contains page code-behind classes, you should take care of updating the aspx files as well.

Reference :

• The original code

Wow, they really seem to have understood all of the sharepoint developers problems. Look at the full developer video. Everything is incredible : Sharepoint Extensions seem complete and cutomizable, there is the new developper dashboard which displays for instance the number of opened SPRequest the time spent on each loading stage of the page, the Business Data Catalog model allows to use any data inside sharepoint within “external lists”, the official LinQ for Sharepoint, the new WSP package which allow to specify which deployment actions to use. This runs on top of Windows Server 2008 and Visual Studio 2010.

The bad news is : CAML hasn’t be thrown away, non-generic types like ListItemCollection are still used. But I guess, they can’t change everything instantly.

• Create a binding redirect within the web.config file.
• Update each and every webpart instance of the collection site (or just the site).

The first one is really the best solution : It’s simple and very fast. But, it applies to the whole Web Application. Sometimes, the client might want to only update the site collection or even the website. In this case, we need to apply the second solution : update each webpart.

Updating each webpart requires you to create a solution that will go through all the pages of your website and replace each instance of a webpart by an other instance.

I can’t give the complete code (as it’s still not mine), but only some little hints that can help you solve this problem.

You have to analyse each an every file of your websites :

1
2
3
4
5
6
7
8
9

		private static void AnalyseFolder( List<SPFile> list, SPFolder folder ) {
			foreach ( SPFile file in folder.Files ) {
				var fileName = file.Name.ToLower();
				if ( fileName.EndsWith( ".aspx" ) || fileName.EndsWith( ".master" ) )
					list.Add( file );
			}
			foreach ( SPFolder subFolder in folder.SubFolders )
				AnalyseFolder( list, subFolder );
		}

You could restrict youself to the “pages” folder, but you would miss some pages like the layouts.

Then for each file of the class :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87

		private void TreatPage( SPWeb web, SPFile file ) {
			try {
				if ( file.Name.EndsWith( ".master" ) ) {
					Logger.LogVerbose( "\"{0}\" is a masterpage...", file.Url );
					return;
				}
				SPWeb managerWeb = null;
				try {
					if ( file.Item == null ) {
						Logger.LogNotice( "\"{0}\" isn't part of a document library...", file.Url );
						return;
					}
 
					// Sometimes the code above works but this will still throw an exception
					file.Item.ToString();
				} catch ( SPException ex ) {
					Logger.LogNotice( "\"{0}\" isn't part of a document library...", file.Url );
					return;
				}
				try {
					using ( var manager = file.GetLimitedWebPartManager( PersonalizationScope.Shared ) ) {
 
						managerWeb = manager.Web;
 
						// we reload the same file but in the SPLimitedWebpartManager's web context
						file = managerWeb.GetFile( file.Item.UniqueId );
 
						var collection = manager.WebParts;
 
						var toDelete = new List<WebPart>();
 
						var previousWebparts = new List<WebPart>();
						foreach ( WebPart wp in collection )
							previousWebparts.Add( wp );
 
						Boolean madeChanges = false;
 
						var toDispose = new List<WebPart>();
 
						foreach ( WebPart wp in previousWebparts ) {
							Boolean deleteWebPart;
 
							var newWebPart = GetNewWebPart( wp, out deleteWebPart );
							if ( newWebPart != null || deleteWebPart ) {
 
								if ( !madeChanges ) {
									CheckOutPage( file );
									madeChanges = true;
								}
 
								Logger.LogVerbose( "Replacing webpart \"{0}\" by \"{1}\"...", wp.GetType().FullName, newWebPart != null ? newWebPart.GetType().FullName : "- none -" );
								if ( newWebPart != null )
									manager.AddWebPart( newWebPart, wp.Zone != null ? wp.Zone.ID : "0", wp.ZoneIndex );
 
								// it's either replaced or deleted : it will need to be removed from the page
								toDelete.Add( wp );
 
								if ( newWebPart != null )
									toDispose.Add( newWebPart );
							}
						}
 
						// If we made some changes to the file, we have to save it
						if ( madeChanges ) {
							foreach ( var wp in toDelete )
								manager.DeleteWebPart( wp );
 
							file.Update();
 
							CheckInPage( file, "Webpart update" );
						}
 
 
						// All the webparts found will need to be disposed
						toDispose.AddRange( previousWebparts );
 
						// We dispose everyone
						foreach ( var wp in toDispose )
							wp.Dispose();
					}
				} finally {
					if ( managerWeb != null && managerWeb != web )
						MemoryManagement.MightDispose( web );
				}
			} catch ( Exception ex ) {
				Logger.LogException( ex, "UpdateWebpartsInPage.TreatPage( SPFile.Url=\"{0}\" )", file.Url );
			}