I recently took the time to take a look inside the Microsoft.Sharepoint.dll using reflector. I’m not sure I have the right to do that. And I’m pretty sure I don’t have the right to publish any code extracted from it, so I won’t show any. 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).
What for ? Sharepoint’s API provides some standard form controls to render each column. This is the controls used to render the standard add and edit forms. And they all inherit the BaseFieldControl class. 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.
Sharepoint debugging isn’t fully automated. So you should really know how to debug and diagnose your assemblies in any given situation. 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.
I’ve seen lots of Sharepoint software having an installation manual of at least 20 pages (sometimes 60). Most of the operations they describe could be fully automated. And these software were made by freaking big companies. They should be ashamed of themselves. Maybe they just forgot that computer science is all about saving some time (and not only making money). One good example is MOSS Faceted search 2.5 (I haven’t tested the 3.
I recently bought a new laptop. I choose a P8600 processor to make sure to have virtualization support and a little TDP (Thermal Dissipation Power) because I don’t really like the fan noise. And it has 4GB or RAM for these little virtual hosts. So today, I decided to have a little Sharepoint 2007 of my own. I installed Windows Server 2008 on a VMWare host, activated Remote Desktop, added Sharepoint 2007 and then MOSS 2007.
I wanted to use a little SPGridView in a software and had a little problem. First of all, in order to use filtering on a SPGridView, you have to give an ObjectDataSource by it’s control’s ID. For anything else, you can use the DataSource property directly. The best sample code I could fin on the net was this one : Creating the SPGridView with sorting and adding filtering. This example is great because it only shows the basic requirements to setup a SPGridView and it gives you a clean way to build the ObjectDataSource and it explains step by step why you have to do things this way (in Sharepoint, it’s very important).
In Microsoft Office Sharepoint Server, you have a powerful search service. It can’t say I like everything in sharepoint but the MOSS Search Engine is really amazing. It enables to search fulltext on everything and also to filter precisely your results by searching on columns at the same time. But the MOSS search engine isn’t as easy as searching directly in CAML. You have to prepare managed properties (from your lists columns) to be able to search on them.
If you’re faced with that error, you should know that it doesn’t mean anything except you have a problem. Lots of people have written posts about it, but most of their explanations are wrong. It just means that sharepoint didn’t like what you did somewhere in your masterpage, your page, your webpart, your user control or anything else. For me, it was because I used the SPWeb.GetListFromUrl method to test if the user actually had access to a list.