Adventures in MS land

I’ve spent the last couple of days fiddling around with Windows Server 2003, Active Directory and SharePoint Portal Server.

Observation #1: It helps to have multiple computers, or alternatively a powerful machine with a virtualization environment like vmware or VirtualPC.

Observation #2: Installing/uninstalling Active Directory (“dcpromo”) changes the security settings on your files, which breaks ASP.NET due to access violations in C:WINDOWSMicrosoft.NETFrameworkv1.1.4322Temporary ASP.NET Files. You can fix this by uninstalling and re-installing ASP.NET in Start -> Control Panel -> Add/Remove Programs -> Add/Remove Windows Components.

Observation #3: There is a shiny new version of SharePoint Portal Server here: This version is “Beta 2 Technical Refresh”, which is newer than the “Beta 2” version on our MSDN dvds.

Upgrading ASP.NET breaks our ReturnUrls

From the newgroups: “The other problem I found was the returnurl from ASP.Net was incorrect as ASP.Net gives you the underlying template file as the return url; if used the author will get an error when they log back in. What I wanted was the CMS returnUrl.”

What he’s saying is that web.config-based authorization and Context.RewritePath() don’t play well together. Looks like we got bitten by that, too. Ouch.

Sharepoint URLs

We’re starting to look at Microsoft’s SharePoint technologies. As with other well funded technology efforts, there is a sea of documentation to wade through to get to the good stuff. Here are a few of the URLs we think will be relevant to programmers:

Programmability in Microsoft Windows SharePoint Services v2.0 Beta 2:

Windows SharePoint Services Web Service

Creating a Basic Web Part

Microsoft SharePoint Products and Technologies Downloads

These get you “into the tree”; the adjacent leaves are useful too.


Yesterday Simon Fell posted an ASP.NET OPML browser in response to Dave’s call to action.

Very cool. Looking over the code, I learned a few little tricks I didn’t know about.

I hadn’t realized that XmlDocument can load a remote URL, though it’s right there in the SDK docs. I seem to remember in the Aggie source code that they have a special wrapper to handle the Http fetch.

A little fooling around reveals that XmlDocument.Load() doesn’t handle 302 redirects gracefully. In fact, the resulting exception puts my HttpApplication into a permanently broken state until I restart the application :(

Update 2003-04-22: Simon is unable to reproduce this behavior. Neither am I when I point my code at his pingback url.

As best I can tell, the problem only arises when both documents—the code making the request and the code issuing the 302–are running on the same IIS 5.1 instance.