I have created another (hopefully useful) checkin policy for Team Foundation Server 2008 - one that checks C# and VB.NET project files for COM references. The idea came from a customer, where they require the developers to use "authorized" interop assemblies instead of developers recreating those by simply adding a COM reference to each and every project. And how do you prevent this? By having a TFS checkin policy in place.

A COM reference looks like this in an MSBuild project file:

  <ItemGroup>
    <COMReference Include="XcpControlLib">
      <Guid>{283C8576-0726-4DBC-9609-3F855162009A}</Guid>
      <VersionMajor>1</VersionMajor>
      <VersionMinor>0</VersionMinor>
      <Lcid>0</Lcid>
      <WrapperTool>tlbimp</WrapperTool>
      <Isolated>False</Isolated>
    </COMReference>
  </ItemGroup>

Instead of searching for the string "<COMReference" I decided to use the MSBuild Engine API in my implementation:

    public override PolicyFailure[] Evaluate()
    {
      PendingChange[] checkedFiles = PendingCheckin.PendingChanges.CheckedPendingChanges;
      ArrayList failures = new ArrayList();

      foreach (PendingChange change in checkedFiles)
      {
        string extension = Path.GetExtension(change.LocalItem);

        if ((0 == String.Compare(extension, ".csproj", false)) ||
            (0 == String.Compare(extension, ".vbproj", false)))
        {
          if (change.ChangeType == ChangeType.Edit || change.ChangeType == ChangeType.Add)
          {
            // this is a workaround because project.Load(fileName doesn't work in the same process as VS
            FileStream fs = File.OpenRead(change.LocalItem);

            Project project = new Project();
            project.Load(new StreamReader(fs), ProjectLoadSettings.IgnoreMissingImports);

            foreach (BuildItemGroup big in project.ItemGroups)
            {
              foreach (BuildItem bi in big)
              {
                if (0 == String.Compare(bi.Name, "COMReference", true))
                {
                  PolicyFailure failure = new PolicyFailure(String.Format(ComReferencePolicyStrings.activateMessage, change.LocalItem), this);
                  failures.Add(failure);
                }
              }
            }
          }
        }
      }

      return (PolicyFailure[])failures.ToArray(typeof(PolicyFailure));
    }

At first, I tried to load directly from the .??proj files, but Visual Studio (after thinking a bit about it it is pretty obvious...) doesn't like someone inside its process play around with the MSBuild engine. That's why I resorted to loading it indirectly.

For installation I have provided checkinpolicy.reg, however, you must adapt the path to the .dll before importing it into the registry.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\9.0\TeamFoundation\SourceControl\Checkin Policies]
"ChrisOnNet.CheckinPolicies.ComReferencePolicy"="C:\\Work\\ChrisOnNet.CheckinPolicies.ComReferencePolicy.dll"

Once registered, you can add it to your team projects:

As usual I have included the source code (BSD licensed) in the download:

ChrisOnNet.CheckinPolicies.ComReferencePolicy.zip (35.35 KB)

Yesterday, we found ourselves at the receiving end of an attack against one of our German Wikis that are running the ScrewTurn Wiki software. Turns out that it was a security issue even with the then latest version 2.0.23. Dario Solera - the maintainer of ScrewTurn - acted real fast when I informed him about the root cause of the attack and released v2.0.24 yesterday night.

Please download and upgrade immediately! The issue is being actively exploited (zero day if you so will).

This is a bugfix release for the previously posted port of nGallery to ASP.NET 3.5. The following changes are incorporated:

• Bugfix: slideshow had "photos/" hardcoded in nGalleryLib (for navigation buttons)
• Bugfix: Event log exceptions, please see Get GoogleBot to crash your .NET 2.0 site (plus ASP.NET 2 + url rewriting considered harmful in some cases). Nicolas Sorel was nice enough to provide me with his .browser definition files.
• Bugfix: default_highlight_image.jpg no longer resided in /photos and therefore caused an exception for galleries that had no highlighted image; moved it back to \photos
• Change: AlbumHandler no longer implements IHttpHandler
• Change: AssemblyInfo.cs changed version to 2.0 to differentiate from original 1.6.1

