• Choose the menu option Debug -> Attach to Process
• In the Attach to Process dialog look in the Attach to: section, if it says "Automatic Native code", then click on Select and choose Managed and Native
• Select the aspnet_wp.exe process
• Press Attach

Yet another in the note to self category.

When using App_offline.htm files to take down a site in IIS, if the file size isn't 512 bytes of content or greater then IE may choose to default to the "Show Friendly Http Errors". Comments count towards the byte size so client side comments will work too.

There is more about this at ScottGu's blog

Another for the Note To Self list

A lot of our sites use a url mapper, so when setting up the sites within IIS we map extension .* to the appropriate aspnet_isapi.dll.

I'd got carried away when setting up the webservice and did the same thing, resulting in a The HTTP verb POST used to access path '/WebService/WebService.asmx/DoSomething' is not allowed. error. Removing the .* mapping fixes this.

Definitely under the note to self category this one...

I've been working with installing a service and took the base code from our platform. Part of the command line specifies a parameter to be used within the installer, but no matter what I did I could not get the parameter to be picked up.

An example of the installation command line is
"C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\installUtil.exe" "C:\Services\MyService.exe" /SERVICENAME="My Special Service"
which, at least in theory, allows the service to be created so that in the Services dialog it is listed under the name "My Special Service"

A quick google with the right keywords and I stumbled across The curious case of InstallUtil and service parameters which both explains the situation and provides a lovely working solution.

In my case, the code was even simpler than the example as I was specifically looking for only one parameter, the service name, and so my OnBeforeInstall and OnBeforeUninstall become

protected override void OnBeforeInstall(System.Collections.IDictionary savedState)
{
   base.OnBeforeInstall(savedState);
   SetServiceNameFromCommandLineParameter();
}

protected override void OnBeforeUninstall(System.Collections.IDictionary savedState)
{
   base.OnBeforeUninstall(savedState);
   SetServiceNameFromCommandLineParameter();
}

where SetServiceNameFromCommandLineParameter is :

void SetServiceNameFromCommandLineParameter()
{
   const string SERVICE_NAME = "SERVICENAME";

   String[] args = System.Environment.GetCommandLineArgs();
   String no_log_file = null;
   InstallContext tmp_ctx = new InstallContext(no_log_file, args);

   string serviceName = tmp_ctx.Parameters[SERVICE_NAME];

   if (serviceName == null)
   {
      throw new ApplicationException(string.Format("{0} undefined", SERVICE_NAME));
   }

//Set service name
   this.serviceInstaller1.DisplayName = serviceName ;
   this.serviceInstaller1.ServiceName = serviceName;
}

where serviceInstaller1 is defined as private ServiceInstaller serviceInstaller1;

As to why this works in the base code, but doesn't for mine I have no idea, but I have at least got it working now

The migration process itself produced us a mapping of old Ids and new Ids, so all I needed was something that enabled me to plug in the old Id and generate the new URL to issue a 301 redirect at. I wanted the change to be as localised as possible, and didn't want to do anything that impacted the functionality of the existing editorial site. After a bit of head-scratching, I decided to make use of a resx file, specifically a local resx file by creating an App_LocalResources folder, and creating a new .aspx.resx file. I populated the resx file with a name value of the Old Id, and a value value of the New Id, and the look-up became straightforward. All I needed to do was catch the Old Id, wrap a
newId = GetLocalResourceObject(oldId.ToString()).ToString();
in a try/catch in case the old Id isn't in the resx file and that would do it. I built up a new url and issued a 301 redirect via
Response.Status = "301 Moved Permanently"; Response.AddHeader("Location", UriToNewId);

All of this code replaced the original code on the editorial site, and redirected any visitors to the new jobs site.

In September, I attended Sara Ford's session at Remix UK on Visual Studio IDE Tips and Tricks which was a really useful session in showing me just how little I knew about the shortcuts available within the Visual Studio IDE. Like many .Net developers, I've been using Visual Studio in one incarnation or another for years now and haven't necessarily spent time familiarising myself with the efficiency updates, new features and new keyboard shortcuts. I found the presentation format quite hard to gather the shortcuts from though and ended up trawling through Sara's blog of tips to get further details on the ones that looked handy (incremental find for instance).

