In the last few days a did some smaller experiments for a new project idea that is spooking around in my head. One of those was to try and get Nancy up and running with Kayak in a simple console application.
This post from Louis DeJardin provided a good place to start. Most of the post ist still current but there are some changes you have to make to get this up and running. I have no “official” information but I had to change the provided code in the KayakStarter class from this (taken from Louis post):
to this:
Did you spot the difference? The only change is the third parameter of the call to the Gate.Hosts.Kayak.KayakGate.Start method. This makes the non-working example files from the NuGet package working again, but it also seems like the Startup class is not used anymore.
Maybe someone with more experience in Kayak/OWIN can shed some light on this?
This post is the first of a collection of brainstorming articles I’ll write in the near future. These are primarily meant to note down my thoughts on specific projects and/or feature implementations etc.
Currently a lot of ideas whirl around in my head (which have nothing to do with my potential future project, of course ;-). One of those is an automatic update feature for windows client applications.
The idea is that there are two main components:
An update server which is a web service of some kind. This server would include some tooling to allow for easier package creation (more on that later).
A client library which you can use to enable automatic updates. This may include dialogs for user notification.
The client
The application using the client would include a public key. The packages provided by the update server would be simple zip archives containing an xml file with relevant data (name of the application, version etc.) and the updated component (either an msi file or a dll for simple plugins). The xml file also contains a SHA1 hash of the updated component and will be signed with the private key corresponding to the public key stored in the application.
On startup or whenever the client application would check the update server for updates like this:
The client can also send additional data (like license keys etc.) as an optional parameter in the GetVersionInfo method which may then be processed by the update server. This would change the webervice call above to something like this:
If the user chooses to download the update, the client application will download the whole zip file, extract it and first verify the signature of the xml file against the embedded public key and then the SHA1 hash against the downloaded update to verify its integrity. This should avoid most of the security risks as long as the update server is called via https and has a valid certificate.
The developer of the application will be able to choose whether a valid ssl certificate will be enforced on the client or not.
The server
As mentioned above the server stores update packages and provides a webservice to retrieve the current available version of an application and the update itself.
The server should store those updates in a single directory (maybe one subfolder for each application or updatable component). In the first step the server would only support the creation of the update package via a command line tool (e.g. a Powershell script):
This will ask the user for the passphrase for the private key and generate the xml file with the hash and signature automatically. It will also copy the output (both the update component and the xml file) to the directory provided in the –out parameter.
The zip file for download will be created and cached on demand by the server. Later on a push of updates via the webservice itself may be implemented.
When the client asks for the version info the server will return the values from the xml in the applicable application subfolder. This means the client is responsible for checking if the provided version is newer or not.
Handling of additional data provided by the GetVersionInfo call can be easily added to the service by adding a custom version handler to an internal dictionary:
This is what I have in mind so far, I guess there will be a follow up post to this when more thoughts come up ;-)
After working about 6 years on a project for one of our customers the time for me to move on has finally come.
My employer stays the same but I’ll switch to a new project and it really may be a new project in the sense of that theres is not a single line of code written at the moment.
We are currently in the state of creating a quote for this new project and there it hit me again: Waterfall … or at least something like it.
But first, a little bit of background: For the last 6 years I worked in an environment that required us to be agile (even if we did not know the right name for it at that time). For the whole of my professional live up until this day I’m used to changing requirements and short deadlines.
But now it looks like in the next project this will change. Not. To be honest, I can not believe in a project where requirements will not change as soon as the customer actually gets to see the product. But I also know that the 1.5 projects I’ve done so far are not nearly enough to be used as a base for such a strong opinion.
After working about 6 years on a project for one of our customers the time for me to move on has finally come.