We had a previous SharePoint project where we installed a custom HTTPModule to the SharePoint Web application. Since the SharePoint manifest file cannot inject entries into the httpModules section of the Web.config file (the manifest file can only insert entries inside the SharePoint section of the Web.config such SafeControl entries), we had to use a custom feature-receiver class, based on the SPFeatureReceiver. The custom feature-receiver class did it’s job nicely; whenever the feature got activated, the required entry in the httpModules section of the Web.config file got inserted.

Sequence property of the WebConfigModification can be used to figure out the uninstall order.

Unnamed sections such as connectionStrings and bindings sections, appear to have an XPATH expression that may result in duplicate matching. But, the ApplyWebConfigModifications method of the WebConfigModifications object will do it correctly as long as:

• EnsureChildNode is used as the type
• Add/Remove in order that is logical. Example: add connectionStrings section first then the add elements inside the connectionString section.
• If you are worried that de-activating a feature will obliterate the connectionStrings section because your feature created it, don’t. SharePoint will only take out the connectionStrings if there are no other entries created by the ApplyWebConfigModifications inside the connectionStrings section. If other features inserted 1 or more connection-string entries there, your feature-receiver will not remove the connectionStrings section. Now, if the connectionString section got edited manually, the SharePoint WebConfigModifcations object will not know this and it doesn’t matter how many child-nodes there are inside the  connectionString object. The root element (connectionString) in this case will be removed because in SharePoint’s perspective, there are no existing Web-config modifications inside connectionString.

Conclusion: if you are going to adopt feature-receivers to install web.config entries such as connection-strings and bindings (for Service-References), you must also adopt to policy to discourage manual insert/modification of the web.config entries. Be consistent.

SharePoint Saturday is coming up to the DC Metro area once more! It is scheduled for May 15 and it is going to be held at Northern VA Community College in Annandale. Here’s the link:

http://www.sharepointsaturday.org/dc/default.aspx

If you’re around DC area and you’re an IT professional using SharePoint, I recommend you attend. And you don’t want to miss this one. The last SP Saturday DC that I attended, they intentionally banned discussions of SharePoint 2010 in the official agenda (you can talk it on the hallways and breaks but wasn’t allowed at the session topic). Looking at the current lineup of the sessions, there are going to be a lot of SharePoint 2010 sessions! So attend!

SharePoint Saturdays typically have good sessions and it’s an opportunity to meet other SharePoint folks. If you’re not from the DC area, SharePoint Saturdays are all over the country and I would recommend checking  what the closest SharePoint Saturday is.

There is big SharePoint team in one of my customers and it’s a good blend of developers, engineers, analysts, and managers. When this team started in 2007, only a handful (2 people really) was knowledgeable in the ways of SharePoint. But because the user-base for this organization is so big, technical resources of other backgrounds started getting recruited to become part of the SharePoint team. Traditional network engineers became SharePoint farm admins. ASP.NET developers became SharePoint developers (that’s how I got into SharePoint). Other Web developers (Coldfusion) became SharePoint developers too.

There are still some Coldfusion developers in this organization but these Coldfusion apps are being phased out and eventually  will be converted to ASP.NET and/or SharePoint. These Coldfusion developers do not have a background on ASP.NET programming model, which is really different, closer to VB6 model if you look at it that it is closer to “classic ASP” model. “Classic ASP”, Coldfusion, and PHP are in the same category in my book—they are server-side scripting. ASP.NET and  SharePoint on the other hand are more object-oriented.

One of the Coldfusion developers asked me which topics on ASP.NET and SharePoint should they learn and in what order. They are excited to develop SharePoint stuff such as Web parts and workflows but need some guidance on where to start.

Here’s the list of high-level skills/topics I pointed out one should in order to develop SharePoint solutions:

• ASP.NET model
  • ASP.NET User Controls
  • Intrinsic Objects (HttpContext, Application, Request, Response, Server, etc.)
  • ASP.NET Page life-cycle
  • C#
  • ASP.NET Web App configuration files
  • .NET Namespaces
• Object-Oriented/Component Programming
  • Properties and Methods
  • Events
  • Delegates
  • Inheritance
  • Implementation (interfaces and abstracts)
• SharePoint Features Development
  • Visual Studio SharePoint Project Extensions/Templates
  • SharePoint Object Model
  • Deploying Features using STSADM