Are auto-updating applications really that useful?

Being incessantly nagged gently reminded by over a dozen applications (and some of their plug-ins) in the past week that there’s updates available, I really have to question whether all these auto-updating (or even just auto-checking for updates) applications are actually worth the hassle.  Sure, when you’re developing an application you’re thinking “My users are never going to bother checking for bug fixes on their own, we’ll have the application call home and check for updates itself.”  That’s all well and good until you realize that you are not the only one in the world developing an application and you’re not the only developer with that thought.  When a single application notifies you that it can be updated, that’s no big deal.  When you have a dozen of them over the course of a week that need to be updated, that becomes a major pain.  Especially for those users that still have UAC turned on.  Granted I seem to be in the very obscure minority of users who keep UAC on, it’s still an unnecessary step to require admin rights, even when the installer itself is never writing to a protected file/folder/registry setting/etc. that really should never require admin rights.

I think the biggest issue with installers seem to be that those that install the application in the Add/Remove Programs Programs and Features are actually creating a registry value in HKEY_LOCAL_MACHINE.  If only a purely user-based installer existed.  Or better yet, Programs and Features listed user-based installs as well as machine-based installs.  I think ClickOnce can support user-based installs, but not everybody wants to use ClickOnce.  Not even in the .NET environment where it’s part of the toolset.  Most teams seem to turn to easily scriptable options like NSIS or WiX.  In all honesty I haven’t looked at ClickOnce since it first came out with .NET 2.0/VS2005.  I could only find one situation where it actually fit my needs, but outside of that I constantly hit limitations and pain points with it.  Perhaps those have been fixed by now, but I haven’t had a need to write an installer in recent projects.  Outside of the .NET world (especially in open source applications that build installers), NSIS seems to be pretty common.  Ed. Note: usage of tools is purely subjective conjecture based on looking over code bases, noticing the standard UI rendered by the tools, and some the fingerprinting the tools leave out the installer artifacts.  I may be missing other common installer creators (InstallShield is out there, but is quite expensive) or grouping them together incorrectly.  A problem with this is that different installer types are created.  MSI’s are recognized as installers and thus require admin rights in order to run them.  NSIS outputs executable installers.  Depending at the flags in the script, the admin rights prompt may not occur until it first tries to write to a protected area.  I’ve also seen this hang up the installer or cause it to outright cancel the install.  Talk about a bad user experience.

I’m not really sure what point I’m looking to make with this post, but it’s a rant I wanted to get off my mind.

Updating the Last Modified Date of a directory

Working with a lot of compressed (.ZIP) folders can have some interesting side effects when you decompress them.  Windows will list all the folders (and subfolders) as having a last modified date of when you decompressed the file.  That may be well and good for most people, but it annoyed me to no end because I typically sort directories by the Last Modified Date as I work with the most recent files the most often.  Plus, downloading a file that hasn't been updated in a couple years and unzipping it can cause some confusion when you see the folder as being last modified today, but every file in it was created/modified a few years ago.  Why not have the folder actually reflect the date it was last modified by the files, not the OS?  That makes better sense to me, so I created a dead simple console app to do just that.

The console application will recursively go down a directory structure and give you a status of the folders and the Last Modified Date's new value.  By default, it will go down a maximum of 300 folders.  That should more than cover most directory trees.  If you want to limit it to only a couple levels, you can call the application from the command line, passing in a number after the folder and it will recourse only that many levels.

One thing you'll notice in the output (more so if you run it in a console window rather than from the context menu that's part of the installer) is that the path names are rarely wider than the screen.  There's a few different ways to accomplish this task, and since I'm not a fan of depending on system libraries in managed code, I took the approach of implementing the function myself based on code I found online.  I can't recall where I originally came across it, but I modified a couple logic errors that were in it.  Take a look at the DirectoryUpdater.CompactFilePath() method if you're interested.

I also built a Windows Installer Xml (WiX) installer because it's so much easier to just right-click on a folder and tell it to update the last modified date.  So as a custom action in the installer it creates the appropriate registry keys for the context action.  As I'm still extremely new to WiX, the only way to have it install them is to choose a Custom install and change the "Context Menu" item to "Will be installed on local hard drive".  Hopefully will get that figured out at some point.

Source code download from here.
Executable download from here.
MSI Installer download from here.

Permanently Get Rid of "Unblock" Button on Downloaded Files

I'm really surprised at myself for waiting so long before I removed this friction point from my daily environment.  Like almost all developers, we look for the path of least resistance when we're trying to get work done.  And I'm going to be generous and say that we're all smart enough to know that we take some level of risk with downloading and executing files from the Internet.  So why should we be bothered by Windows telling us that a file we just downloaded (especially intentionally just downloaded) may be unsafe and tries to protect us?  I don't care, I want to execute it without all the extra safety precautions.  I don't want to have to go into every file I download and click on the "Unblock" button so it will function as expected.  I've read some posts that this is unique to Internet Explorer only, but that's not so.  My browser of choice is Firefox (haven't had the desire to switch to Chrome yet) and it does the same thing.  This is especially true when downloading CHM help files as nothing loads because the content is blocked.  Even more so when you unzip a file that is still "blocked" and all the expanded files are now also "blocked."  You end up with a bunch of file properties that look similar to this with that not so attractive "Unblock" button at the bottom:

So how can you permanently get rid of it? Well Windows is applying an NTFS stream to the file that keeps what zone the file is originally from.  The easiest way is to edit your Group Policy settings (normally handled by your domain settings if you're in a corporate network, but also exists on a personal machine).  Since this isn't normally something configured for home use, I'm not entirely sure which versions of Vista it can be found in.  The disclaimer on the setting says at least XP Professional SP2.  Anyway, you will need to run %windir%\System32\gpedit.msc as an administrator.  Next, navigate to Local Computer Policy -> User Configuration -> Administrative Templates -> Windows Components -> Attachment Manager.  The setting "Do not preserve zone information in file attachments" is most likely at a status of "Not configured".  You will want to go into the properties of it and change it to Enabled.  No restarts necessary to apply it.

From that point on, any file you download will no longer have to be "Unblocked."