Skip to content

SharePoint

Custom Configuration Sections in a .NET config file

I’ve been working on a basic rules based web service for InfoPath forms.  The basic idea is to allow us to do “poor man’s integration.” to some back end systems now and then swap that out later without modifying the forms — since the forms will be adapted by several people and there may be more forms than we want to go back through. So a single web service that all InfoPath forms call on submission — by the way one they call in addition to whatever else they want to do — for instance, post themselves to a SharePoint site.

Anyway, so I needed a rules section in the config file where each rule had some attributes.  The problem is that .NET isn’t setup to easily hand you back the XML from a section in the configuration file — actually it gets pretty upset about the section even being in the file.  The solution is a IConfigurationSectionHandler.  Here’s what it takes to implement…

1) Modify the web.config file.

a) Add a <configSections> tag.  Note this must be the first tag in the <configuration> node.  This looks something like…

 

<configSections>
  <sectionGroup name=”customConfig”>
    <section name=”rules” type=”InfoPathRouting.Classes.XMLConfigurationSectionHandler, infopathrouting” />
  </sectionGroup>
</configSections>

In this case, I’m creating a new section called customConfig and adding a section in it called rules, which my class (InfoPathRouting.Classes.XMLConfigurationSectionHandler) in my DLL will handle.  (InfoPathRouting is the ASP.NET project name)

b) Add the actual section in the file.  In this case I’d add something like:

 

<customConfig>
<rules>
  <!– Whatever I want in here —>
</rules>

 

2) Add the class to the project.  Here’s the XMLConfigurationSectionHandler that I wrote.  The only restriction is that it must support the IConfigurationSectionHandler interface.  That interface only defines one method, Create().

 

using System;
using System.Configuration;
using System.Xml;
namespace InfoPathRouting.Classes
{
  public class XMLConfigurationSectionHandler : IConfigurationSectionHandler
{
    public object Create(object parent, object configContext, XmlNode section)
{
      return (section);
    }
}
}

In this case I wanted the XMLNode back so I could do my own thing with the XML fragment, so that’s what I returned.

 

3) Reference the configuration section in your code.  The following line of code fetches the XMLNode for my new rules section:

 

XmlNode rules = (XmlNode) System.Configuration.ConfigurationSettings.GetConfig(“customConfig/rules”);

That’s it.  I now have a repeatable way to store any kind of XML configuration I want in my app.config and web.config files.

Quick Tip: Don’t forget Outlook’s ability to display a web page for a folder

While working with a client recently we were discussing the issues with the Exchange web parts that are shipped as a part of SPS.  (This spawned the development on the new Exchange web parts, see my previous post.)

However, we came to the conclusion that it might be too small to include some email items in SharePoint.  So I mentioned the idea of doing things the reverse way.  Use Outlook to host your SharePoint site.  It’s a feature that’s been around in Outlook for a while.  All you have to do is…

  1. Create a folder in Outlook.
  2. Right click, select properties.
  3. Click the home page tab.
  4. Enter the address of your SharePoint site in the address text box.
  5. Select the show home page by default for this folder checkbox
  6. Click the OK button.

Now when you navigate to this folder in Outlook you’ll see your SharePoint site.  Not a bad deal when you’re looking to have a single dashboard to the organization and you live in email — as many of us do.

Beta Opportunities

I’ve got a series of web part packs and utilities of various sorts that I have on my radar to release in the next few months.  As I’m getting geared up for that, I’d like to see if anyone would be interested in doing some beta testing.  Here’s what’s on the plate short term…

  • SharePoint URL Management – If you let your users enter URLs on your SharePoint sites then you know that they can and do link EVERYWHERE.  The point of the URL management utility is to first, identify where users are linking to — in every URL field in every list in every site in a site collection.  The links are organized by server by URL and finally by where they are used from.  The second feature of the application is to do wholesale replacements of URLs and parts of URLs.  So you can change the server that a URL points to, the path of the page, or even everything about the URL including any querystring parameters provided.
  • Exchange Web Parts – SharePoint Portal Server offers some basic Exchange Outlook Web Access web parts. From my perspective they have two fundamental flaws.  First, they can’t be used in Windows SharePoint Services.  Second, they require that the user personalize the web part properties.  This web part pack won’t need the users to personalize the properties to be able to use it.  Thus it doesn’t require personalization at all.  The web parts figure out who the user is based on their login name.
  • Site Properties Pack – Site properties in SharePoint are very powerful.  They are a quick way to provide some “state“ information about the site which can be used to connect to other applications.  The site properties pack will contain a web part to visually display and modify site properties, a content editor web part which will take content and display it while doing property substitutions, and a list display web part that allows for display of a list with property substitutions in the URLs.  Together they are a toolkit to get you started with working with site properties for integration.

There are more applications to come but these are the ones that I’m to the point of writing documentation for.

Of Chickens and Eggs

While working with a client yesterday we were discussing the idea of having email (or parts of your email) as a window in SharePoint.  They were discussing how the limited space made things difficult while simultaneously discussing how it was important to have a one stop experience for the portal.  Then the comment came up that one member of the group always started their day with email.

A light bulb went off.  You can set an HTML (web) page as the default view for a folder in outlook.  Simply right click the folder, select properties, select the Home Page tab, enter your URL, Click the ‘Show home page by default for this folder’ checkbox and click OK.  Now whenever you click on the folder the web page appears.

Now they can decide whether they want Outlook housing SharePoint or SharePoint housing email via Outlook Web Access.  While on that note.  Send me an email if you’ld like to beta some utilities that are like the ‘My Inbox’, ‘My Calendar’, and ‘My Tasks’ web parts in SPS.  I have written a set which don’t require the user name to be set in properties so they can be deployed on a shared view.  I’d like to get some testing done on them.

SharePoint Advisor Live! Day 1

I’m out at SharePoint Advisor Live!.  It’s good to get to talk to the other speakers to learn about how they’re using SharePoint in their worlds and talking to the attendees to learn about their challenges.  A few of the highlights from the day…

  • Echo for SharePoint (www.winapptechnologies.com) – A winform based application to migrate lists and web part pages from one site to another.  Currently only works on the local server (meaning they’re using the SP API).  No command line yet — so it won’t fit into automated deployments.  It does, however, manage to get past some of the issues that the two migration utilities that I’m working on are still having.
  • ParallelSpace (www.parallelspace.com) – Content migration utilities and security assessment utilities for SharePoint.
  • Microsoft/Domino connection (www.msdomino.net) – Allows for Domino/Notes to be shown in SharePoint.  Not clear on how it all works yet, the demo wasn’t fully functional yesterday when I went by but it’s definitely interesting.

There were some interesting conversations about off-line clients and rich clients for SharePoint.  Mostly the idea that Access might be a front end to SharePoint.  Specifically the thought of adding relationships to SharePoint list data was discussed.

Recent Posts

Public Speaking