I volunteered to do a session for the developers at Madgex as part of the ILP programme to pass this useful material on, and to encourage myself to find more tips. In preparing the talk (which is tomorrow) I've made a lot of use of a copy of Sara's book Microsoft Visual Studio Tips: 251 Ways to Improve Your Productivity as well as suggestions from the team.

I hadn't got very far into the book before I found myself changing settings in Visual Studio and trying things out - always a good sign. This is definitely a book to have next to you whilst you're sitting at your development machine and not one for general reading as I found some of the tips needed to be tried to make complete sense of them. I've also found myself trying out a lot of them on different environments - Visual Studio 2005, Visual Studio 2008 and SQL Server Management Studio (which doesn't get a mention in the book, but has quite a lot of tips that just work) to see what works in which scenarios, and which will prove useful to me and how I develop code. I've found the tips to be good-sized nuggets of information, almost all of which cover one scenario in isolation. They are easy to read and follow, and contain good text instructions with screen shots when they are helpful.

I'm not sure how much long term use this book has, I suspect it is one to have in the office shared amongst a group of developers so that everyone can have a browse, pick some efficiencies and pass the book on rather than one to dip into on a regular basis. Despite the fact that the tips from the book are also on her blog, the book makes them a lot more accessible and easier (at least for me) to read and implement. So, in summary, a worthwhile addition to a development library.

The Morning Brew #162 mentioned a tool Clone Detective which

is a Visual Studio integration that allows you to analyze C# projects for source code that is duplicated somewhere else. Having duplicates can easily lead to inconsistencies and often is an indicator for poorly factored code.

Today, a colleague and I spent some ILP time investigating the tool to determine whether it would help us in the Madgex environment or not.

We tried the tool out on a couple of projects, but due to it being a Visual Studio 2008 only plug-in our options were a bit limited. After installing the plug-in, the next thing we did was watch the video. This gave us a good overview of how it works, and where to find it (hiding under View -> Other Windows -> Clone Explorer). During the video it explained that effectively this tool breaks code down into a series of tokens, and then looks for other pieces of code which can also be broken down into the same series of tokens. The terminology took a little while to get a grasp of - there are clones and there are clone classes. A clone class is a series of tokens which is/may be repeated throughout the solution. A clone is an instance of this fragment. So, if there was a line of code which did something like a = b + c, the clone class would be [var] = [var] + [var], and the clones could be lines of code which are a = b + c or d = e + f (irrespective of whitespace or variable names etc).

It works across an entire solution, so we set it running and looked at the clones it found. Unfortunately, a lot of the clones that were detected for us were false positives - like properties which when tokenised are the same, but which can't really be re-factored. Additionally, some of the clone classes that it detected, are actually multiple presentations of the same code. For instance, one file I looked at had the following lines all marked as clones of different clone classes:

• lines 20 - 43
• lines 20 - 59
• lines 24 - 43
• lines 24 - 44
• lines 37 - 59

which basically tells us that the area of code from lines 20 - 59 should be re-factored into (probably) one new piece of code which can then be re-analysed to find out if other re-factorings are also worthwhile.

The interface is easy to get to grips with, and is accessed either via its own panels (Clone Explorer, Clone Intersections and Clone Results) or by an indication in the code window with a context sensitive menu item Find Clones, or Show Clone Intersections. Clicking on an item in the explorer allows you to navigate into more detail and find the clone class or find all instances of it. In a big solution, with a lot of clones (false positives or otherwise) the right click to get clone class listing can take quite a while - in the order of 10 - 20 seconds - which can result in lots of re-right-clicking when one is impatient. This may indicate a problem with scalability.

The tool would have proved a lot more useful to us with a few extras:

