Repent! The End is Near!
It has been announced that Virtual Server 2005 will no longer be supported after 2014. Plan now to migrate your virtual images, before it's too late.
You know your company's getting big when it announces that an already outmoded product will see its sunset seven years from now.
All of the good stuff in one package. This is a great idea for a newly-paved machine.
This has been an annoyance for a long time. When you open a file with an "unknown" extension, you get the dialog asking you if you want to search the Interweb to find an appropriate program. Like the author of this post, I have never, ever found anything through this. I automatically choose "Select the program from a list".
Now you can perform some registry hackery to bypass this dialog and always go to the "Select from a list" step.
A while back, I saw a 60 Minutes interview with Nicholas Negroponti about the One Laptop Per Child Project, and it was very interesting. These things really are useful in an African village. Kids, as kids do, were taking to them like ducks on a pond. It's a cool box, too.
Now we have a chance to both satisfy our lust for curiosity about the technology and help a child. Come November 12th, there is a two week program where you can buy one of these babies and have one donated. Sign up here to be notified when it officially starts.
Rob Walling has blogged about it.
Ken Brubaker points to a summary by Clemens Vasters of a white paper comparing various existing distributed communication technologies with WCF. The bottom line - WCF is
Also in his summary, Clemens remarks (italics his):
For WSE 2.0/3.0 implementations, migrating them to WCF will obviously provide the most significant performance gains of almost 4x.
The performance differences alone make WCF a technology worth exploring.
Jeff Levinson provides a brief overview of how you could set up and do change management for development using TFS. The approach is a bit different than I've seen in the past.
Here's a nice CodeProject article on both using TortiseSVN (the primo Subversion client) and integrating it with Visual Studio. It discusses Ankh, VisualSVN, and an add-in developed by Garry Bodsworth (described here). There are some useful tips on Subversion in general, and some of the comments have interesting questions and answers as well.
I'm going to dip my foot into WCF. That's more than a toe but less than a headlong dive. Of the four books listed in our library, I have found two. Here are some quotes from the intros:
...you might instinctively treat WCF as just another API. Resist this temptation... WCF is not just a wrapper around existing functionality or just another whiz-bang API. WCF is the evidence that a tectonic shift has occurred in distributed software development.
Justin Smith, Inside Windows Communication Foundation
Tectonic shift!? Wow! Equally as eye-opening is this one:
To me, WCF is simply the next development platform, which to a large extent subsumes raw .NET programming.
Juval Lowy, Programming WCF Services
This could be fun...
I've been noodling around with F# for a while, partly to get used to the upcoming Functional Programming 
features of C# 3.0, partly to expand the way I approach programming problems. Now, Somasegar has announced that Microsoft will be making F# a first class language, along with C#, VB.NET, etc. This is very good news, not only for devotees of ML-type languages, but also for FP in general. When something is readily available in Visual Studio, there's more of a likelihood that someone will give it a try*.
And while it's true that other ML implementations for .NET have been around for a while, such as Nemerle, SML, CAML, OCaml and Haskell, the polish that Microsoft will put on F# will make it much easier to use.
Also, unlike some of the above examples, F# is under active development by Microsoft Research in the UK. Don Syme is the leader of the team. F# can be either compiled or scripted like Python, but it has ML's type inference and is type-safe. It generally performs as well as (or better than!) compiled C# code. For an intro and overview of features, check out the project's main page.
* Except for J#. Don't ever try J#.
Let's say you have a .BAT file with a command like
c:\bin\dcc32.exe [parms to compile a Delphi program]
It will return an %errorlevel% of greater than zero if the program does not compile, zero if it does.
Since I was testing this by double-clicking, I put a PAUSE statement right after it to see the output of the compile step.
c:\bin\dcc32.exe [parms to compile a Delphi program]
pause
Once the whole build project started working, I left the PAUSE in but REM'ed it out so I could remember what I had done in case I needed to go back and debug later.
c:\bin\dcc32.exe [parms to compile a Delphi program]
rem pause
It turns out that REM is an "active" statement in a .BAT file and sets %errorlevel% to zero! When the compile line really did fail, the error was being masked by the REM right after it, so the MSBuild project kept going as if nothing was wrong. Once the REM line was removed, the MSBuild project failed as it should.
Got somebody who's hard to buy for? Here's something that's appropriate for either a nerd or a geek.
There's a nice description of version control branching and merging on Jeff Atwood's blog. He points out some patterns and anti-patterns taken from a Microsoft article. We are facing some complex issues with branches and customer-specific features right now at work. I don't know the best answer (yet), but these two articles give a good framework for discussing the technical as well as organizational ramifications.
If your code is running in a Sql Server context (sproc, trigger, CLR assembly, etc.) and you wish to know who initiated the execution, you can try the T-SQL command SELECT SYSTEM_USER. This will give you one of three answers:
Number three is interesting, because it masks the "real" user identifier behind a persona. To change your context, issue the command
EXECUTE AS USER = 'Gsl\SierraServer'
Then no matter who you are or how you logged in to the server, SELECT SYSTEM_USER will return "Gsl\SierraServer". The BOL even calls it the "impersonated" context.
Not that customers would ever fiddle with sprocs or table schema or permissions that you carefully craft and install...
In creating a new build, I found I needed a way to set an environment variable within the MSBuild script for subsequent use by a .BAT file. On CodePlex, I found a project called SDC Tasks Library that filled the bill and then some. From the site:
This is the latest version of the SDC Tasks for .NET 2.0. The SDC Tasks are a collection of MSBuild tasks designed to make your life easier. You can use these tasks in your own MSBuild projects. You can use them stand alone and, if all else fails, you can use them as sample code.
There are over 300 tasks included in this library including tasks for: creating websites, creating application pools, creating ActiveDirectory users, running FxCop, configuring virtual servers, creating zip files, configuring COM+, creating folder shares, installing into the GAC, configuring SQL Server, configuring BizTalk 2004 and BizTalk 2006 etc.
This used to be on GotDotNet (RIP) but is alive and well now on CodePlex. To use this in your MSBuild script, put something like this at the top of the script:
<UsingTask AssemblyFile="Microsoft.Sdc.Tasks.dll" TaskName = "Microsoft.Sdc.Tasks.SetEnvironmentVariable" />
When you need to use it...
<SetEnvironmentVariable Variable="MyEnvVar" Value = "$(BuildPathVar)\Bin" Target="Process"/>
The help file that comes with the .DLL is only a reference and seems to have no examples, but for some tasks, the usage is pretty clear. As always Google is your friend for real-life examples.
DotSVN is an Open Source .NET library that allows you to programmatically access a Subversion library. While this is an interesting idea, what I found even more interesting was the article's graph showing the growth in usage of Subversion over the last 3.5 years. The rate of adoption is dramatic, and this is just for public Apache servers!
Call GC.Collect() is generally considered unnecessary and can actually disrupt the smooth functioning of the .NET garbage collector. Dennis Dietrich gives a scenario where it is reasonable to call the garbage collector in your code. His example outlines a situation where you want to test that all references to an object have been deleted at some point in the program so that the object can be garbage collected. The catch-22 is if you maintain a reference to the object to see if it still exists, it cannot be collected.
Enter WeakReference. This class allows you to maintain a reference to an object while letting it be collected if need be. In the time between the object's destruction and its pickup by GC, a WeakReference allows you to continue to use the object. Now continuing to use an object that's in limbo may seem like a bad idea, as the garbage man could drive by anytime. But here's an interesting scenario where you may wish to keep a WeakReference so that you could have the possibility of turning it back into a strong reference (and thus keep the object from being collected).
In our testing case, we wish to do the opposite, make sure we cannot continue to reference the object. After GC.Collect() is called, we check the IsAlive property of our WeakReference.
On a side note, it's interesting that something so fragile implements ISerializable.
In the process of looking up some cheat sheets, I found this site. The SQL 2005 was what led me there, but this caught my eye, since a lot of guys at work use the command line. There are things in here I had never heard of, much less used.
For example: CSVDE Import or Export Active Directory data. Wow. I've used TRACERT quite a bit, but now there's also PATHPING. If you are cmd junkie, check it out.
I recently started a new position where they use VS2005 and Test-Driven Development, which is something new to me. At home I've been using VS2008 beta2, and it has been very solid. So, I installed it side-by-side on my company laptop. All of a sudden, one of the unit tests I was working with failed. After a bit of digging, it turned out that it was related to the order of List<T>.Sort().
This particular unit test was for a custom IComparer that cared only about certain high-priority filename extensions. The rest of the extensions were left essentially unsorted, and the filename portions were ignored. The thing was, the unit test was expecting all of the items sorted to be in a particular order. When I put some debugging in, I found that order of two of the four "non-high-priority" extensions were swapped when I ran the test.
After some angst and some mild reproaches from my boss ("We usually use VPCs for installing beta software..."), I decided the best course of action was to repave the machine. Later on, buried in a post about how garbage collection is changed in 3.5, I found a reference to "SP1 for the 2.0 framework"!
It kind of makes sense that something would need to be done to allow the new multi-targeting feature, but I had always thought everything was going to be pretty much the same in the 2.0 framework. Turns out that's not exactly the case. I didn't come to any conclusive evidence in short time I spent Reflectoring, but it's clear that something's different, since the size and date of mscorlib is different in 2.0 after 3.5 is installed.
In any event, I pointed out that the framework documentation for 2.0 (and all subsequent versions) says that a Quicksort algorithm is used, which does not guarantee that equals will remain in their original order. I finally got a concession that perhaps the tests could be revised. In doing so, I found out that the version control history showed that someone else had found the same problem and had simply changed the expected sort order to match what came up on that test machine!
As my first taste of Test-Driven Development, this was a bit sour. Shouldn't we be thinking about what needs to be tested instead of just writing any old thing? In this case, it was testing that items inserted into the List<T> after an initial sort would also be sorted when you once again issued List<T>.Sort(). WTF?!? If List<T>.Sort is broken and it's up to my puny unit test to find it, let's all just pack up and go home.
If a test produces a "false failure", shouldn't we see if something needs to be revised instead of changing the test to match the new result?? If it's too much trouble to make sure the tests test what should be tested and have them run correctly, why do we do TDD?
