MOSS Feature Dependencies

I recently had to build a MOSS solution that included two features - one feature created custom permission sets when activated, and the second feature created custom groups and bound the custom permission sets (created by the first feature) to the custom groups in the second feature.

I wanted to expose the features to the Site Features console so that they could be easily activated/deactivated by the Site Administrator, but I didn't want them activated out of order.

One approach to this problem is using a feature dependency. By specifying the GUID of a dependent feature in a feature.xml file, you can prevent the feature from being activated if the dependent feature has not already been activated.

Additionally, a user-friendly message is displayed to the site administrator specifying the dependent feature that must be activated before MOSS will allow the current feature to be activated.

All in all, feature dependencies are an easy-to-implement feature in MOSS 2007 that keep the deployment of your custom features trouble-free.

.DLL Hell, Part Duex

If you believe Microsoft's line that .DLL Hell is a thing of the past, I've got some swampland in Florida to sell you.

Recently we deployed a new solution to a MOSS server. For good measure, an IISRESET was performed AND the server was rebooted.

Guess what? One of the old .DLLs continued to be in use. This situation was finally remedied by totally un-installing the .DLL from the Global Assembly Cache ("GAC"), rebooting the server clean, and then re-installing the .DLL back into the GAC.

Finally, the new version was in use.

So, like the old story goes, despite the MS press to the contrary: reboot early, reboot often, and re-GAC early, re-GAC often...