That's all the changes that happened, here are the source and deployment files:

nGalleryTNG2_ProjectFiles.zip (2.95 MB)
nGalleryTNG2_WebFiles.zip (1.03 MB)

I have posted an updated version

Given my plans to rather sooner than later upgrade my server to IIS7, I am currently switching all applications to ASP.NET 2.0 in preparation of this move. But there was nGallery, which I used all over the place when I needed a photo gallery...

Today I decided it was about time to do something about it, and gave converting nGallery to .NET 2.0 a try (actually all the projects target .NET Framework 3.5). Turns out it took me roundabout two hours for this whole endeavour. To save everybody else time, here is my VS2008 solution tree:

nGalleryTNG.zip (2.92 MB)

What is changed compared to the original nGallery 1.6.1 for ASP.NET 1.1? Here is a somewhat complete laundry list:

• Converted it to a Web Application project
• Placed all third party source code in the ThirdParty folder. That way I can always change and recompile if necessary.
• Took all static images from the \photos directories and put them into \images. No more mixing the photo handler & photo cache with the Web site's images.
• The album handler is now being abused in Application_BeginRequest, plus it now uses RewritePath. Fixes the darn Server.Transfer errors.
• Moved the configuration of nGallery from the data folder to App_Data. Other than that: no configuration changes.

I did not switch to ASP.NET 2.0 master pages, it still uses the old user control approach. But after all, I only needed it in a working fashion for 2.0+.

Note: I only tested the XML-based storage because that's how I use nGallery. The SQL-storage has received no testing whatsoever!

Download Web site files only: nGalleryTNG_WebSite.zip (924.39 KB)

If you are interested in IronPython, you should check out Matt's latest SharpDevelop addin: IronPython Integration In SharpDevelop 2.2. His blog post details the status of code completion, Windows Forms designer support, plus: converting code from C# or VB.NET to IronPython.

Please note that this is a work in progress, and that the official release of this addin will be for SharpDevelop 3 and IronPython 2.0.

Been on holidays, at conferences (eg last week Ask The Experts @ XTOPIA in Berlin), and worked on various projects - a couple of reasons it was rather quiet lately in this blog.

Yesterday I decided I needed a simple guestbook application for a to-be-developed private Web site, and because I didn't find anything that fit my needs I decided to write one myself with the goal of (ab)using XLinq in the course of this endeavour:

Guestbook_XLINQ.zip (7.09 KB)

Caveat emptor: I am no designer (surprise!). But thanks to no design it should be easy for you to add your own design. However, as this month's MSDN magazine is all about security, I decided to make the application production-ready security-wise. You'll find a lot of parsing plus XSRF protection (note: this version does not check for integer overflow in calculating the start row).

Missing features: this guestbook is not prepared for localization, nor does it use a control-based approach (where you drop those in your pages and get an in-place guestbook).

Update a version of this application for VS2008 RTM is available here.

Been following tf4mono development for quite a while, and now there is an installer that works on Windows with .NET 2.0 (more info). Be sure to check out the comments as it doesn't seem to work on a machine with Team Explorer already installed.

The check-in policy for TFS is revved to v2.1 and it comes with the "Included Paths" and "Excluded Namespaces" features announced earlier on my blog. The release announcement has more details; also, take a look at the screenshot tour of configuring CCCP.

When I released version 2.0 of the TFS CCCP, I also previewed one feature of the planned 2.1 release: included source control paths. That prompted a comment by Klaus that excluding namespaces for eg auto-generated code (think CodeSmith or code generated by GAT / GAX guidances) would be a nice feature too.

So I carved out some time today, and built the UI plus added the necessary code changes. To give you an idea what it will look like, here is a screenshot:

To do: testing, documenting, packaging.

Today, I finally released v2.0 of the code comment checking policy for Team Foundation Server (TFS) / Visual Studio Team System (VSTS) 2005. Two major new features: firstly, you can extend the policy to do more restricitive checks (i.e. verify that the comments are actually in line with the number of parameters). Secondly, you now get an MSBuild task to compute "code comment coverage" during an automated build - independent of VSTS / TFS!

