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: DownloadWikiForum

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]
  publicstaticvoid CustomRegister(Type t)
  {
    COMRegistration.RegisterForElevation(Assembly.GetExecutingAssembly().Location,
       SampleComponent.ClassToElevate,
       Global.AppId,
       100);

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

  [ComUnregisterFunction]
  publicstaticvoid 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 = Registry.ClassesRoot.OpenSubKey("AppID", true);
 RegistryKey appIdKey = hkcrappId.CreateSubKey("{"+ appId +"}");
 appIdKey.SetValue(null, Path.GetFileNameWithoutExtension(assemblyLocation));
 appIdKey.SetValue("DllSurrogate", "", RegistryValueKind.String);
 appIdKey.Close();

 // [HKEY_CLASSES_ROOT\AppID\ManagedElevator.dll]
 // "AppID"="{75AB90B0-8B9C-45c9-AC55-C53A9D718E1A}"
 RegistryKey asmKey = hkcrappId.CreateSubKey(Path.GetFileName(assemblyLocation));
 asmKey.SetValue("AppID", "{"+ appId +"}", RegistryValueKind.String);
 asmKey.Close();

 hkcrappId.Close();
}

Please take note that when the component is registered on eg Windows XP, no registry entries are written. After all, they are not needed.

The .Components namespace

Not much of a change - it contains the administrative component(s).

The .Guids namespace

The guids have been moved to a separate namespace. The reason? That way you can reference the assembly in the client project and use the guids directly - no magic strings anywhere any more.

The .InterOp namespace

This is the most important change with regards to the POC project - defining the correct ComImport'ed interface is now the responsibility of the implementer of the elevated component. That way, anyone needing access to this component only needs to reference the assembly and they are good to go. It is a bad idea to have this interface part of the client codebase!

Speaking of the client... here is the button code for DemoForm.cs:

private void cmdLaunch_Click(object sender, EventArgs e)
{
 if (UACHelperFunctions.IsUACEnabledOS())
 {
   IHelloWorld ihw = COMElevation.Start<IHelloWorld>(
        SampleComponent.ClassToElevate, SampleComponent.IHelloWorld);
   ihw.SayHello();
   COMElevation.Release(ihw);
 }
 else
 {
   ManagedElevator.Components.ClassToElevate c =new ManagedElevator.Components.ClassToElevate();
   c.SayHello();
 }
}

What looks interesting at first is COMElevation.Start as well as Release:

public class COMElevation
{
 publicstatic TIFace Start<TIFace>(string IID_Class, string IID_Interface)
 {
  return Start<TIFace>(new Guid(IID_Class), new Guid(IID_Interface));
 }

 publicstatic TIFace Start<TIFace>(Guid IID_Class, Guid IID_Interface)
 {
  object o = UACManager.LaunchElevatedCOMObject(IID_Class, IID_Interface);
  return (TIFace)o;
 }

 publicstaticvoid Release(object o)
 {
  Marshal.ReleaseComObject(o);
 }
}

Actually all it does is encapsulate the necessary calls to UACManager and Marshal. Why is there no if / else using IsUACEnabledOS here? Well, at first I thought I'd build such a switch, but then I thought again: why would I use COM InterOp if I don't have to? I already referenced the assembly for the component (for the guids and interop interface), so why not use managed all the way and save time? That's what I did in the cmdLaunch_Click event handler.

That's it for the code folks, now a little discussion at the end on why in the world would you even think about doing this in a cross-platform way, or why it is a stupid idea all along:

This approach is only sensible if your application runs as administrative user on XP, otherwise all the calls in the administrative component will fail. However, the cross-platform part is only there to make it a complete best practice, there is no "you must use it cross-platform" - if you build applications for Windows Vista with the eventual need to elevate a task, then UACHelper is definitely for you! (and forget about that it would even work on XP)

Oh, and I almost forgot - here is the complete download, source code included of course (my code is BSD licensed):

AutomaticRegistration.zip (91.92 KB)

The previous installment UAC Elevation in Managed Code: Starting Elevated Processes dealt with starting executables with the "real" administrative token. In this blog post, we deal with starting a COM component with elevated privileges. For in-depth background information, please consult Kenny Kerr's absolutely excellent post on Windows Vista for Developers – Part 4 – User Account Control.

To start with, we need a COM component. Instead of writing an ATL C++ COM component from scratch, I took the MyElevateCom sample from CoCreateInstanceAsAdmin or CreateElevatedComObject sample from the Vista Compatibility Team Blog. Note that for building it, check out my post Visual Studio on Vista: Not so Fast!

