SharePoint

When you want to implement a custom stsadm for SharePoint, all you realy have to do is implement the Microsoft.SharePoint.StsAdmin.ISPStsadmCommand interface. Because I develop on a machine with no SharePoint installed, I (only) copy the assemblies I need to develop locally. For the stsadm command I was working on recently (more on this in a future post) I only needed the Microsoft.SharePoint and Microsoft.Office.Server assemblies. Or at least I thought so…

While writing a custom stsadm command for SharePoint (more on that in a future post) and having to do something based on the command the user typed in, I used ToLower(CultureInfo.InvariantCulture) on the command string to be able to check without the hassle of differences in casing. When I ran code analysis on my project, I got this somewhat cryptic message: CA1308 : Microsoft.Globalization : In method ‘CommandParser.Run(string, StringDictionary, out string)’, replace the call to ‘string.

After developing a custom Web Service to be hosted in SharePoint (based on this HowTo article on MSDN) and deploying it on a testing environment, I got some entries in the EventLog over there, stating: “Unable to connect publishing custom string handler for output caching. IIS Instance Id is ‘xxxxxxxxx’, url is ‘https://internalsharepointserver/somesubfolder/services.asmx“ The PublishingHttpModule trying to cache an unmanaged path seems to be the problem here. When enabled for a custom web application (such as my web service), it causes the eventlog entry each time certain requests like web service calls or static CSS files are made.

It’s here: the Microsoft SharePoint Administration Toolkit. This first release contains two tools, both supported on WSS 3.0 and SharePoint Server 2007. Batch Site Manager From the “Move, Lock, and Delete Site Collections” page on Applications Management you can schedule bulk operations against site collections in the farm—including moving site collections between content databases (!!). stsadm extension: UpdateAlert This command will refresh all alert URLs in a specific site collection, which is extremely important should you change the URL of a web application or after an upgrade.

A week ago I had a nice page that was hosted in SharePoint and, among others, contained an updatepanel with a dropdownlist in it. Everything worked, and all was well. Because our testers had found some issues we had delivered two newer versions to our development environment. In the last version they found an issue that wasn’t there before: selecting a different value in the dropdown did not only update the updatepanel, but resulted in a complete postback.

As I said earlier, we didn’t test our solution to using the ModalPopupExtender in SharePoint in all situations. Today we made a start to do so. To indicate our successrate: we now use window.showModalDialogwith some extra pages… Lets go through some of the problems we encountered. Placing an UpdatePanel around the entire UserControl (with default settings) makes that the entire UserControl is posted back, even when it is a control inside a nested UpdatePanel that posts back.

Getting the ModalPopupExtender from the Ajax Control Toolkit to work (decently) in SharePoint was not exactly a walk in the park. With a default SharePoint installation, the modal popup is partly positioned ‘outside’ of the page (you only see the bottom right part of the popup in the top left corner of the browser). Postbacks are not executed or executed poorly and the page gets garbled up. A possible solution for the positioning of the popup is to set the X and Y property of the ModalPopupExtender.