As for future versions, it is already in source control - take the following team project for example:

Currently, you can turn on / off CCCP only for the entire team project. However, checking a unit test project or a Windows Forms smart client is rather pointless (in my opinion at least):

It is much more helpful for library projects that are to be used by different in-house or external customers, where with the help of eg Sandcastle you can create a nice help file. Therefore, vNext will sport a "Paths to check" feature:

I decided to go with include instead of exclude because it is much more explicit with regards what is being checked and what not. Currently, this is only available via source download.

The recently released version of CruiseControl.NET has a small issue with MSBuild Output in the Web dashboard: Unable to load transform: c:\ccnet\webdashboard\xsl\msbuild.xsl. A fix can be found in this thread in the fourth post. The reason to upgrade to 1.3? CC.NET now runs on .NET 2.0 (it has been ported), and it has a feature I want to try: integration queues.

On May 10^th, we recorded the interview on SharpDevelop that is now live on .NET Rocks. The interview starts around minute ten in this show. I tried to give some background on project history (if you really, really want all the details: look here), some of its features, where we stand today in comparison to VS Express, what's up next (hint: version 2.2 end of this month), and what the near future holds for SharpDevelop.

After the interview I realized that I mentioned most devs only by their first name, which happens if you are part of the team for nearly seven years! Therefore, I'd like to formally apologize for any confusion this might create and point to the development team page on our Wiki. There, you will find Daniel Grunwald (current technical lead), Mike Krüger (project founder now working for Novell on MonoDevelop, read an interview with Mike), Matt Ward, David Srbecky and the many others who make and made SharpDevelop the #1 open source IDE for .NET. Thanks guys!

A couple of links in closing: Download Wiki Forum

Today, I uploaded a preview of version 2.0 to CodePlex. There are two big ticket new items in comparison to version 1.3:

• Plugin support The TFS checkin policy only tests for existence of code comments. For many applications, this is just fine. However, sometimes you also want to test for completeness of comments (i.e. a refactoring "broke" the documented parameter list). In this case you can use the new extensibility API, which comes with two sample plugins in the cccplibcontrib project. The API allows you to select which checking you want to override or complement, and you get full access to the parsed source file just like the stock implementation ("abuse" for non-code commment checking purposes obviously possible too). If you come up with a cool plugin, be sure to contact me for inclusion into the contrib project!
• MSBuild task This build task lives in cccplib, which is entirely independent of TFS or VSTS (it was written by Matt Ward). Therefore, you can use it eg with CruiseControl.NET or simply as part of the local .*proj files. What's the purpose of this build task anyways? Simple: as part of the build, you get information on "code comment coverage", just like you do with let's say code coverage and unit tests. Currently, you only get an XML file with the report - if you are XSLT-savvy and want to contribute a HTML report transform, let me know!

To get an overview what v2 looks like, how to configure it, etc you might be interested in this demo screen recording.

I have been doing some sprucing up of SharpDevelop's Web offerings today - namely the code converter. Up until today, you only could convert syntactically valid classes. Recently, Daniel implemented the SnippetParser class, which is now in use for the snippet converter (C# to VB.NET, VB.NET to C#). Note: the Web service for code conversion does support both class and snippet conversion, a Windows client sample is available for the former.

Also new (just completed a few minutes ago) is the code formatter: it uses the highlighting engine from SharpDevelop's text editor to HTML-ize a bunch of formats: ASP/XHTML, BAT, Boo, Coco, C++.NET, C#, HTML, Java, JavaScript, Patch, PHP, TeX, VBNET, XML. Again, there is a Web service available, as well as a sample using the service. This offering is built upon the HtmlSyntaxColorizer sample that can be found in SharpDevelop revisions > 2522 (currently only on the build server)

I am sure that both the snippet converter as well as the code formatter are welcome additions. Spread the word! After all, it's free.

In The Virtues of Monoculture James makes an excellent point: "We celebrate the diversity of choices available to solve a problem and call it freedom. IT managers and CIOs look at it and call it chaos, confusion and uncertainty." Touché.

