Condividi tramite

Using Reflector to See SharePoint's "Source" Code

  • Articolo

Important Note: Customers are advised to review the end user license agreement (EULA) for the relevant Microsoft products before using this tool. This blog entry does not authorize or endorse any use of Microsoft products that is not addressed specifically by the product's EULA.

Do you sometimes use a "reflector" program to examine SharePoint source code? This can be necessary to:

  • Understand out how SharePoint is doing something, to find what elements can be customized.
  • Understand what members to override in classes you create that inherit from SharePoint classes.

The de facto standard program for doing this is Lutz Roeder's Reflector. The MSDN article on ten must-have tools has a great description of how helpful it can be and how to use it.

One thing the article doesn't tell you is where to find SharePoint's assemblies; fortunately it's not that hard. Click "Open" in Reflector, then with a little bit of browsing, most people easily find the dlls in the ISAPI directory of the "12-hive" (C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\ISAPI).

Open one or more of these dlls, then browse the classes to see how SharePoint's put together… the Disassemble tool is exceedingly useful! Note: the code you see is reconstructed from MSIL, into the language of your choice (C#, VB, Delphi, C++ or Chrome)… the product teams didn't really use all those goto's!

However, some SharePoint namespaces seem to be missing or incomplete when viewed in Reflector. This had me baffled for quite some time, until I found the following.

Some SharePoint assemblies are stored in the _app_bin directory of the web application instead of the ISAPI directory in the 12-hive. Presumably, the reason for distributing certain code into the web application's root is related to something like stability, security or scalability. But the important point is if you're using Reflector to look at SharePoint code, you may need to look here as well.

This is especially true for a namespace like Microsoft.SharePoint.ApplicationPages. Two assemblies contribute members to this namespace: 12\ISAPI\Microsoft.SharePoint.dll and Inetpub\...\_app_bin\Microsoft.SharePoint.ApplicationPages.dll. If you just reflect the one in ISAPI, you'll see very few members; the ones you typically want to look at are in _app_bin!

SharePoint DLL locations

Here's a list of all the SharePoint assemblies and where they appear.

12\ISAPI

Microsoft.Office.Excel.Server.Udf.dll
Microsoft.Office.Excel.Server.WebServices.dll
Microsoft.Office.Policy.dll
Microsoft.Office.Server.dll
Microsoft.Office.Server.Search.dll
microsoft.office.workflow.tasks.dll

Microsoft.SharePoint.dll
microsoft.sharepoint.portal.dll
Microsoft.SharePoint.Portal.SingleSignon.dll
Microsoft.SharePoint.Portal.SingleSignon.Security.dll
Microsoft.SharePoint.Publishing.dll
Microsoft.SharePoint.Search.dll
Microsoft.SharePoint.Security.dll
microsoft.sharepoint.WorkflowActions.dll

Not .NET assemblies (can't reflect):
OWSSVR.DLL
SHTML.DLL
SSOCLI.DLL

Inetpub\wwwroot\wss\VirtualDirectories\<web app>\_app_bin

Microsoft.Office.DocumentManagement.Pages.dll
Microsoft.Office.officialfileSoap.dll
Microsoft.Office.Policy.Pages.dll
Microsoft.Office.SlideLibrarySoap.dll
Microsoft.Office.Workflow.Pages.dll
Microsoft.Office.WorkflowSoap.dll

Microsoft.SharePoint.ApplicationPages.dll

stssoap.dll

Obfuscation tips

Sometimes, not too often, when Reflector is disassembling source code for you, it will show "This item is obfuscated and can not be translated" instead of code. I think the product team did this for some of the more "sensitive" areas of the code (such as LogInAsAnotherUser) and also on a bit of a random basis, perhaps to prevent fully reverse engineering the product. In any case, by changing the translation language to IL in Reflector, you might get enough information from the MSIL code to answer the question that drove you there in the first place. For example, sometimes I just need to know what modules are being called, or what strings are being used to find other resources in the 12-hive; these are still visible in MSIL.

Important Note: Customers are advised to review the end user license agreement (EULA) for the relevant Microsoft products before using this tool.

Technorati Tags: SharePoint,MOSS+2007,Development

Comments