The March of Progress, .NET-Style

A fairly common programming task is the need to convert from an array of integers to a comma-separated string.  For instance, this often comes up when you have an array containing some IDs, and you want to use the IDs in a SQL query (such as "select * from some_table where id in (1, 2, 3)").  In the old .NET 2.0, this usually involved a "For" loop:

    Dim intArray() As Integer = New Integer() {1, 2, 3}
    Dim s As String = ""
    For Each id As Integer in intArray
        s &= id.ToString() & ","
    Next
    s = s.Substring(0, s.Length - 1)

Then came .NET 3.5 and LINQ, and the code got a bit more concise:

    Dim idStrs As IEnumerable(Of String) = _
        From id In intArray Select idStr = id.ToString()
    Dim s As String = String.Join(",", idStrs.ToArray())

Finally .NET 4.0 came along with a helpful new form of the String.Join method, and reduced this task to a one-liner:

   Dim s As String = String.Join(",", intArray)

Someone up there is listening.

Return of the Framework Bug

So the .NET Framework problem that I wrote about last week reappeared this week, coming back around like a bad penny.  The same two users whose .NET apps stopped working last week had the same problem again today, while everyone else was fine.  Apparently, some of the .NET Framework files had disappeared from their machines.  However, after some poking around on the Internet, I turned up a new piece of evidence - a known bug that can result in Framework files being deleted.  Apparently, if a .NET patch is installed while .NET assemblies are in use, then not only can the install fail, but some of the assembly files can be deleted for good measure.  Even if the user is especially conscientious and closes all apps before installing the update, there could still be services running that use the assemblies.  To be safe, one must use the Process Explorer to find and kill any processes that have an open handle to the assemblies before installing the update.

Luckily, I also realized why the problem kept coming back on the same users' machines.  If you just remove and reinstall the .NET Framework 3.5 SP1, it won't contain all the latest patches, so the next time the user runs Windows Update, the updater will helpfully try to install those patches - which will likely start the whole cycle of pain all over again.  So this time I made sure to install all the latest .NET patches as well.  At least they should be good until the next time a new .NET patch is released, and hopefully by that time the installer bug will be resolved as well.

Programming Quotes

Have a favorite quote about programming?  Lots of good ones here.

The Jamie Zawinski quote is funny - though judging from some of the code on his website, he's no slouch at regular expressions himself.

.NET Framework Won't Install - Who's Locking My File?

At the company where I work, we develop in-house applications mainly for the .NET platform.  In addition to the many good things about the .NET platform, there is also the occasional annoyance of having to fix a problem with the .NET framework on a user's machine.  Usually it all works pretty seamlessly, but occasionally something goes wrong.  Sometimes this happens right after a Windows Update is pushed out - other times, there is no apparent cause.  In any case, the problem typically presents itself to the user as though all of our in-house applications are broken.  Since all of the other applications that the users typically use (such as Outlook, Excel, etc.) still work just fine, they tend to look to us, the developers, to fix the problem.  Although Desktop Support is nominally responsible for things like the .NET framework, as a matter of practice, it behooves us developers to do something about it.

Such was the situation that presented itself to me today.  Usually the fix is fairly straightforward - remove the offending framework version and re-install it.  Today, however, there was an added wrinkle, which was that the Framework installer was failing with an "Access denied" error.  The user had Administrator privileges, so there shouldn't have been a problem there.  Rebooting (needless to say, one of the first things to be tried for any software-related problem) also didn't work in this case.  The Installer still wouldn't run.  Eventually, after casting around the Internet for a possible solution, I had the good fortune to come across a helpful blog post by Aaron Stebner.  Stebner's blog is full of genuinely helpful information for resolving a myriad of .NET-related headaches - suffice it to say that he is a god among men.  This time was no different, and after following his advice and using msconfig to disable some inessential startup services, the installer ran like a dream.  So it appears that a service was holding a lock on a particular file that the installer needed to write to.  Why this was still happening even after all versions of the .NET framework had supposedly been removed from the machine is a mystery for another day.

So, with the user's problem resolved, I returned to my desk to perform other lower priority tasks, such as actually writing software.  However, I soon got to thinking, wouldn't it be nice if there was a way to see exactly which process was holding a lock on the particular file that was giving the "Access Denied" error?  It might have helped to speed up the troubleshooting, and in any case, it would have been an interesting thing to know.  So after (a bit more) searching on the Internet, it turns out that there is just such a tool, and it is provided for free, by Microsoft no less.  The tool is called the Process Explorer, and you can download it here.  Let me tell you, this is a pretty slick little app.  I played around with it a bit, and I was suitably impressed by the ability to drill-down on all the processes running on my machine.  You can even search by a particular file name to see exactly which processes are locking it.  There's a lot more it can do too, but alas, I had to get back to my coding.

Monetizing Google's Data

I don't work at Google, but if I did, I'm sure there are lots of great applications I could build if I had access to their data.  One area where the possible uses of Google's data has been relatively underappreciated is the realm of finance.  Today we learned that Google has started calculating its own inflation index by tracking the prices of products advertised online.  Although they haven't decided whether or not to publish this index yet, there are other potentially interesting sources of economic information available to Google that it could use for its own advantage or sell for the right price.  For instance, rather than simply tracking the prices of products online, couldn't Google easily measure consumer interest in different products, based on searches for product keywords or clicks on shopping-related links?  And wouldn't that information be interesting to a stock analyst following the manufacturer's stock?  Presumably this data could be updated in real-time, providing a nice jump on the release of sales data for new products - or even providing a way to measure interest in forthcoming releases.  So maybe Google should start its own hedge fund to trade based on these signals.  I suppose that the thought of Google running a hedge fund might conflict with their motto of "Don't Be Evil", or at least it wouldn't help their image.  There would be something unseemly about Google profiting so openly from the data it collects.  But I don't see how it could be unlawful, since there's no insider trading involved.