Assuming that you built and successfully registered the COM component (it is built to the instuctions from Kenny's post), you can go about and write the managed caller. First, we need a reference to the component:

Then comes the tricky part - actually instantiating the COM component. When you take a look at the C++ example, you see that quite some "moniker magic" is involved that cannot be replicated by simply newing up the component. So how to mimic this behavior in managed code? The Microsoft® Windows® Software Development Kit for Windows Vista™ and .NET Framework 3.0 Runtime Components comes to the rescue: inside, you find C:\Program Files\Microsoft SDKs\Windows\v6.0\Samples\CrossTechnologySamples.zip, which contains the VistaBridge sample.

From that, I took the VistaBridgeLibary, and modified the static UACManager.LaunchElevatedCOMObject method a bit:

[return: MarshalAs(UnmanagedType.Interface)]
publicstaticobject LaunchElevatedCOMObject(Guid Clsid, Guid InterfaceID)
{
  string CLSID = Clsid.ToString("B");
  string monikerName ="Elevation:Administrator!new:"+ CLSID;

  NativeMethods.BIND_OPTS3 bo =new NativeMethods.BIND_OPTS3();
  bo.cbStruct = (uint)Marshal.SizeOf(bo);
  bo.hwnd = IntPtr.Zero;
  bo.dwClassContext = (int)NativeMethods.CLSCTX.CLSCTX_LOCAL_SERVER;

  object retVal = UnsafeNativeMethods.CoGetObject(monikerName, ref bo, InterfaceID);

  return (retVal);
}

Modifications: the method is now public instead of internal, and CLSCTX changed to local server (otherwise it wouldn't work).

Next, we need a UI:

This button is the CommandLinkWinForms control from VistaBridgeLibary, with the ShieldIcon property set to true.

Let's hook up the event code:

private void tryItButton_Click(object sender, EventArgs e)
{
 Guid IID_ITheElevated =
  new Guid(0x5EFC3EFB, 0xC7D3, 0x4D00, 0xB7, 0x2E, 0x2F, 0x86, 0x4A, 0x1E, 0xAD, 0x06);

 Guid CLSID_TheElevated =
  new Guid(0x253E7696, 0xA524, 0x4E49, 0x9E, 0x50, 0xBF, 0xCC, 0x29, 0x91, 0x31, 0x23);

 object o = UACManager.LaunchElevatedCOMObject(CLSID_TheElevated, IID_ITheElevated);

 ITheElevated iface = (ITheElevated)o;

 // Call the method on the interface just like in the C++ example
 iface.ShowMe();

 // Release the object
 Marshal.ReleaseComObject(o);
}

The interface ID as well as class ID guids come directly from the C++ project (it is always a good idea to "speak" more than one language), but you could obtain those from the type library or registry as well if you don't have the source code of the component handy.

Object creation is handled via LaunchElevatedCOMObject, and the resultant object is cast to the interface from the imported type library. Noteable (and important) is the last line: because the object wasn't created by the runtime, we have to take care of its destruction (the created interface doesn't have a Release() method, so we use Marshal.ReleaseComObject).

That's it - your managed code is now instantiating an elevated COM object that has full reign over the system.

ElevateCOMComponentSample.zip (117.07 KB)

When you are working with Windows Vista, you know that even the administrative users are stripped ("filtered") of their privileges for normal operations, and that when you have to perform tasks requiring administrative privileges, you are presented with an UAC elevation prompt. The idea of this blog post series is to provide you with working samples on how to work with elevation from inside managed applications (you might also want to read Windows Vista Application Development Requirements for User Account Control Compatibility).

I want to side-step the really easy part - providing a manifest to start the entire application elevated (a good idea if the application makes no sense at all unless it has administrative rights, like regedit.exe). You can find information on those topics in Adding a UAC Manifest to Managed Code and Vista: User Account Control.

Now back to the topic of this post: App A needs to start App B with administrative rights (because App B e.g. needs to write to HKLM or Program Files). Therefore, we somehow must run App B as an administrative user (or with the non-filtered token of the current user). So how do we go about it?

First, some eye candy. You definitely already saw those nice shield icons before:

Those shield icons are stock on Windows Vista and indicate to the user that the action that hides behind the button requires elevation. I didn't create a button control myself - instead, I reused one that is readily available on the Web: Add a UAC Shield to your Winforms buttons in C#.

All I had to do myself was to start the Process ("App B"):

private void startProcess_Click(object sender, EventArgs e)
{
  ProcessStartInfo psi =new ProcessStartInfo();
  psi.FileName = theProcess;
  psi.Verb ="runas";
  Process.Start(psi);
}

The ticket (so to speak) for the elevation prompt is setting the Verb to "runas" in the ProcessStartInfo instance - this will pop up the elevation prompt if necessary when Process.Start is called.

This simplistic approach has a problem though - once App B is started, users can switch back to App A, because it App B isn't "modal" for App A. To solve this problem, I incorporated the approach from Daniel Moth outlined in his post Launch elevated and modal too:

private void launchModal_Click(object sender, EventArgs e)
{
  ProcessStartInfo psi =new ProcessStartInfo();
  psi.FileName = theProcess;
  psi.Verb ="runas";

  psi.ErrorDialog =true;
  psi.ErrorDialogParentHandle =this.Handle;

  try
  {
    Process p = Process.Start(psi);
    p.WaitForExit();
  }
  catch (Exception ex)
  {
    MessageBox.Show(ex.ToString());
  }
}

And that's it - App B is now modal. Once App B quits, control is relinquished to App A (which still doesn't run with administrative rights).

ElevateProcessSample.zip (21.1 KB)

Shortly after Christmas last year, I started with the Code Comment Checking Policy (read about it here, here and here) for Team Foundation Server. The idea for it was based on Florent Santin's TFSCCPolicy, but it used an entirely different approach (full-blown parser instead of RegEx).

As I never intended to compete with him (after all, we are both MVPs), I contacted him informing him of my endeavours. He liked the approach I took, and offered me take over on CodePlex because he had little time to spend on it anyways. So, at long last, today I set up shop as project coordinator at TFS Code Comment Checking Policy, Formerly Known as TFSCCPolicy.

The latest binaries are available, as well as the source code checked into the repository. If you have ideas on how to improve the feature set, let us know in the User Forum. Same goes for joining the team or letting us know about blog posts or tutorials you wrote.

I just gave StatSVN a try, which compiles statistics for Subversion repositories. For my trial, I used the 2.1 branch of SharpDevelop - which, because only created a month ago - should create a small and manageable statistic to start out with.