In my last blog entry UAC Elevation in Managed Code: A .NET COM Component Elevated I showed how to get up and running with an all-managed code solution for UAC and COM elevation. Today I want close out my series on UAC with some information on how to properly organize the project plus present a library you can reuse to get up and running quickly - without many of the manual and tedious steps from the previous proof of concept example.

Speaking of the previous sample: it is still the basis for this best practice, so the following directory layout will look familiar to you:

Before diving into code, I want to start out with the SampleSetup directory, which contains the executables. As you can guess, the starting point is Step1Register. It contains register.bat, which you have to execute:

Note that on machines without the .NET Framework SDK, there is no gacutil.exe. In that case, you have to drag & drop ManagedElevator.dll to c:\windows\assembly.

And in case you have been wondering from this screenshot, yes, the application now also plays nicely on Windows XP:

Of course, there is no consent UI popping up, nor is there a shield icon like there is on Windows Vista:

The magic for this cross-platform functionality is hidden in the UACHelper project - which brings us to the source section of this blog post:

All the necessary COM elevation magic is now moved to this neat little library - including the adapted UAC bits of VistaBridgeLibrary (no longer necessary). The names already give away the purpose of each class and where they are used:

• COMRegistration Used by the elevated component to automatically register the necessary registry keys.
• ShieldButton Used by the client to display a button with a shield icon (on Vista). For XP, no shield is rendered.
• COMElevation Starts the requested component with admin privileges.
• ElevatedProcess If you want to start a simple process elevated. Not used in this guidance.

The first customer of this library is the elevated component, so we start discussing this guy next:

At first glance, this is similar to the previous POC implementation. The main difference now is that I have broken down the functionality by feature area into namespaces:

• The "main" namespace
• The .Components namespace
• The .Guids namespace
• The .InterOp namespace

Let's look at these one by one.

The "main" namespace

Here, we have one class only:

class RegisterFunctions
{
  [ComRegisterFunction]
  public static void CustomRegister(Type t)
  {
    COMRegistration.RegisterForElevation(Assembly.GetExecutingAssembly().Location,
       SampleComponent.ClassToElevate,
       Global.AppId,
       100);

    // add additional "for elevation" components here by duplicating the above
  }

  [ComUnregisterFunction]
  public static void CustomUnregister(Type t)
  {
    COMRegistration.UnRegisterFromElevation(Assembly.GetExecutingAssembly().Location,
        Global.AppId);
  }
}

It is called when the assembly is regasm'ed, and it is here where you call into COMRegistration.RegisterForElevation to add all the necessary registry keys for elevation:

public static void RegisterForElevation(string assemblyLocation,
    string classToElevate,
    string appId,
    int localizedStringId)
{
 if (!UACHelperFunctions.IsUACEnabledOS()) return;

 // [HKEY_CLASSES_ROOT\CLSID\{71E050A7-AF7F-42dd-BE00-BF955DDD13D4}]
 // "AppID"="{75AB90B0-8B9C-45c9-AC55-C53A9D718E1A}"
 // "LocalizedString"="@E:\\Daten\\Firma\\Konferenzen und Talks\\..."
 RegistryKey classKey = Registry.ClassesRoot.OpenSubKey(@"CLSID\{" + classToElevate + "}", true);
 classKey.SetValue("AppId", "{" + appId + "}", RegistryValueKind.String);
 classKey.SetValue("LocalizedString", "@" + assemblyLocation + ",-" + localizedStringId.ToString(), RegistryValueKind.String);

 // [HKEY_CLASSES_ROOT\CLSID\{71E050A7-AF7F-42dd-BE00-BF955DDD13D4}\Elevation]
 // "Enabled"=dword:00000001
 RegistryKey elevationKey = classKey.CreateSubKey("Elevation");
 elevationKey.SetValue("Enabled", 1, RegistryValueKind.DWord);
 elevationKey.Close();

 classKey.Close();

 // [HKEY_CLASSES_ROOT\AppID\{75AB90B0-8B9C-45c9-AC55-C53A9D718E1A}]
 // @="ManagedElevator"
 // "DllSurrogate"=""
 RegistryKey hkcrappId