Package Manager for .NET
Package managers in one form or another are practically everywhere: Gems and Rip for Ruby, Maven for Java and the sea of bottled for various Linux and Unix distributions. And only .NET-developers in the old-fashioned way crawl around the sites in search of a particular version of the required library.
Being one of these developers and tired of the constant search for the required components, I decided it was time to finish. The result of this decision was the same component manager for the .NET platform
Meet: octalforty Componento (the first alpha is available here for 32-bit OS or here for 64-bit fellows). This, to my knowledge, is the first attempt at creating a package manager for .NET.
The mechanism of operation, in principle, is not very different from its counterparts in other environments: there is a central repository to which clients access and from where they receive information about what to download from where. A significant drawback is that the package format (in fact, zip archives) is not standardized at all, therefore, compared to the same Ruby, chaos reigns everywhere in this respect. But this is a new thing (assuming a successful course of affairs, of course).
')
The folder into which Componento has been unarchived is best to add to the
Imagine that you are at the very beginning of the project development and begin to collect the necessary libraries. Suppose the project folder structure is similar to the following:
In
A real .NET developer cannot step on without a unit test and ORM tool. Therefore, at the first stage we will need NUnit, NHibernate and Fluent NHibernate. Let's start:
To such a command, Componento will quite reasonably respond by saying that “No packages installed”. Let's see what components are on the server:
Great, just what you need.
The
In addition, Componento can install from the Subversion repositories, folders, and Zip files. For example,
And a few words about dependencies. If the root folder in which Componento installs the specified component, will be the file
then the Componento will recursively install all the dependencies, and later it will check for version conflicts and will not allow it to be so easy to remove the component if it has dependencies.
A lot of them. First, there is no package format per se. That is, there is absolutely no metadata about the component (unless there is a version and a name). Secondly, the work with local folders and archives is not fully thought out. Third, it is not yet possible to publish your components in the central repository (in the ideas of both a web interface and a separate API for publishing components). Fourthly, platform support is not formalized (for example, the separation of components into those for Silverlight, .NET 2.0, .NET 3.0, etc.). Well, in general - this is just the first alpha.
I am not yet ready to put this work on the court of the English-speaking public; first you need to get something more substantial. Therefore, suggestions, suggestions, comments and criticism are welcome. Let's build a package manager for .NET!
Being one of these developers and tired of the constant search for the required components, I decided it was time to finish. The result of this decision was the same component manager for the .NET platform
Componento
Meet: octalforty Componento (the first alpha is available here for 32-bit OS or here for 64-bit fellows). This, to my knowledge, is the first attempt at creating a package manager for .NET.
The mechanism of operation, in principle, is not very different from its counterparts in other environments: there is a central repository to which clients access and from where they receive information about what to download from where. A significant drawback is that the package format (in fact, zip archives) is not standardized at all, therefore, compared to the same Ruby, chaos reigns everywhere in this respect. But this is a new thing (assuming a successful course of affairs, of course).
')
"Go!"
The folder into which Componento has been unarchived is best to add to the
PATH - it will be easier further.Imagine that you are at the very beginning of the project development and begin to collect the necessary libraries. Suppose the project folder structure is similar to the following:
In
src , the source code of the product itself, in lib , third-party libraries, well, in doc , obviously, the documentation.A real .NET developer cannot step on without a unit test and ORM tool. Therefore, at the first stage we will need NUnit, NHibernate and Fluent NHibernate. Let's start:
C: \> cd d: \ projects \ acme \ lib E: \ Projects \ Acme \ lib> componento list
To such a command, Componento will quite reasonably respond by saying that “No packages installed”. Let's see what components are on the server:
E: \ Projects \ Acme \ lib> componento list / remote octalforty Componento 1.0 Alpha 1 Copyright (c) 2009 octalforty studios Downloading 4.3 Kb autofac (1.4.4.561) bltoolkit (3.0) ... fluent-nhibernate (1.0) ... nhibernate (1.2.1) nhibernate (2.1.0) ... nunit (2.5.0.9122) nunit (2.5.1.9189) nunit (2.5.2.9222) ... urlrewriting.net (2.0) zedgraph (5.1.5)
Great, just what you need.
componento install nunit - and the most recent NUnit will be in the lib folder. Install nhibernate and fluent-nhibernate same way. The result is this:The
_componento folder is the cache of the downloaded files, and componento.db is the database of installed components and their dependencies.The remaining features
componento install nunit /version 2.5.0.9122 you could install the NUnit library version 2.5.0.9122, and with the componento uninstall nunit /force /recursive command to remove NUnit and all dependencies.In addition, Componento can install from the Subversion repositories, folders, and Zip files. For example,
componento install bltoolkit /source svn+http://bl-toolkit.googlecode.com/svn/trunk/ will take all the BLToolkit sources from the specified repository (the svn+ prefix is required when accessing the repository via HTTP or HTTPS ). And the componento install myproject /source d:\projects\myproject.zip team componento install myproject /source d:\projects\myproject.zip “installs” the archive myproject.zip .And a few words about dependencies. If the root folder in which Componento installs the specified component, will be the file
dependencies.txt following content:nhibernate-linfu file:///e:/lib/nhibernate-linfu
nhibernate-castle file:///e:/lib/nhibernate-castle
then the Componento will recursively install all the dependencies, and later it will check for version conflicts and will not allow it to be so easy to remove the component if it has dependencies.
Cons and flaws
A lot of them. First, there is no package format per se. That is, there is absolutely no metadata about the component (unless there is a version and a name). Secondly, the work with local folders and archives is not fully thought out. Third, it is not yet possible to publish your components in the central repository (in the ideas of both a web interface and a separate API for publishing components). Fourthly, platform support is not formalized (for example, the separation of components into those for Silverlight, .NET 2.0, .NET 3.0, etc.). Well, in general - this is just the first alpha.
Instead of conclusion
I am not yet ready to put this work on the court of the English-speaking public; first you need to get something more substantial. Therefore, suggestions, suggestions, comments and criticism are welcome. Let's build a package manager for .NET!
Source: https://habr.com/ru/post/68453/
All Articles