What do you need to get up and running with StatSVN (except, of course, StatSVN itself)? Well, the Subversion command line client (get it here), as well as Java. Working with StatSVN is really easy - simply follow the steps outlined in the readme and you can't go wrong - it even works nicely on Windows Vista.

If you don't want to install StatSVN on your box just to see how a report might look like for a real-world project, I have packaged the report generated for our SharpDevelop 2.1 branch:

DemoReport.zip (1.27 MB)

Before looking at the report, check out the LOC and churn rate I have posted below:

This branch was created from /trunk to only contain bug fixes from Beta 2 to release candidates and RTW. That's why there are spikes of activity, with no activity at other days. Also, not all developers are working on the branch, many are concentrating on developing features for the new version which lives in /trunk.

Matt followed through with his promise (see CCCP 1.2 Available With Setup) to write a tutorial on how to create a WiX-based installer with SharpDevelop: Creating an Installer with SharpDevelop

Updates

• TFSCCPolicy and CCCP Merge

As promised, the latest version of CCCP now sports a setup program. Setup is based on WiX, and has been created using SharpDevelop's WiX support. A special thanks flies out to Matt Ward, who provided me with the initial skeleton of this setup project. Please note, however, that you must use the bits from our build server because Beta 3 of SharpDevelop 2.1 doesn't work correctly with this setup project (\Source\Setup\Cccp.Setup.sln).

To give you an idea of the WiX project editing experience inside SharpDevelop I have included two screenshots for you (Matt promised a tutorial for his blog):

Above you can see the project tree plus the main WiX file, below the editing experience for the files included in the setup project:

There are four assemblies included in this setup project, with three being installed to the GAC - only cccppol.dll is copied to the target directory, and it has a registry key associated that enables the policy within VSTS. This is a change to previous versions of the policy that used ILMerge to pack those four assemblies into one.

The only other main change over previous versions is configuration:

The new options make hard-coded values from previous versions accessible to the administrator. Please note that this will force you to remove & then add the policy back to your team project if you used previous versions of CCCP (serialization changed).