• Ability to ignore properties
• Ability to list all clone classes at once, rather than having to right click on a file in the Clone Explorer and choose Show Clone Intersections. Then picking a file in there and right clicking to select Clone Class x -> Find All Occurrences
• Ability to mark clone classes as "ignore" so it doesn't report on them again

So, our summary is, a nice idea but gives too many false positives and isn't refined enough at the moment to be of use within our environment on a regular basis. It may, however, still be useful as a one-off exercise (with patience) to find the key areas that should be addressed. In a less complex code base it might be worth another look. Additionally, if when working on some code we detect something that looks like its been copied and pasted, then it might well be worth running Clone Explorer to find other areas that could benefit from our refactoring.

This leaves us with the question, how else can we detect clones in our code base? Until we find something else, this is better than nothing. Does anyone have any suggestions of other tools which could address this area?

We've done some more work on integrating FxCop into our development process this week, and today Mike and I have sat down and started work on choosing which rules to validate against initially. To do this, we've based our starting set on the rules that Microsoft have switched on internally. Thus far we've been through the Design, Naming (mostly left switched off until the coding standards review is complete) and Performance rules.

Having set these up in a .FxCop project, I then wanted to be able to make use of the Post Build event to get the assembly analysed according to a predefined set of rules. This took a bit of research but I think I've got it sorted now:

Instead of using:
"C:\Program Files\Microsoft FxCop 1.36\FxCopCmd.exe" /c /f:"$(TargetPath)" /r:"C:\Program Files\Microsoft FxCop 1.36\Rules" /consolexsl:"C:\Program Files\Microsoft FxCop 1.36\Xml\VSConsoleOutput.xsl"
I'm using
"C:\Program Files\Microsoft FxCop 1.36\FxCopCmd.exe" /c /f:"$(TargetPath)" /consolexsl:"C:\Program Files\Microsoft FxCop 1.36\Xml\VSConsoleOutput.xsl" /project:"C:\Program Files\Microsoft FxCop 1.36\DefaultRules.FxCop"
and so am making use of the "/project" flag to specify the .FxCop file to run, and no longer specifying the /r (or /rule) tag to indicate where to find the rules. It is important that the .FxCop file doesn't contain any targets of its own, as otherwise both the assembly produced by the build AND the assemblies targetted in the .FxCop file will be analysed, which could lead to a lot of head-scratching when you try to work out why a source file that doesn't exist is causing problems :-)

More information on the options for the FxCop Command Line version is available here.

This is a tool I've used in the past with success, but which I found frustrating by the lack of integration into the IDE, instead relying on its own, slightly gawky interface.

Configuration

Rules can be switched off, switched on, and also custom rules can be added - read this tutorial for some useful hints and tips. Rules can also be supressed on a project by project basis, or globally by updating the FxCop.targets file - this will be really handy for how we want to set our chosen tool up.

Error detection

I left the rules as default, so they are based primarily on the Microsoft Design Guidelines. When run through the FxCop IDE a helpful link is provided to online documentation explaining the issue in more detail - for instance AssembliesShouldHaveValidStrongNames - and giving example fixes. The quality of errors returned were much better than CodeIt.Right, referring both to coding standards (naming of variables etc), but also performance and security improvements. There is no automagic correction meaning that developers learn from the warnings.

Automation

There is a command line version of the tool available which can be built into an automated build process. Additionally, this can be added as a post-build event outputting the results into the Warnings tab of the Error window in VS2005 and VS2008.

It took a while, but we've finally reviewed our static code analysis tools and made a proposal to use FxCop.

Of the tools we evaluated there were 2 main contenders - FxCop and Submain CodeIt.Right which I've covered in more detail in other blog posts.

The other tools, NDepend, Visual Assist and Resharper, didn't get close enough to our criteria on a number of points. NDepend and Resharper look like valuable tools, but not under the mantle of what we wanted from static code analysis. VisualAssist was more of a tool to help whilst you type - adding to the intellisense and providing prompts for syntax violations.

Note: We don't run Visual Studio team edition so there is no built in code analysis tool