|| Tuesday, January 2, 2007
|| Monday, January 1, 2007
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.
|| Sunday, December 31, 2006
You will have to wait till next year to get this (and more) new functionality for the Code Comment Checking Policy. For example, a WiX-based setup:
Also in the box now: version information to easily see which assemblies are currently in use when you are adding the policy:
Also, there are a few changes to the configuration of the policy. Note that this will require you to remove & add the policy back to the team project's source control settings. The new defaults are the same values as the previously hard-coded configuration:
So check back next year!
|| Thursday, December 28, 2006
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:
|| Wednesday, December 27, 2006
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.
|| Friday, December 22, 2006
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.
Michael Howard has all the links in this blog entry Online Security Sessions from TechEd IT Forum Available. Topics include: malware cleaning, UAC internals, social engineering, Vista kernel changes, Vista firewall and IPSec enhancements. Which reminds me that the post-conference DVDs should tip up in my mailbox rsn.
|| Monday, December 18, 2006
Two weeks ago, during this year's AspInsiders summit, I got ahold of a 1982 (!) copy of "The Soul of a New Machine" at Half Price Books. I still have to decide whether the equally ancient Continental boarding pass DEN-SEA used as a bookmark will be kept too (I guess so), but the book is definitely worth your time - be it for a computer history lesson, or on the "signing up" concept and all other project management topics being touched on (without it being a pm book). The story in itself is more than fascinating, so although old by now, it does come highly recommended.
|| Friday, December 15, 2006
From Express to Team Suite & Team Foundation Server. Get it here
© Copyright 2020 Christoph Wille
newtelligence dasBlog 2.3.9074.18820