Blog posting for December

I finally remembered my Google password so I can post to my blog again. Unfortunately, I haven't come up with anything else to blog about since my last post.

Should I think of something, though, I now will be able to post it.

Use PowerShell to remove a directory from Subversion

Sometimes through an oversight on my part or some oddity of Subversion I need to completely remove a directory from source control so I can get the project directory working, building correctly, and then re-enter it into Subversion as new.

The quick answer is to get rid of all the ".svn" directories in each subdirectory of the project.

The easiest way to do this with PowerShell is to have it recursively locate and then delete the directories.

The one-liner:

gci -recurse -include .svn -force | remove-item -recurse -force

Works like a charm.

Two PowerShell oddities with "Rename-Item" and "Move-Item"

Oddity 1: I've got a subdirectory in a directory named "python." I want to rename it "Python," just change the case of the directory name.

Can't seem to do it with the PowerShell "Rename-Item" command. None of these will work:

rename-item python Python
rename-item 'python' 'Python'
rename-item 'C:\python' 'C:\Python'

Same when using double quotes instead of single quotes. All get an error message that the source and destination names are the same. The workaround to get me back working again was simple:

rename-item python tempname
rename-item tempname Python

By and large I like PowerShell's VB-style slackness with case sensitivity but a couple years of coding with C# now has given me a definite preference for tighter discipline. It's just too bad you can't turn case sensitivity on and off.

I Googled this problem and didn't find any other complaints or solutions, I'm guessing that this is just not that big a problem for Microsoft. Maybe it'll be quietly fixed in PowerShell 2.

Oddity 2:

The old DOS "Move" command and the PowerShell "Move-Item" commands are no longer equivalent, and in a good way. The difference is when moving items between volumes: when moving something on the same volume the two are equivalent, but when moving between volumes ... well, it won't let you do it. You've got to do a copy from one volume to another, then manually delete the original.

Overall PowerShell is so utterly superior to DOS that it's hard to conceive of a feature being "missing" from it where it was once present in DOS; rather, it's removed a bug from DOS.

What happened to the Visual Studio 2005 "property" snippet in VS2008?

There's a good reason behind it, I'm sure, but one of the snippets I used constantly with Visual Studio 2005 was the "prop" property snippet and it's changed in VS2008.

The client I'm working for has upgraded to VS2008 so I've begun coding in it and, by and large, it's acting pretty much the same as Visual Studio 2005 except for odd little quirks like this.

The VS2005 property snippet acted like this -- you typed in "prop", double-tabbed, and VS loaded this snippet:

private int myVar;
public int MyProperty
{
get { return myVar; }
set { myVar = value; }
}

It was great -- I was using it like second nature. The VS2008 property snippet returns this instead, though:

public int MyProperty { get; set; }

Considerably more "bare bones" than the one I was used to with VS2005. As I mentioned earlier, I'm sure there's a good reason for it (since I notice VS2008 has expanded the number of property snippets for C#) but I do miss the old VS2005 version.

The answer turned out to be pretty simple: just copy the "prop.snippet" file from a workstation that still has VS2005 on it (it's in the "Snippets" directory under VC#) into the matching directory on the workstation with VS2008, renaming it to something like "propc.snippet."

On my machine it just meant getting that "prop.snippet" file and pasting it as "propc.snippet" into "C:\Program Files\Microsoft Visual Studio 9.0\VC#\Snippets\1033\Visual C#".

I'll figure out why it was changed later. For the time being, this gives back a great function.

Visual Studio 2005 debugger irritation with double backslashes

I'm sure everyone knows this but me but I couldn't find this information easily today and wasted time solving it, so I'm posting it here on the chance that a search engine spider will grab it and index it in case someone else can use it.

When stepping through a section of code that was reading records from a SQL database, I watched a variable in the Visual Studio 2005 "Immediate" window which was pulling a field from a SQL record representing a pathname.

The textfield in the database record was "C:\directory\subdir1" but in the "Immediate" window it was listed as "C:\\directory\\subdir1".

Since the error I was trying to track down was a "file not found" I was sure that problem was around there, there was something I was doing that was causing the backslashes to stutter and double up in C#.

I tried just doing a

(Variable.ToString()).Replace(@"\\",@"\");

but no good, the debugger said the double backslashes were still there. I then spent 20 minutes down memory lane handling the problem using a Regular Expression but the debugger showed that that didn't work either.

The answer is simple: the double slashes are an illusion of the debugger, they're not real. By default the debugger will display backslash characters as double backslashes since it's using the backslash as a control character. The pathname was fine, it was getting it from the SQL record exactly the way I expected, it just didn't "look" that way (the "file not found" error was a few lines away).

Just write the text out to a control on a form or out to the console ... it's fine. The debugger is still our friend.

It's merely a painful hangover from 5 years developing with VB.NET and its "vbCRLF" instead of C and its "\n"; you forget how normal languages handle control characters.

EventLog Problems in C# in 64-bit .NET Framework 2.0

While developing a web service in C# I decided to have it write its audit/error messages out to a custom event log -- writing them out to the Application Event log seemed rude since this wasn't my server and the client was already having all sorts of other apps write to the App log.

Besides, I thought it would make life easier for me since all my messages would be in their own separate-but-equal log. An eventlog of one's own, so to speak.

By and large the eventlog documentation from Microsoft is pretty good with one small exception that's cost me about 90 minutes to figure out: the EventSource and EventLog parameters need to be the same string, at least with the 64-bit implementation of .NET Framework 2.0.

The problem arose when installing the service on the client's server. The install code performed the customary check of the EventLog service to see if the event source information was already registered and, if not, registered it:

string SSource = "Exchange Provisioning Service";
string SLog = "ExchProvLog";
EventSourceCreationData esc1 = new EventSourceCreationData("Exchange Provisioning Service", "ExchProvLog");
if (!EventLog.SourceExists(sSource))
EventLog.CreateEventSource(esc1);

But subsequent calls to the event log would throw an error message:

EventLog.Write("Exchange Provisioning Service", "Service VWoolf1 started successfully", EventLogEntryType.SuccessAudit,234);

resulted in:

"The local computer may not have the necessary registry information or DLL files to display messages from a remote computer"

After the 90 minutes spent Googling the best link was a Dr. Dobb's Journal article from 2004 which provided the background to solving the problem (http://www.ddj.com/windows/184405714). The article doesn't address this particular problem but it showed where to start.

When registering an EventSource with the EventLog service the service creates a key under HKLM\SYSTEM\CurrentControlSet\Services\EventLog for the new EventLog. Under this entry is an entry for the new Event Source. This is evidently where the action is -- in this registry key is an "EventMessageLog" pointer which points to the DLL with the library of error messages which the log uses for this type of event source.

If the Event Source and Event Log are different, unfortunately, it puts in two entries under HKLM\SYSTEM\CurrentControlSet\Services\EventLog\: one with the new Event Source, the other with the new Event Log. This it doesn't like, and it throws that message above.

I guess you could just use the registry editor to snip out the one of these two SourceName entries you don't like but, since I was writing this for a user install, I didn't want to screw with that and felt that using a one-name-for-both entities solution is good enough for now. It works, and that has a lot going for it.

One additional note:

When you're writing the de-install part of this user install package, when you want to completely remove your program and the custom event log you created from the user's machine, I've found that just deleting the event log:

EventLog.Delete(Logname);

is sufficient. Don't screw with removing the event source and then the event log, it just seems to cloud the issue and throw exceptions.

//EventLog.DeleteEventSource(EventSource); // don't bother with this
EventLog.Delete(Logname);