MOSS Cascading DropDownLists - The Sexy Approach - 1 of 2

Disclaimer: I recommend reviewing any/all code (including content that is linked to) and fully understanding what it does before deploying anything to your staging, test, and/or production environments. There is nothing worse than deploying code/solutions which cause critical errors that you don't know how to fix.

Link to next post: MOSS Cascading DropDownLists - The Sexy Approach - 2 of 2

I am really excited about this post for a number of reasons:

• AJAX makes things look really slick
  
• Cascading DropDownLists in SharePoint are a pain
• I've finally finished this project!

The task at hand was to implement Cascading DropDownLists within a standard SharePoint list (no InfoPath). Some resources that were immensely helpful while constructing this are as follows.

Regarding Custom Field Controls and Cascading DropDownLists:

• Data Cogs - SharePoint Cascading Drop Down Lists
• MSDN - Creating a Windows SharePoint Services 3.0 Custom Field by Using the EntityPicker

Regarding AJAX integration with SharePoint:

• Mike Ammerlaan - Integrating ASP.NET AJAX with SharePoint
• Rich Finn - Ajaxify MOSS

The project consists of two solutions, one which configures the web.config with modifications to allow ASP.NET AJAX, and one which deploys an AJAX Cascading DropDownList custom field control. This post will cover the integration with AJAX. My next post will cover the custom field control.

Prerequisites:

• You must have .NET Framework 3.5 SP1 installed on your server
• You must add the AjaxControlToolkit DLL to your VS solution

These are links to the four files (Feature.xml, manifest.xml, wsp_structure.ddf, AjaxControlToolkitSupportInstaller.cs) which are necessary for the solution which enables AJAX on your web application. I have decided to host the files within my GoogleDocs account because I like color coded files, there is too much code to paste it into this blog window, and I don't feel like creating a CodePlex project to upload, maintain, track bugs, and such.

If you are familiar at all with SharePoint Solution deployment, you will be right at home with manifest.xml and wsp_structure.ddf. I did not use any 3rd party tools for solution deployment. I used a simple C# class library with some custom batch files for processing the wsp_structure.ddf.

Please note:  You *must* create two GUIDS: one for the solution, and one for the feature. Also, be sure to create your assembly with a strong name, and insert your PublicKeyToken into the Feature.xml file.

I took bits and pieces from both Rich Finn's CodePlex project and Mike Ammerlaan's blog to create this feature. However, I really liked the way that Ted Pattison implemented a SPWebConfigModification feature in his post Using a Web Application Feature to Modify web.config, so instead of Ajaxify MOSS's command line approach, this is entirely browser based, and activated/deactivated within Central Administration on the "Web Application Features" page. Speaking from experience, be sure you have the correct web application selected before you activate the feature.

Part 2 to be coming shortly.

Enjoy!
--andrew

Links to solution files:

• manifest.xml
• wsp_structure.ddf
• Feature.xml
• AjaxControlToolkitSupportInstaller.cs

.Net Framework 3.5 SP1 and SharePoint Search/InfoPath/Etc.

Recently, I installed .NET framework 3.5 SP1 onto my production SharePoint WFE after thoroughly testing a new AJAX based field control I had developed.  In my staging and development environments, I encountered no issues with the framework itself, however, once I installed on production, a couple issues arose:

• Administrator approved InfoPath forms with custom code were causing errors (no indication of what the error was)
• Search Service was failing to crawl content with the error "Access Denied."

After some Googling, I came across a MS KB article , and an MSDN blog both referring to a security feature in IIS 6 called "loopback check."  This feature was added (also present in IIS 5.1) to prevent reflection attacks on the server.  Please see the blog entry by jiruss for more information on this feature.

Of the two workarounds listed, either disabling the loopback check, or modifying the host names specified in the registry, I believe modifying the host names to be the best solution.  I agree with jiruss in that completely disabling the loopback check increases the attack surface area of your system, and should be avoided.

The actual modifications I made were to add the URL/host headers/AAM mappings for my various sites (main portal and mysites were the only two that did not use the machine name in AAM) to a newly created "Multi-String Value" registry key called BackConnectionHostNames (each entry on a separate line) at the registry path:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0

Hope this helps any people experiencing "Access Denied" related issues after installing .NET framework 3.5 SP1.

Enjoy!

--andrew