SharePointの分解 - [extern "関数実装の検索

Question

Microsoft.SharePoint.dllのいくつかの方法を分解して、必要なものについてもこれらのクラスのいくつかを使用できるかどうか、またはホイールを再発明する必要があるのかどうかを確認します。

とにかく、SPRequestラッパーによって呼び出された非管理コードに到着し始めるポイントまで、関数呼び出しをトレースできます。SPRequestクラスのSPRequestInternalClassクラスコール関数の多くの関数は、COMオブジェクトを介してどこかで実装されています。

今、私はこれらのメソッドを直接呼び出しようとしていませんが、そのように愚かなものは何でもありませんが、私はそれらがどのように実装されているかを見る必要があります。

私の質問は、SPコードの管理されていない、COM部分がどこにあるのか？

Answer 1

I figured it out. I found this blog post by Hristo Pavlov: Understanding SharePoint: SPRequest

In the article he explains:

The internal SPRequest class has an unmanaged reference to a COM object called SP.SPRequest and having a ClassID of BDEADEE2-C265-11D0-BCED-00A0C90AB50F which is implemented in and exposed by the OWSSVR.DLL class library.

The SP.SPRequest COM object exposes almost 400 basic operations and almost everything you do with the Microsoft.NET managed SharePoint object model that reads from or writes to the ContentDatabase (including data, fields, content types, list schemas, etc) will actually go via this unmanaged COM object. Even more the OWSSVR.DLL is actually an ISAPI extension registered in IIS and its methods can be called directly via an HTTP request to /_vti_bin/owssvr.dll. Many of the Office applications (Word, Excel, InfoPath, SharePoint Designer etc) are using HTTP calls to OWSSRV directly in order to integrate with a remote SharePoint server. It won’t be too much of an exaggeration to say that OWSSRV.DLL is the soul and body of WSS 3.0. It comes historically from SharePoint ver 1.0 from the days before Microsoft.NET when web applications were developed using technologies like ISAPI and DCOM.

Edit:

Another note about this is that this DLL is not in the GAC.

You can find this assembly in the ISAPI directory of the hive. In SP 2013, the path is:

C:\Program Files\Common Files\microsoft shared\Web Server Extensions\15\ISAPI\OWSSVR.DLL

Or the equivalent on your system.

Edit 2:

Good luck doing anything with this DLL. You can't just decompile this like you can with the .NET assemblies, so knowing where the DLL is doesn't actually help you peer into internal, undocumented implementations.