Joshua Flanagan

This is a tip for anyone using the SubVersion command-line client (svn.exe) that can't mentally process unix-style diff output.

By default, running the svn diff command on a modified file in your working directly will dump diff output to the console:

C:\work\ProfileView>svn diff
Index: ControlBuilder.cs
===================================================================
--- ControlBuilder.cs   (revision 25)
+++ ControlBuilder.cs   (working copy)
@@ -59,10 +59,11 @@
             if (validationType != ValidationDataType.String)
             {
                 validator = new CompareValidator();
-                validator.ID = "val_" + property.Name;
+                validator.ID = "v" + property.Name;
                 validator.Operator = ValidationCompareOperator.DataTypeCheck;
                 validator.Type = validationType;
                 validator.ValidationGroup = DEFAULT_VALIDATION_GROUP;
+                validator.SkinID = "validators";
                 validator.ErrorMessage = DEFAULT_VALIDATION_ERROR_MESSAGE;
                 validator.Display = ValidatorDisplay.Dynamic;
             }

In this simple example, you can probably figure out what changed. But if the modifications were more extensive, the output would be harder to interpret.

Enter WinDiff. WinDiff is a graphical utility for visually comparing 2 files or the contents of 2 folders. There are many other similar tools available - I choose WinDiff because its free, and its already on my system. It comes with Visual Studio .NET (if you install the VC++ Tools); or if you don't own VS.NET, you can get it with the Windows Support Tools.

The SubVersion client allows you to specify a 3rd party diff tool using the diff-cmd argument. However, the argument list it passes to the tool does not match the input arguments that windiff.exe is expecting. The solution is to create an intermediate batch file that translates the arguments. I created svnwindiff.bat in my SubVersion install folder (c:\apps\subversion). It contains a single command:
"C:\Program Files\Microsoft Visual Studio 8\Common7\Tools\Bin\windiff.exe" %6 %7

I then specify this batch file as my external diff tool:
C:\work\ProfileView>svn diff --diff-cmd c:\apps\subversion\svnwindiff.bat

Which will open the following window:

Finally, to save yourself some typing, you can set WinDiff as your default diff tool by editing your SubVersion config file located at:
C:\Documents and Settings\username\Application Data\Subversion\config

Find the commented (#) line for diff-cmd, uncomment it and set the path, so it looks something like this:
diff-cmd = c:\apps\subversion\svnwindiff.bat

Now, simply typing svn diff at a command-line will automatically launch WinDiff to visually display the differences.

Update: I've been taken to task for mentioning an ancient diff tool like WinDiff. While I stand by my initial reason for WinDiff ("its already on my system"), I figure it's in your best interest that I mention some more modern alternatives. A few free ones: KDiff3, WinMerge, and ExamDiff. Scott seems to like the $30 Beyond Compare (although it is conspicuosly missing from his Ultimate Tools List).

I've posted the source and binary for the latest release of my ProfileView ASP.NET server control. I was finally able to address the much requested fix to make the order of the properties displayed at runtime reflect the order they are declared in the web.config. Here are the release notes:

• Properties now display in the order they are listed in web.config
  
• Design-time view now uses same rendering method as runtime
• Fixed design-time bug that caused it to fail when a profile property type was not specified
• Design-time view now has a Smart Tag to allow you to preview an anonymous user's profile
  

Mikhail Arkhipov already posted exactly what you need to know to debug classic asp pages in Visual Studio 2005. His post includes the instructions for Win2K3, but the comments include instructions for WinXP.

I'm only posting this in hopes that it helps the search engines lead people to his post. When I searched for "debug classic asp visual studio 2005", I had no luck. If I would have abbreviated visual studio as vs (as he did in his post title), I would have found it immediately.

Of the billion toolbar buttons that Visual Studio 2005 includes, I couldn't find one to open a command prompt to the project directory. This is a must-have for us command-line SubVersion users. Luckily, a quick Google search turned up this post (its actually the comment from Barry Gervin that I credit). Updated for VS 2005:

From the Tools -> External Tools... menu, click Add, and fill in:

Title: Command Prompt &Here
Command: C:\WINDOWS\system32\cmd.exe
Arguments: /k ""C:\Program Files\Microsoft Visual Studio 8\VC\vcvarsall.bat"" x86
Initial Directory: $(ProjectDir)

Note the Title is important only because I wanted to use the letter 'H' as my shortcut key since it is close to the 'T', and unused on the default Tools menu. This enables the very easy one-handed keystroke ALT+T,H.

I then went to Tools->Customize..., selected Tools from the Categories, then found "External Command 3" (there were 2 other tools already registered in VS) in the Commands section, and dragged it up to my toolbar. Right-click on the new button on the toolbar, select Default Style, then Change Button Image, and choose the square (its a good starting point). Using Edit Button Image... I drew a crude "C:".

When creating a designer for an ASP.NET server control, it is often very useful to read settings from the user's web.config file. In previous versions of the .NET Framework, you had to jump through hoops to access the web.config file at design time. I was very thankful for this solution when I needed it, but I'm happy to move on. The dependency on EnvDTE felt wrong, and the fact that it used COM interop with the VS.NET IDE meant it probably would not work with any other tool.

Thankfully, in .NET 2.0, it is much simpler. If you want to get the full path to web.config (useful for parsing the XML manually), it has been reduced to:

using System.Web.UI.Design;
//...
IWebApplication webApp = (IWebApplication)Component.Site.GetService(
typeof(IWebApplication) );
IProjectItem item = webApp.GetProjectItemFromUrl("~/web.config");
string webConfigPath = item.PhysicalPath;

Note: you will want to check for nulls and handle appropriately. The call to GetService could return null if the design tool hosting your control does not support this service (something other than VS.NET). And of course the call to GetProjectItemFromUrl could fail if there is no web.config in the project.

Even better, instead of parsing web.config yourself, you can get strongly-typed access to the configuration using the new classes in the System.Configuration namespace. For example, in my ProfileView control, I use code similar (more null checking) to the following to discover information about the configured profile properties:

using System.Configuration;
using System.Web.Configuration;
using System.Web.UI.Design;
//...
IWebApplication webApp = (IWebApplication)Component.Site.GetService(
typeof(IWebApplication) );
Configuration config = webApp.OpenWebConfiguration(true);
ConfigurationSectionGroup systemWeb = config.GetSectionGroup("system.web");
ProfileSection profileSection = (ProfileSection)systemWeb.Sections["profile"];

foreach (ProfilePropertySettings configProperty in profileSection.PropertySettings)
{ // read the settings in each configProperty }

Once you get the Configuration object as demonstrated above, reading a value out of the appSettings section is as easy as:

config.AppSettings.Settings["maxRetries"].Value