Mono Package and Deployment Framework

Codename "Spock"

Preface:

One of the most spectacular features of the Mono framework is the fact that all assembled Mono applications and libraries maintain universal compatibility across all platforms that Mono can run on. Under most circumstances, the same assembled application can run under the Microsoft.NET framework without recompilation. This offers some of the same abilities that can be had from Java. As with Java, you can package your entire application and library into a single Jar file format. This method is very popular in the Java world. A similar method for both Mono and Microsoft.NET, should be possible as well.

The need for single package framework is only half the battle. Java packages in most of its own dependencies, but Mono does not have to do that. Dependencies can be checked at install/runtime by checking the local machine's global assembly cache for compatible versions of the required libraries already installed. If the dependencies are not met, the app will not run, which requires the user to run out and find the dependencies required to run and install them. This can be a drag on deployment and limit the users willingness to even install the application in the first place. The perfect solution for this is a fully laid out central assembly deployment framework similar to apt-get in Debian or RedCarpet for SuSE, Fedora, NLD and others.

Proposal:

Single file deployment package - similar to RPM or DEB files, but with the ability of working across multiple platforms like Java's Jar format. This could possibly be based on a zip based format like Java's Jar format with a static file structure and file names to identify package file information.

Optional Dependency Information file format that contains a listing of packages that the current one provides, replaces, requires, as well as checks for the operating systems supported, outside package requirements, and if any traditional libraries are required.

Meta Information file format that hold information about the current package such as descriptions, an optional signature for guaranteeing the package identity came from the correct server or packaged by the right person and optional configuration options that could be extended in the future by allowing a simple installation framework to collect information before installation.

A launching script (for simple packages) or assembly (for packages needing custom options) that is stored with a static file name that tells what the package launcher so do to run the file such as additional checks that should be done, special commands that should be used to launch, any installation steps required, etc. If the assembly option is used, the assembly should inherit form a basic interface library that represent all the options that it could use. When the package launcher runs the package, it should search for the assembly, then any classes that inherit interfaces from the deployment library, create a new instance of the classes and set/pass and references to any of the managers preloaded helper objects that can do functions such as unzip, install, check for files, make a generic prompt asking for input from the user, etc. A layer of security could be apply at this level as well.

Any traditional libraries that must be built for a specific operating system for the package to function could be included in binary form or in a source format. In ether case the package dependency information should specify which operating system this package will work. In the case of sources, the files should be stored in a zip file or in a directory in the package. The launching app will check to see if it has built the binaries for the sources already and if not, it will extract them and build them as the launching assembly/script says too.

Package Launcher - similar to "java --jar" that can read the package, extract the information from its information files, and then run any commands in the lauching assembly/script to install the package into the gac if it has any libraries included, and provide automatic dependency failure information dialogs/console prompts with ways to download missing dependencies from any servers that pre-specified in the installation. If all tests passed and after reading all the required information to run, it would then run the assemblies according to its launching assembly/script.

Local Repository - a local directory with all the meta/dependency files of all the currently installed libraries or packages downloaded through the framework. This should be indexed and formated and have a strong naming system for all the packages. In theory this could be an extension of the GAC that already exists in the framework.

Deployment repository server - contains all the files for all the dependencies and packages to be downloaded on demand when needed. The format should be based on something basic such as http or ftp to allow easy pass through of downloading though proxies and caching servers. The server system should be static as to allow easy mirroring using existing techniques. A possible solution is to include all packages in the current server in a single zip file, full of the meta package information files in a XML serialised format for easy reading. The client could then scan all servers when it updates by checking to see if it should download from that server if it has a new updated package file by checking the timestamp of the zip file before downloadin. This method would lower traffic on servers with lots of packages and traffic.

Package Browser

An offically ran server - an official server to be the example of the service. While anyone can run a server, the one ran by the mono team can hold packages only tested by the mono team themselves and can also be the deployment framework of Mono packages such as GTK# and MonoDevelop as well as many other libraries.

Saturday, February 26, 2005 DRAFT - ITEMS SUBJECT TO CHANGE!