So I took the weekend and coded a little library, which I call “WmAutoUpdate” (freely available on Github). It can easily be integrated with your .NET Compact Framework app and works with any webserver that is able to serve files on the server side.

Go on over to Github, get the source and check the “example” folder:

Usage
============
Consider the example folder for a simple example of how to use the framework. The application simply consists of a form, which displays the string “old Version”.

  static void Main()

    {

      Updater updater = new Updater("http://www.myupdateurl.com/update.xml");

      updater.CheckForNewVersion();

      Application.Run(new Form1());

    }

Upon start, the WmAutoUpdate framework kicks in and downloads the XML file “update.xml” from the update server. The update.xml file looks as follows:

  <?xml version="1.0" encoding="utf-8" ?>

  <updates>

    <download name="WmAutoUpdateExample">

      <version maj="3" min="0" bld="0000"/>

      <message>Important Update. My very important release/update note. This will be displayed within the Update

      Form</message>

      <link>http://www.myupdateurl.com/update.zip</link>

    </download>

  </updates>

Pretty self-explanatory. Afterwards, the user can choose whether to update now, or skip the update for now. If the former is chosen, the file described in the “link” tag is downloaded and unpacked into a temporary folder (Unpacking is facilitated through the http://www.codeplex.com/DotNetZip lib). Next, these files are moved from the temporary folder into the application folder, replacing the outdated files (the outdated files are copied into a backup folder, beforehand). If everything goes well, WmAutoUpdate creates a file called “success” within the backup folder. Lastly, the application is restarted (right now this is implemented via a call to CeRunAppAtTime; Unfortunately, the minimum time-frame this function accepts is 11 seconds. Thus, it will take 11 secs for your app to restart). Upon restart WmAutoUpdate checks for the “success” file within the backup folder. If found, the entire backup folder is deleted. If not, all files within the backup folder are copied back into the application folder (rollback).

Both update.zip (which simply contains the same application, but with a form saying “new Version” and the Assembly Version set to 3.0.0) and update.xml can be found in the “Server Files” directory within the example folder. Both files need to be put into the according server web directory.

If you, like me, enjoy listening to a good audiobook while dozing off to dreamland, but don’t want to leave your computer running throughout the entire night…

NightTunes is for you!

No more harddisk clatter noise or blowing CPU fans disturbing your sleep …plus you’re reducing your your energy bill and your carbon footprint

Unlike other shutdown solutions, NightTunes does not depend on user-set timers to determine when to shutdown your PC. That way it is guaranteed that your computer won’t bail out on you right in the middle of your goodnight tale, only because you forgot to set the timer right.

Check out http://www.earlybirdapplications.com for details.

http://earlybirdapplications.com

Come in, take a cookie and browse through the, yet, sparse exclusive product list!

I just released the source code of iTunesSnarl. It is available via Google Code. So if anyone out there could please fix the cover issues, I’d be more than happy

Check it out here: http://code.google.com/p/itunessnarl/

Version 1.1, released 2008/09/04

• The current song’s title is now displayed in the title of the snarl window.
• The snarl window now also lists the artist’s album title (most of the time….don’t know why it bails out sometimes).
• Removed Snarl_CMD.exe and any dependencies to it.
• Plugin now registers with Snarl and popups can be disabled via Snarl.

I wish I could tell you that now the album cover is also displayed in the Snarl window, but as I said above, that proofs to be a little more difficult than expected. Any help is appreciated!

The installer can be downloaded here.

———————————————————————————–

Update: Go here for version 1.1

———————————————————————————–

Over the last weeks I’ve become a huge fan of Snarl, which is a Growl-like notfication system for Windows. With the appropriate plugin, applications like Firefox or Miranda can display user messages through Snarl, which only opens small “bubble” message boxes that close itself after a certain period of time. This way the desktop isn’t cluttered with message windows that the user has to close by hand.

So far, the number of extensions/plugins that are available for Snarl is still small, but with the software below I’m doing my part to increase it

Since the only plugin for iTunes, iTuny, is more of a Launchy plugin than a Snarl plugin, and since I couldn’t get its Snarl component to work (maybe I didn’t try hard enough), I decided to give the iTunes SDK a try and developed my own plugin. You can download the installer below. When running the setup, the plugin will install itself to $Program Files$\iTunes\Plugins\iTunesSnarl\ from where iTunes will load it automatically whenever you launch it. So no need to start the plugin seperately (of course Snarl needs to be running). Just fire up iTunes and that’s it. From now on you will get a small bubble message showing you the current artist and track title whenever you skip from one track to another.

Download it here

P.S.: I borrowed the Snarl_CMD.exe from the iTuny sources. f0vela, I hope you don’t mind!

After playing around with the code for a while, I got some weird exceptions thrown at me, e.g. “A first chance exception of type ‘System.Runtime.InteropServices.COMException’ occurred in PresentationCore.dll“. Now, the only thing I had changed was letting the tagging routine run in a seperate thread:

[STAThread]
static void Main()
{
Thread t = new Thread(writeMetadata);
t.Start();
Application.Run(new Form1());
}
static void writeMetadata()
{
// write the metadata to the image here
}


After searching the web for a while I found an article by Aaron who had run into similar problems. Apparently, WPF components cause some trouble when they’re executed outside a thread that doesn’t have its apartment state set to STA. Fortunately, Robert was kind enough to point me in the right direction. All you have to do is set the apartment state right and off you go with WPF components all over your threads Thus, the Main() routine from above changes as follows:

[STAThread]
static void Main()
{
Thread t = new Thread(writeMetadata);
t.SetApartmentState(ApartmentState.STA);
t.Start();
Application.Run(new Form1());
}

That’s all there is to it!

After searching for a solution for days, I stumbled upon AppUpdater, which is a free .NET component that “was written using the .NET Framework and enables you to make your application auto-updatable simply by dropping the component into your existing .NET applications and setting a few properties (ex. where to get updates from)“. And indeed, it’s as easy as it sounds. Drag-and-drop the component on your application’s main form, configure the AppStart.config file and start your application by using the provided AppStart.exe. Then put an updated version into the according folder on your server and the AppUpdater component will take care of the rest. (if you cannot follow, read the AppUpdater article first

Although step 5 of the walkthrough says that any Web-DAV enabled web server should suffice, I ran into trouble using an apache web server with the dav and dav-fs modules loaded. Apparently, you need an IIS, since it interprets DAV verbs a little different than its apache counterpart. While both the CheckForFileUpdate() and the UpdateFile() functions from the AppUpdater’s class “WebFileLoader.cs” work as expected, the client throws an exception in GetDirectoryContents(). It seems that the apache dav module has some problems with the iscollection and displayname tags of the request string since it returns the following response (e.g. for the file appupdater.dll):


<D:response xmlns:lp1=\"DAV:\" xmlns:lp2=\"http://apache.org/dav/props/\" xmlns:g0=\"DAV:\">
<D:href>/update/1.0.0.1/appupdater.dll</D:href>
<D:propstat>
<D:prop><lp1:getlastmodified>Sat, 12 Apr 2008 00:30:16 GMT</lp1:getlastmodified></D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
<D:propstat>
<D:prop>
<g0:displayname />
<g0:iscollection />
</D:prop>
<D:status>HTTP/1.1 404 Not Found</D:status>
</D:propstat>
</D:response>

getlastmodified returns the right timestamp, but both displayname and iscollection return a “404 Not Found” error. Now, I could’ve gotten into the DAV protocol, put my web server into debugging mode, TCP-dumped a couple of DAV requests and tried to build a proper request string, but then again there is actually no need to employ DAV for simple tasks like this. The simple HTTP protocol totally suffices in this situation. You just need to go a slightly different way:-) As initially implemented, the AppUpdater connects to the web server in the GetDirectoryContents() function and browses the directory to find and copy all the contained files to the client. “Directory Browsing” is a DAV feature, so we’ll have to improvise here.

Let’s say I just released version 2.0.0.0 of my application (Former version was e.g. 1.0.0.0). According to step 5 of the article, I simply need to create a new folder named “2.0.0.0″ in my server’s root update directory and edit the UpdateVersion.xml file to point to this newly created dir. Instead of uploading all files from our release folder, we’ll zip them up and upload the resulting zip-file into the server’s “2.0.0.0″ folder. That way our client only needs to download one file (via HTTP) and isn’t dependent upon the “Directory Browsing” feature. After downloading the zip-file we’ll just unpack it into the temp directory that the regular AppUpdater would have stored the downloaded files in and let it do its magic from there on. It’s as simple as that, plus you only need to zip up and upload those files, which have changed between releases. The AppUpdater will copy all files, which it finds in the 1.0.0.0 but cannot find in the 2.0.0.0 folder to the latter folder. Unfortunately, this little hack doesn’t allow for auto-downloading of missing assemblies anymore (setting the AutoFileLoad option of the AppUpdater component to true), but then again users can just download the installer and re-install the app, if they accidently deleted any of the files in the app’s root folder.

Now to get going and to enable the AppUpdater to work with your apache web server (without Web-DAV) you actually only need to modify one file. First download the the .NET Application Updater Component package, which includes the AppUpdater’s source code. Afterwards edit the file “WebFileLoader.cs”. Since the GetDirectoryContents() function caused us so many headaches and we won’t need it anymore you can delete it entirely. Afterwards, replace the code of the function CopyDirectory with the following (most of which is copied from the UpdateFile function):


Resource currentResource;
int FileCount = 0;
string newFilePath;
if (!Directory.Exists(filePath))
Directory.CreateDirectory(filePath);
HttpWebResponse Response;
HttpWebRequest Request = (HttpWebRequest)HttpWebRequest.Create(url);
Request.Credentials = CredentialCache.DefaultCredentials;
try
{
Response = (HttpWebResponse)Request.GetResponse();
}
catch (WebException e)
{
if (e.Response == null)
{
Debug.WriteLine("Error accessing Url " + url);
throw;
}
HttpWebResponse errorResponse = (HttpWebResponse)e.Response;
if (errorResponse.StatusCode == HttpStatusCode.NotModified)
{
e.Response.Close();
return 0;
}
else
{
e.Response.Close();
Debug.WriteLine("Error accessing Url " + url);
throw;
}
}
Stream respStream = null;
string newPath = "";
try
{
respStream = Response.GetResponseStream();
newPath = filePath + Path.GetFileName((new Uri(url)).LocalPath);
CopyStreamToDisk(respStream, newPath);
DateTime d = System.Convert.ToDateTime(Response.GetResponseHeader("Last-Modified"));
File.SetLastWriteTime(newPath, d);
}
catch (Exception)
{
Debug.WriteLine("APPMANAGER: Error writing to: " + filePath);
throw;
}
finally
{
if (respStream != null)
respStream.Close();
if (Response != null)
Response.Close();
}
// unzip files
Shell32.ShellClass sc = new Shell32.ShellClass();
Shell32.Folder srcFlder = sc.NameSpace(newPath);
Shell32.Folder destFlder = sc.NameSpace(filePath);
Shell32.FolderItems items = srcFlder.Items();
destFlder.CopyHere(items, 20);
File.Delete(newPath);
return 1;

(Sorry for the messy code. I couldn’t get Wordpress to indent it properly:-( In the last 7 lines we employ the Shell32 COM library to extract our zip file. To make this work, you need to add the correct reference. In your project, click on “Add Reference”, then on the “COM” tab in the opening dialog and then search for “Microsoft Shell Controls And Automation”. That’s the lib you want to add. Finally compile it and add the resulting .dlls to your project, although I would generally recommend adding the entire AppUpdater project to your solution and referencing it.

Before we can test our new application, we need to create a new directory on our server (let’s assume the example from above and name it 2.0.0.0). Then go through the article’s steps 1-4 and do everything as told, build your application, zip up the new files (to e.g. app.zip) and upload the zip file to the 2.0.0.0 directory on the server. Afterwards, edit the UpdateVersion.xml file as follows:

<VersionConfig>
<AvailableVersion>2.0.0.0</AvailableVersion>
<ApplicationUrl>http://your.web.server/your_update_dir/2.0.0.0/app.zip</ApplicationUrl>
</VersionConfig>

It’s very important to mention here that with the modifications you made, you now need to give the FULL PATH to your zip file within the ApplicationUrl tags, not just the directory as before.

Last but not least, fire up your client and let it automatically update itself!

That’s it! Hope it works for you.