Visual Studio network performance with TFS through a VPN

I’ve been accessing a TFS server remotely through a VPN connection. I’d noticed that the performance was not that great, and then discovered this suggestion to specify the defaultProxy element in the devenv.exe.config file.

That worked pretty well, but I noticed that things were still a bit sluggish, so added a bypasslist element too, to ensure that anything on a 192.168.0.0 network doesn’t use the proxy either. That’s working nicely now.

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

Updating multiple lines in Visual Studio project files

A while back I blogged about how to change text from a single line in a Visual Studio project file. What about when you need to replace a number of lines of text? This worked for me:

$regex = new-object Text.RegularExpressions.Regex “\<Target Name=`“AfterBuild`”\>.+\</Target\>”, (‘singleline’)

We have to do a little more work compared to the first approach. We need to join all the individual lines into one single line so that the regex will operate correctly. Because we want to set options on the regex, we create that separately too. Note that the above example writes to a new .tmp file, so you can confirm the replace is working properly before overwriting the original files.

Project files are just XML files, so this technique should work for any XML file.

In my case, the solution was checked in to TFS, so the project files will need to be checked out before they can be updated. The checkout can be incorporated into the pipeline like this:

References:

• Find multiple line spanning text and replace using Powershell
• How can I replace newlines using powershell?

Assuming culture

I’ve just had an interesting bug report for Aussie Toilets. The stack trace starts with this:

System.Reflection.TargetInvocationException: TargetInvocationException —> System.FormatException: FormatException à System.Decimal.Parse(String s, NumberStyles style, IFormatProvider provider) à Gardiner.PublicToilets.Services.DataService.b\_\_3(XElement x)

There’s a small clue there, but the other big hint was the user’s regional setting:

Culture: fr-FR

It turns out in a number of places I’d been assuming the default number format, particularly instances of Decimal.Parse(), Convert.ToDouble(), and the popular String.Format().

So if you’re in France, you’d be used to seeing “123.49” written as “123,49”. The bug in the application was that the data being read was originally formatted in the former, but with the user’s regional settings set to ‘French (France)’ the parsing methods were assuming it would be formatted as the latter.

I’ve resolved the problem in this instance by explicitly specifying the InvariantCulture, as the data isn’t displayed to the user. If it were intended for user display, then allowing the user’s regional settings to influence the display would be quite appropriate.

FxCop (aka Visual Studio Code Analysis) will warn you about these kinds of issues, specifically CA1305 – Specify IFormatProvider. I’ve changed this warning (and a few others) to an error to ensure I don’t get caught by it again.

Expect Aussie Toilets v1.4 soon!

Sidenote

When I first started working on Aussie Toilets, I was doing it from the perspective of a parent who has had first-hand experience trying to find a public toilet for a young child. I hadn’t really considered another market for the app might be the overseas visitor. Maybe I should consider providing translations for some of the labels for these users too.