Horn Evolution

I have some exciting news that will really help take horn forward to the next step of its evolution.

The current incarnation of horn as a client tool is proving just too cumbersome to really reach any sort of mass appeal. As with any client application, the number of different environmental factors that one client machine can have make it irritating, error prone and less likely to succeed in this form. Horn as a server tool negates the need for the code to run on every different client configuration.

The internal mechanics of horn also make it less appealing as a client tool. horn downloads a lot of source code onto the client machine before each build and this is not preferable for a lot of people who simply want the binaries and not the pile ofsource code that accompany such a build.

I have been mulling over moving horn to the server for some time and I am very pleased to announce that we have had a very generous offer to provide the how in respect to the physical hardware for horn to run on the server.

The good people of iMeta have agreed to give us some much needed server space in their infrastructure to take horn to the next level. We have not really got down to the specifics of the partnership but it is enough to say that if we develop our end then they will give us a slot to make the next step a reality.

There is no doubt that horn is an ethically sound proposition. Anybody who has experienced the versioning hell that we have set out to eliminate knows that put simply the disparate OSS bits do not play together. I take my hat off to iMeta for having such faith in backing us in our quest to take the friction out of OSS adoption and maintenance thereafter.

I would like to especially thank Hadi Hariri for orchestrating the partnership.

As an aside, I wish that we were getting some feedback from some of the more notable OSS projects out there. I mean projects like castle and Nhibernate. Even a quick “you are crazy” would be better than nothing at all. I think horn is an important OSS .NET project or at least the concept is and I wish for more people to get involved who have deeper roots in the .NET OSS landscape.

OK, that is the good news and now let us get down to specifics of how this will work...............

Rather than downloading the binaries via a command line executable we are going to produce a website that will mirror thepackage tree of horn descriptors. We want the web to mirror the package tree and allow categorised navigation via links or search around the site. Each descriptor will potentially have its own page in the web and on such a page the user will have a link to allow them to download a .zip file of the binaries for that descriptor.


What we are looking for is a very lightweight MVC application with very simple views that will be generated from the horn descriptors (more on that later). We either generate the views or we generate some sort of data format that the views will read from.

Which leads me onto the other new horn server side component. Put simply we are going to create a windows service that is going to recursively crawl round the package tree periodically and build all the descriptors it finds. The service will create or update the .zip files that are available for download from the web.

If any of this is of interest to you then please join the Horn user group for updates or check out the source here.