I also put together a short screen recording on getting up and running with CCCP (sorry for the low audio quality, but I didn't manage to get Vista & my headset to cooperate nicely):

CCCP12InAction.wmv (1.58 MB)

Finally, here are the downloads:

CCCP12.msi (626.5 KB) [Windows Installer as demonstrated in the video]

CCCP12_Source.zip (1.06 MB) [Source code, BSD-licensed]

With this release I declare the CCCP feature-complete, at least when it comes to the features that I need. If you have further ideas for improvement, let me know by adding a comment to this post. If you find bugs, please let me know too. Oh, and if you like it, let others know!

Post Scriptum: yes, the MSBuild task hasn't been implemented yet. But the policy is done.

I wrote about SVK in Mirror, mirror on the wall and Going local with SVK. Now the release of version 2 has been announced. Note: WIN32 binaries are not yet available.

What is SVK? A quote from the homepage: svk is a decentralized version control system built with the robust Subversion filesystem. It supports repository mirroring, disconnected operation, history-sensitive merging, and integrates with other version control systems, as well as popular visual merge tools.

Work progressed much faster than I thought, so I can present you today with the next iteration of CCCP, the Code Comment Checking Policy for VSTS / TFS. What is new and improved over yesterday's release:

• VB.NET code comment verification enabled
• Code comment statistics tracking implemented, off by default
• Reference.* excluded (Web Services auto-generated files)
• Visibility special-casing of class type removed, CodeCommentCheckingVisibility honored
• Refactoring of CheckCodeComments, CreateInstance added for cleaner construction
• Unit testing automated and initial tests added
• Use String.Compare instead of == where potentially case sensitive or culture dependent

This equates to: the policy itself is feature-complete! It now sports the following functionality:

• Code comment verification for C# and VB.NET using a real parser engine
• Options to enable verification based on elements (methods, ...) and visibility (public, ...) - note that C# and VB.NET is auto-detected, no need to enable or configure this

Not included is "double-clicking policy violation automatically positions cursor on offending element" (I'd need to take a dependency on VS, and quite frankly have no idea how to implement this using VS' object model). Remaining on the todo list is the MSBuild task for calculating code comment coverage, but this will take a while because firstly I am not really that firm with writing MSBuild tasks, and secondly I will have to spend more quality time with IIS7 in the near future.

Without further ado, here are the goods:

• CCCP11_20061228_SetupOnly.zip (238 KB): Contains cccppol.dll, a .reg file and ReadMe.txt. Follow the instructions in the latter to modify the .reg file, and then double-click the .reg file to register the version control checkin policy.
• CCCP11_20061228_SourceSetup.zip (1.49 MB): Includes the above plus all the source code (BSD-licensed). This is a complete build tree minus only one tool: ILMerge. This must be downloaded separately. Please see the Source folder for the solution file, and PostBuild for instructions on how to build the final cccppol.dll assembly.

Further information:

• CCCP - Code Comment Checking Policy aka "Policy Triple-Slash" for VSTS / TFS, the initial post about the making of the checkin policy.

Updates

• 2007/1/21: TFSCCPolicy and CCCP Merge
• 2007/1/1: CCCP 1.2 Available With Setup (this is the latest released version)
• 2006/12/28: A newer version supporting VB.NET is available

The idea for this VS Team System version control checkin policy came up in the week before Christmas when I was pointed to one of the shortcomings of TFSCCPolicy, namely that it would flag commented-out methods as missing code comments. That triggered me looking at the source code and I saw that it was using regular expressions.

Why use RegEx when you can use a full-blown parser engine with a DOM? Well, that's what I thought and therefore got in touch with Daniel, technical lead of SharpDevelop. We discussed two potential ways: either going to the metal using NRefactory alone, or go it easy using the DOM and visitors. He even supplied me with a few lines of code to get started - of course for the latter option because I am a lazy coder.

So I set out yesterday to write that checkin policy. To make it really useful, I set up a library project which would contain all the logic, a unit test project for it, plus the actual policy project. The advantage? Well, the logic library can be reused in an MSBuild task, the idea is as follows: calculate the "comment coverage" just like you can do with code coverage and unit testing. (Sorry, but this isn't part of the package just yet)

Given that plan, I of course got around to the policy project as the last one today. When I was pretty much done, I set out to test it for the first time inside VSTS - whoa, what a surprise. It balked almost immediately. You can read my quest for enlightenment here, the main takeaway: don't outsmart yourself when you create a checkin policy which consists of multiple assemblies that don't live in the GAC.

That way I at least got around to deploy my first project using ILMerge. There is only one downside to using ILMerge - the merged assemblies don't retain their version numbers, which can be seen in this screenshot of the configuration dialog (NRefactory should be 2.1):

Aside from this minor glitch, the checkin policy is working fine. What can it do / what can't it do at the moment:

• It is currently limited to C#. VB.NET will be added later, all I need to do is instantiate the parser. It is as easy as that.
• Auto-update when files are saved. Someone please hit me with the clue stick.
• It doesn't exclude all auto-generated files, just the .designer files like TFSCCPolicy. I need to sit down and make a list.
• Not all elements correctly report the line number.
• Unit tests - well, only one at the moment. More to follow of course, including the full build automation.
• Cleanup in the logic library.

Other than that I would love to get feedback from you on this initial version! Simply post feedback on this blog entry.

Finally, the source code (BSD-licensed by the way) and the binaries:

CCCP10_20061227.zip (964.34 KB)

If you are interested in using it only, then please go to the Drop directory. For those interested in the code: start with the solution file in the Source folder (and then go to Setup).

Updates to the code / checkin policy will be linked to at the end of this post, so feel free to bookmark this blog post for your reference on CCCP.

Today I got around to trying CCNetConfig, which provides a UI for editing CruiseControl.NET's ccnet.config file. Thanks to the SharpDevelop project, I have a rather good test case with a couple of continuous integration plus nightly builds:

Our ccnet.config file is maintained by using Notepad (yes, you read that right). As such, I added a few <!-- --> comments here and there, mostly for pointing me to documentation, blog articles or just disabling a feature temporarily. Therefore, you can already guess my biggest gripe: on saving the file, it is auto-reformatted and all my comments are gone.

Other than that, it is a really good way of editing ccnet.config especially because all properties are easy to edit and you are presented the documentation automatically, no more searching around for tag / attribute help on the Web.  Overall: very useful if you don't spend all day being release manager.

Read the post from Miguel Microsoft and Novell Collaborate. Good news for Mono, OpenOffice and Samba.

Today, we shipped Beta 2 of SharpDevelop 2.1 (release information). Usually, we only ship two betas (followed by release candidates), but last weekend we decided to add a third one to this release cycle - to build a rock-solid foundation for the releases coming after version 2.1.

Speaking of last weekend: three of us met for the annual #develop developer days (#d^3 2006, a four day event) - way short of the original invitation list. But this turned out to be an advantage for discussing architecture and componentization. A lot of improvements already made it into Beta 2, a few more are yet to come in Beta 3.

Part of this effort was the creation of a presentation on SharpDevelop, which includes an area of interest to all .NET developers out there: a list of our components that can be reused outside the context of SharpDevelop plus the documentation and samples for those components. Remember: SharpDevelop is LGPL, so feel free to use our components!

In addition to this "general" slide deck, Daniel (SharpDevelop technical lead) also created a "Level 600" introduction to NRefactory, which can be found here. Definitely interesting for those of you that want to use code completion in our text editor control.

Finally, SharpReport now is a project in its own respect. The reason(s)? Well, SharpDevelop and SharpReport are developed on different schedules, so now we are customers of each other and no longer intertwined. Cool stuff coming on this front: export to various formats, allowing you to use SharpReport - yes - for generating reports in ASP.NET sites!

Beta 1 of SharpDevelop2 2.1 is available for download. While I was putting together the annoucement for v2.1 yesterday, I realized that for a point release, we really managed to put in a lot of new cool features:

• FxCop Support
• Component Inspector
• WiX Support
• Incremental Search
• Code Navigation History
• List Data Sources in SharpReport
• XPath Queries
• Code Completion for Different Frameworks
• GoTo XML Schema Definition
• Targeting Different Frameworks
• Hosting of SharpDevelop in 3rd Party Applications

A couple of WOW features (for me, at least): Not only can you compile an application for different versions of .NET, you also get version-specific code completion support. Another cool one is that you can host SharpDevelop in your application, providing your application a "macro editor" (on steroids I might add) with full .NET support. And to pick a third, code analysis rounds out our professional offering in addition to code coverage as well as unit testing.

Two features did not make it for the Beta 1 announcement as they don't yet cover all the scenarios we are hoping for: integrated Subversion support (yeah!) and targetting the Compact Framework for Windows CE devices. Those slipped silently into this release.

As you can see, SharpDevelop is ever growing and the developers working on it can be rightly proud of their achievements!

Finally, a kind of "call to action": let us know what you think! Not only in our forums, but also in your blogs, communities, et cetera. We need your feedback regarding feature set, stability, and much more.

Disclaimer: I am the PM for the #develop project.

After almost two years in development, the #develop team has shipped version 2.0 of its open source integrated development environment (IDE) SharpDevelop2. The new version supports the .sln / .*proj project file formats of Visual Studio 2005, therefore you can open and edit existing projects inside SharpDevelop2. The team however does not view SharpDevelop2 as a competitor for the Express line of products (comparison) from Microsoft, but it aims at software developers that need best of breed tools for their software development process - like unit testing, code coverage, documentation generation and more. In the same vein, version 2.1 will complement those existing features with integrated source code control, code analysis tools as well component testing.

SharpDevelop2 is especially well-suited for developers that chose the Boo language, because SharpDevelop2 offers first-class support for code completion as well as the Windows Forms designer. Aside from this unique selling point there a couple of smaller but nonetheless productivity-enhancing features in version 2.0: code conversion (eg VB.NET to C#, but see for yourself), support for Mono, documentation preview, RegEx compilation und quite a few more.

A lot of the features are owed to the ease of integration and extensibility provided by the addin system found in SharpDevelop2. This addin system can be used by developers in their own application - this being the reason for the rather unconventional license choice for SharpDevelop2: LGPL instead of GPL, which is much more common for development tools such as #develop. Re-use by third parties has been the driving factor to change the license.

Thanks to all the contributors that made SharpDevelop2 a reality, especially the technical lead on the 2.x effort, Daniel Grunwald.

Disclaimer: I am the Senior Project Wrangler for #develop. Therefore I am biased as well as knowledgeable.

Today, we shipped RC2 of SharpDevelop2. For those of you who haven't heard of it before, it is an Integrated Development Environment (IDE) for .NET. I will get to the features in just a second. First, I want to thank all developers that spent time on making v2 a reality. Daniel, the lead developer on v2, actually implemented a nice little tool for showing the project statistics, you can read more and download the utility in his blog Analyzing the code in SharpDevelop. Wow, we started quite a long ago on this baby.

I promised to get back to the feature set. Let's tackle it with more than a grain of blog posts and feature videos:

Supported Programming Languages

My definition of support is as follows: full code completion (aka IntelliSense) and a working Windows forms designer. Therefore, three languages qualify: C#, VB.NET and Boo. Aside from those fully supported languages, you get syntax highlighting for many more.

Speaking of syntax highlighting and code completion: both features are supported for XML files. You can check it out in the xml editing experience feature video (yes, this is available since v1.1!) You get this for MSBuild files too!

Features You Would Expect

Let's start with the integrated debugger. This has been our achilles heel since the very beginning, as implementing a debugger isn't exactly a piece of cake. However, thanks to David, v2 sports a debugger and you can watch a demo.

Let's continue with a simple list: Search & Replace, code folding, code templates (just try Ctrl+J in the editor), a toolbox and more.

Cool Features

Ahhh. At last. Let's see what we got:

• Unit testing (since 1.1, NUnit-based)
• Code Coverage (2.0, based on NCover - read more in Matt's blog post)
• Documentation generation (since 1.1, based on NDoc)
• Quick XML Doc (since 1.1, just try Ctrl+Q to get a preview of the HTML help that will be generated for your XML comments)
• Auto code generation (since 1.1, just try Alt+Ins)
• Code converter - convert your projects from C# to VB.NET and vice versa (since 1.1). New in 2.0: three way with Boo.
• Reports. Yes, SharpDevelop ships with a free-to-use report engine, #report. It was added late in 1.x, now improved for 2.0. Watch the demo
• Support for multiple frameworks - although 2.0 is the default, SharpDevelop can target 1.1 as well as Mono. Even Gtk# is supported.
• Ctrl+Mousewheel zooming. You will like it. I do.

What's Not There

We ain't a big software company, so we have to tackle features in order. Therefore, you won't find ASP.NET support in SharpDevelop, as well as others: CF support (planned for 2.1), version control (planned for 2.1), ClickOnce (planned for 2.1)...

Even if you don't plan on using SharpDevelop for your daily work, give it a try and let us know what you like and what not on our forums. You might even learn about a cool new feature like Component Inspector that is coming with 2.1, code-named Serralongue. And we'd be more than happy to welcome additional developers, testers, writers and translators.

Yesterday, I picked up on an old code piece of mine - sending images to the client via an HttpHandler. Why in the world would you implement that with a handler when there is http.sys kernel mode caching? Well, I had a few unique constraints:

• the images had to live outside the Web root and any of its vroots
• the image names had to be concealed because the naming would give away information, and renaming the images prior to publishing on the Web was out of the question

Now, a common approach to sending images from a certain directory (leaving requirement #2 by the wayside for the moment) would be this:

image.aspx?image=iamthebest.jpg

So what is wrong with this approach? First and foremost using an ASP.NET page. The page lifecycle is a drain on performance and throughput, because you simply don't need it. That sorts out why I chose to go with an HTTP handler.

Secondly, somebody could DOS your server. You heard me right. For the background, check the article Trap Alert: Files that aren't. A .NET version (managed C++) of this checker can be found in this download (the article Dateityp-Ermittlung in Managed C++ is only available in German).

How do you get around this issue? Well, how about reading the directory up front, and instead of having the filename in the URL, send the hash! When the image is requested, take the hash and look up the corresponding file, presto. In addition you get one security feature for free: no directory traversals can be hidden in your code.

When I uncovered the code yesterday, I decided to rewrite it for more general use. So what do you get?

• The ImageCacheControls project: it contains the ImageCache class, which does most of the heavy lifting. In addition, you get an ImageCacheControl server control, as well as the implementation of the HTTP handler. (Don't forget to check out the Readme.txt for the latest on feature set and known issues)
• The Web project: a rather simple Web site with demo files in it. The file I want to direct your attention to is Image.ashx. This is the one file - aside from the control project binaries - that needs to be copied to your projects to get started with ImageCache. Note that I made it easy to work with C# (default) or VB.NET.

Usage of ImageCache is demonstrated in default.aspx.cs plus the source code of default.aspx (design time of the control does not work, known issue).

The code behind looks like this (CreateMapping loads the directory contents, initializes the hash to file name map, stores it into the cache):

using ChrisOnNET.ImageCache;

public partial class _Default : System.Web.UI.Page
{
   protectedvoid Page_Load(object sender, EventArgs e)
   {
      // normally, this would be done in global.asax
      ImageCache.CreateMapping("demo", Server.MapPath("~/TestImages/"));

      // the DIY approach to rendering the image tag
      string testHash = ImageCache.GetHashForFile("026.jpg", "demo");
      Response.Write("<image src=\"Image.ashx?bucket="+
         "demo"+
         "&image="+
         Server.UrlEncode(testHash) +
         "\" />");

      // the elegant approach to rendering the image tag
      Response.Write("<image src=\""+ ImageCache.GenerateUrl("036.jpg", "demo") +
      "\" />");

      // see HTML source for server control approach (Design time not working, known issue)
   }
}

Rendering Image tags in Page_Load isn't nice, but after all it is only intended to show the functionality. Most likely you are going to use the declarative ImageCacheControl anyways:

<%@ Page Language="C#" AutoEventWireup="true"  CodeFile="Default.aspx.cs" Inherits="_Default" %>

<%@ Register Assembly="ImageCacheControls" Namespace="ChrisOnNET.ImageCache" TagPrefix="cc1"
%>

<html xmlns="http://www.w3.org/1999/xhtml"
>

<head runat="server">

    <title>Untitled Page</title>

</head>

<body>

    <form id="form1" runat="server">

    <div>

        <br />Using the ImageCacheControl:&nbsp;

        <cc1:ImageCacheControl ID="ImageCacheControl1" 


            Bucket="demo"

            FileName="026.jpg"

            runat="server"
/>

    </div>

    </form>

</body>

</html>

That's basically it. Let me know what you think.

ImageCacheTakeOne.zip (59.55 KB)

When I saw the MSDN Magazine article A Visual Studio Add-In That Converts C# Code To Visual Basic I simply had to extend this addin with our parser-based converter. Basically, I took the code I wrote for Code Converter for .NET 2.0 - Online, as well as Offline and put it into the addin, which has now an additonal conversion service in its list (conveniently the first one):

I have also updated the installer (which is now a release build, why was that provided as a debug build in the first place?), to be found in the PasteAsVBSetup\Release directory.

PasteAsExtended.zip (721.36 KB)

Enjoy!

Daniel published the first article in a series about using the SharpDevelop core to build your applications. Those of you tracking the progress of SharpDevelop through the years might be wondering "Aren't there restrictions because SharpDevelop is released under the GPL?" Well, version 1.x is GPL-licensed. But for version 2.0, we changed the license to LGPL. Thus, you can use all of the SharpDevelop2 assemblies in your applications regardless of license.

Aside from the articles, there are videos showing how to write addins for SharpDevelop2. This will get you started with plugging in functionality with SharpDevelop2 via addins (again, your choice of license now!). Be sure to always get the latest bits either via our source control server, or if you prefer from our build server.

Please note that SharpDevelop2 requires .NET Framework 2.0, and, the usual disclaimer, that it is a work in progress. This, however, does not apply to the core - it has been in development for four years+, and as such is very stable and proven. After all, it is the basis for a 300 kLOC C# application!

Today, a member of our German .NET community asked if it is possible to programmatically query the Google page rank. He had seen it done in PHP (here on the Google Community site), but didn't have time / PHP skills to translate it. All I found on a rather shallow search was PullRank, which I'd describe as non-fit for server use.

So I decided to set out to convert the PHP sample. Being PHP-challenged myself, I decided to give the PHP to ASP.NET Migration Assistant a shot. Whoha! That converted code is the most convoluted contraption to be called code I have seen - ever. I tried to get it to run, but failed because the conversion left me with some loose ends.

Instead of giving in, I contacted Christian Wenz to lend me a hand because he has some PHP experience. He thankfully hosted an "annotated" version of the PHP script so I could look at the output of various stages to test my solution with known-good values. That was most helpful.

Instead of doing a Web site demo application with everything intertwined, I split up the project into two - GPRDotNet being a DLL assembly project you can reference in any type of .NET application (Windows Forms, Web Forms, you name it), as well as a simple Web frontend to demo the usage: DemoSite.

Querying the page rank is really simple - the following snippet is the code from the "Check PageRank" button event handler:

protected void doCheckPageRank_Click(object sender, EventArgs e)
{
  GooglePageRank pr =new GooglePageRank();

  string url = webSiteUrl.Text;

  try
  {
    string rank = pr.GetRank(url);
    thePageRank.Text = rank;
  }
  catch (Exception ex)
  {
    // this is rather chatty (telling the end user everything *IS* a bad idea)
    thePageRank.Text ="Requesting the page rank failed. Reason: "+ ex.ToString();
  }
}

I want to emphasize that the code for the GooglePageRank class is a rather quick & dirty port of the PHP code and that it does not contain the necessary error handling you would expect for a server-side library. After all, it is just a proof of concept for our community.

Finally, here is the source code: PageRank.zip (26.89 KB)

If you find errors, please leave a blog comment so others know about improvements. Thanks!

This week I got started and I implemented a C# to VB.NET conversion. Today, I added VB.NET to C#, as well as C# / VB.NET to Boo. You can find the new converter at this URL:

http://developer.sharpdevelop.net/codeconvert.net/

In addition to the "usual" Web interface, I also added a Web Service. This enables you to remotely exploit the code conversion features of #develop. For example, in a Windows Forms application:

It behaves exactly the same way as the online converter. To get you started, the following download contains both the executable (in the bin/release folder) as well as the source code for the application shown in this screenshot. Have fun, and please don't forget to report conversion errors so we can improve the underlying NRefactory!

CodeConvertServiceClient.zip (38.57 KB)

Remember my call to action in Web applications and SMTP proxies don't mix well (it seems)? I mentioned that I am guilty as well - not only for Web applications as it turned out, but also for other server-based software, such as the Subversion post-commit hook I wrote.

You can already guess the contents of the change log (the last public version was 1.7):

• SMTP authentication & SMTP server port options added

If you are running the hook today, all you need to do is copy the new post-commit.exe over your existing one (assuming you use 1.7), and add the following four lines to your post-commit.exe.config's <appSettings> section:

<add key="SMTPAuthentication" value="" />

<add key="SMTPServerPort" value="25" />

<add key="SMTPUsername" value="username" />

<add key="SMTPPassword" value="password" />

Those values default post-commit.exe to the 1.7 behavior. To use authentication, set SMTPAuthentication to BASIC, and provide username and password. Most of the time, you will not need to play with the server port.

Finally, here is the usual binary & source code archive:

SvnPostCommitHook1.8.0.51014.zip (424.24 KB)

The Seattle Post Intelligencer has the by far best analysis on the "Mono BOF" at the PDC - read it here (Builder UK article for contrast). From the marketing aspect of the BOF refusal to the impact Mono will have to shops that bought into Windows (zilch, that is), those two articles cover all bases.

Especially the one I also like to point out: Mono will always play catch up with .NET (unless the development pace at MS slows down, but there was no such sign at this year's PDC). I had to laugh out loud when the Seattle PI quoted Somasegar as saying that "it's [Mono] a good science experiment that is happening there". And a warning that if it eats into their revenue, they will reconsider their current position. Given that Mono not only implements the ECMA standard, this certainly is an option. Taking further into consideration that MS sure as hell won't risk a class action suit from shareholders growling about lost money because of Mono, this is a threat scenario the Mono project better prepares for.

Before you flame me for the previous paragraph: I am project manager on the open source #develop project, so spare me the FUD blames. Especially if you are IANAL.

As a long-time subscriber as well as regular reader of the Bugtraq mailing list, I saw Gregory's post on decrypting MSN Messenger passwords. Because that one really piqued my interest, I immediately headed over to infoGreG and grabbed the source code, put it into a VS.NET 2003 C++ project, fixed a couple of compiler switches, and et voila - it works as advertised!

I finally got around to make a new version of SvnPostCommitHook. For one, it was about time to include Ben's changes, and secondly I wanted to roll a new version onto our Subversion box - it was still running on v1.3. So much for dogfooding...

With that, here is the change log. Note that the last public version was 1.5:

8/8/2005 - 1.7, Changes by Christoph Wille

• LookInfo getter logs when _lookinfo is null
• MailTextOnly & AppendDiffToMail properties added to .config file (text-only currently does not send diffs anyways)
• UU case added to svnlook parser
• Change SvnLookOutputParser.SkipBlanks method to return bool if StringCollection hasMoreLines

5/14/2005 - 1.6, Changes by Ben Lowery, ben AT blowery DOT org

• <pre> blocks for code#
• Updates CSS for new HTML
• Logic for finding CSS updated
• More logging

And here is the usual binary & source code archive:

I spent this weekend in Bad Ischl together with other members of the #develop open source project. This was the first get-together under the "#develop developer days" umbrella, and most of the core team was able to attend the two-and-a-half day event.

Our focus was to talk about #develop 2.0 "Corsavy", feature-set wise as well as hashing out architectural issues not addressed yet. Aside from that, coding was the #1 priority: to tackle a couple of outstanding issues, such as Forms Designer or Refactoring support. Spending time in one room makes communication so much easier when you have to solve tricky issues that span multiple modules in our infrastructure. It definitely paid off to spend this weekend together.

After quite some struggle, I got the mono::live CD to boot & actually work in Virtual PC. The first step to sucess is to create a new VPC image, and capture the ISO of mono::live for startup of your VPC image:

This thing will now ask you a couple of questions, such as country, keyboard layout, and screen resolution you would like to use:

Now for the stumbling block - mono::live (or Ubuntu, the underlying distribution, to be more precise) detects the graphics card emulated by VPC, however, uses the 24BPP mode with the VPC-emulated card only supporting 16BPP. Looks weird at first and had me stumped too. But I got help on GotMono.com (actual post, interesting snippet provided here for reference):

As far as I am aware, the easiest way to handle this is to just allow the machine to boot up all the way, and then when you can see the fuzzy background image (i.e., the stretched Mono logo) so that it looks like booting is complete, hit CTRL+ALT+F3 to bring up a command prompt.
 
Then type (or rather, cut and paste), this command, all on one line:
 
Code:
sudo sed 's/DefaultDepth\t24/DefaultDepth\t16/g' /etc/X11/xorg.conf > /tmp/xorg.conf && sudo cp /tmp/xorg.conf /etc/X11/xorg.conf && sudo killall Xorg

to restart the X server at a color depth Virtual PC can handle.

Because pasting didn't work the way I wanted it to, I ended up typing this stuff using US keyboard settings on a German keyboard (don't ask). Anyways: this did the trick! Now I can start exploring mono::live without having to reboot my machine.

Ben Lowery sent me changes for the SvnPostCommitHook application. From his email: Here's my version of the code.  I updated it to be able to use DotNetOpenMail, as I sometimes have problems using CDO through System.Web.Mail. I also updated it to support a pluggable mail formatter, with a text and an HTML formatter in the current code.  At the moment, it's up to the mailer to decide how mail is sent, but that could be easily pulled out into a config file at some point, as could the format of the html or the css that I'm using.

Change log details:

• Added abstract base for mailing
• Moved System.Web.Mail based mailer to CdoMailer
• Added option to send mail with DotNetOpenMail
• Added MessageFormatter hierarchy for message formatting
• Added HtmlMessageFormatter for html change messages
• Moved text message formatting into TextMessageFormatter
• Added package batch script to rename exe to post-commit.exe
• Added Library directory for references
• Added log4net to the Library directory
• Made SilentCmdLineApplication::Execute simpler
• Moved parsing logic into SvnLookOutputParser

SvnPostCommitHookv1.4.zip (417.83 KB)

Saw this over at OSNews.com: OpenMFG, the makers of open source ERP software, have released OpenRPT, a report writer for ad-hoc Web-based reporting. It creates graphical, embeddable reports, similar to the commercial software Crystal Reports or Microsoft Access report designer, but runs on on Linux, Mac OS X, and Windows. It supports graphs, integrated barcodes, label printing, and watermarks and report definitions can be stored in a PostgreSQL database as XML, or exported to individual files.

Looks worth checking out.

The post commit hook for Subversion now has reached a stage where I consider it feature complete. Newly added for this release:

• log4net for logging important information (ie exceptions) necessary for debugging a hook that is supposed to run automatically. Note that it uses v1.2.9 of log4net, which is a Beta release. The log file name is post-commit.log (you can change this in post-commit.exe.config)
• Nicely formatted commit mail. The change log line items are parsed, the A, U & D information is used to build Added, Modified & Deleted sections in the message.

Here is an example of the message format (from the #develop commit mailing list):

Author: mattward

Date: 2005-04-10 20:06:25 +0200 (So, 10 Apr 2005)

New Revision: 1840

Log Message:

Added basic .manifest schema.  Schema annotation displayed alongside 


auto-completion list. Mixed namespaces and simple content types 


now supported.  Added attribute value auto-completion.


Added:

trunk/SharpDevelop/data/schemas/manifest.xsd

....

trunk/SharpDevelop/src/AddIns/.../SimpleContentWithAttributeTestFixture.cs

Modified:

trunk/SharpDevelop/data/resources/StringResources.dk.resources

...

trunk/SharpDevelopResources/LanguageResources/LocalizeDb.mdb

Deleted:

trunk/SharpDevelop/src/AddIns/.../ActiveElementPathTestFixture.cs

          

 -- SvnPostCommitHook 1.2.0.50410 -- 

Installation Take all three files from \Hook and place them in your repository's hooks directory. Open post-commit.exe.config and modify the entries in the appSettings section to match your installation and needs.

Test it Run post-commit.exe once interactively from the command line to see if your installation is ok. Potential errors are only logged to post-commit.log, not to the Console. So be sure to check it!

Finally, the download:

I updated the post commit hook application, however, installation advice from the original blog entry Post Commit Hook for Subversion, the .NET way still applies. What's new? The revision info is parsed and more nicely presented in the commit mail message. Because of info parsing, one call to svnlook could be saved.

SvnPostCommitHook1.1.0.50410.zip (14.08 KB)

In the entry Subversion on Windows as a Service, plus Commit Hook and Backup Script I showed a batch file for hooking into the post commit event of a repository. This batch file annoyed me from the very beginning. During the Indigo Community Day on Thursday in Munich I decided that it was about time to get rid of it, and after yesterday's party, I thought it might be a nice pinky exercise to do the basic port to C# today.

And yes, it is very basic at the moment. All you need to do is take post-commit.exe and post-commit.exe.config from the \SvnPostCommitHook\Hook directory in the downloadable zip file and drop those two into the hooks directory of your repository. The .config file is your ticket to customization:

<?xml version="1.0" encoding="utf-8" ?>

<configuration>

 <appSettings>

  <add key="SvnLookPath" value="C:\Program Files\Subversion\bin\svnlook"
/>

  <add key="MailTo" value="commitlist@yourdomain.com"
/>

  <add key="MailFrom" value="commithook@yourdomain.com"
/>

  <add key="MailSubject" value="Your project name rev {0}, {1}" />

  <add key="MailServer" value="localhost" />

 </appSettings>

</configuration>

Just as the batch file, post-commit.exe's task is to read the change log and commit message, and post it to a mailing list that distributes the information to the project stakeholders. Therefore, you need to configure the four Mail* settings to match your configuration and preferences. The SvnLookPath needs to point to your Subversion installation, however, most installations should be fine with this default.

How can you test the operation of post-commit.exe? This is the syntax:

post-commit <repository> <revision>

For example:

post-commit e:\subversion\fidalgo 1830

In the current version, testing is highly recommended as no logging or exception handling is implemented.

SvnPostCommitHook1.0.0.50409.zip (12.07 KB)

The source code is BSD-licensed. Future plans are to fully parse the svnlook output, as well as add a logging infrastructure to easily find configuration problems during normal operations of your Subversion server.