Simple PowerShell way to change a string across multiple files

This situation comes up only occasionally and I keep forgetting how to do it, so here it is so I can save myself the time next time:

1) Position myself in the directory where the files are located
2) Type in this quicky applet in PowerShell:

$filenames = ls *.exe.config
$match = "devserver2"
$replacement = "prodserver1"
$filenames | %{
>> $content = get-content $_
>> $content = $content -creplace $match, $replacement
>> $content | set-content $_
>> }

Note that I used the case-sensitive PowerShell replace verb. I wish this could be a one-liner but I haven't been able to figure out how to do that.

Helpful tip when using VS2008 over slow network connection

Disable the animations in VS2008 to improve performance over slow network connections:

Tools / Options / Environment / General -> uncheck the "animate environment tools" checkbox

Installing VS2008 C# services under Vista

There's something wrong with using a Visual Studio 2008 setup project ot install a windows service under Vista.

It's a pretty deep problem (see Alek Davis's post at http://alekdavis.blogspot.com/2007/09/deploy-windows-services-on-vista.html for details) ... and not worth the effort, in my estimation.

Just use INSTALLUTIL under the C:\Windows\Microsoft.NET\Framework\v2.0.50727 directory to install the service the old-fashioned way (INSTALLUTIL ) using the machine's administrator account (make sure to run INSTALLUTIL using "RunAs as Administrator" -- it doesn't seem to work if you try running it with an account with administrator privileges).

I included the Alek Davis link in case I need to actually create a service setup program in the future, here's hoping I don't.

I'm curious as to whether this problem persists in Windows 7.

This is another reason that Vista is not working out for me. If I hadn't gotten that free copy at the Microsoft Roadshow I'd have never touched it; perhaps this is why it was free.

Forcing Tortoise/SVN to refresh icon overlays

I use Tortoise/SVN at a client site as the tool for handling source control. The client's computers are rather underpowered, unfortunately, and often the Tortoise icon overlays can get really out of date (or disappear entirely). It's hard to tell what has been committed, what's changed, etc.

The easiest way I've found to force a "refresh" on these icons is to close the Windows Explorer window and run "TSVNCache.exe" from the command prompt. Give it a chance to run and wait a while (I'm finding that it takes my client's machines about 20 seconds), then start Windows Explorer. The icons should be back and (more importantly) should correctly reflect the status of files/directories.

Checking Session variables during Visual Studio 2008 debugging session

Often during debugging I need to enumerate the current session variables in use plus get their current values. It isn't documented but it isn't hard to do by examining the "Session" variable which is available during a debugging session.

• Add a "Session" watch variable in the watch window
• Under the "Session" watch variable, look under "Keys"
• Look under "Non-public members"
• Look under "_col"
• Look under "Non-public members"
• Look under "_entriesarray"

Each Session variable will be listed along with its current value.

Calling ASP.NET web service methods directly from a remote machine

Debugging a web service on my local machine is easy -- write the web service, publish it to my local machine, and then go to "http:\\localhost\webservice1\service1.asmx" to get a convenient prefab test form for entering simple data into the web service.

The prefab form is great for quick testing but unfortunately when you try and access it from a remote machine you get the message "The test form is only available for requests from the local machine."

There's a simple solution. Add these settings to the Web.Config file of the web service application:

<system.web>
<webServices>
<protocols>
<add name="HttpGet"/>
<add name="HttpPost"/>
</protocols>
</webServices>
</system.web>

This opens up a big security hole by letting remote users directly access the web service itself so you'd should naturally never do this in a production environment, but for quick-and-dirty testing it's quite useful.

Visual Studio 2008 setup projects always require .NET 3.5

I developed a simple console app in Visual Studio 2008 for a client whose XP machines are all running .NET framework 2.0 and sent them a setup program to install it.

Despite my specifically building the app to run under .NET framework 2.0 the setup program told the client that he had to install .NET framework 3.5 before continuing. I checked each dependency of the console app and the setup program itself and in each case it was built to run under .NET framework 2.0.

The solution was pretty out of the way -- in Visual Studio 2008 when building the setup program click on the "View" menu item, then "Editor," then "Launch Conditions" ... that's where the requirement for NET framework 3.5 is. Reset this to NET framework 2.0, rebuild the setup program, and the setup program will be satisfied with NET framework 2.0.