Why NuGet?

tusmestertusmester RSS Feed

One of the most important aspects of a modern software is how to get it into the hands of customers. Especially developers, because they are the ones who will spend most of their time working with our libraries and components.

In the last couple of years we published sensenet as source and binary install packages, and after installing either of them, developers had to copy libraries around and take care of references themselves. We knew that we have to come up with something easier. A more reliable and modern way to distribute our components as fast as possible.

Fast updates

We chose nuget.org to publish the bits of our ECM platform, because in the .Net world that is the de-facto standard for delivering libraries. We want to be where our developers are, where they are looking for products and plugins (this is why we are moving our source code to github).

If you are not a developer, don’t panic. We are working on another way to distribute sensenet: an installer with a nice user interface for the ones who prefer that. This post is for developers who feel comfortable in their well-known environment, Visual Studio, and want a familiar way to get started with sensenet 7.0.

The previous version, sensenet 6.5 is still distributed the old way, as a source package and a Web Platform Installer package.

Install only what you need

Another reason why we chose NuGet is that it lets us publish our platform in small, separate components and let you install only the ones that you actually need in your project. Search for ‘sensenet’ in NuGet Package Manager in Visual Studio to see all our packages (remember to switch on the ‘Include prerelease’ checkbox to access the latest ones).

Take a look at this article for details about the components we offer.

Package list in Visual Studio

No more moving dlls around

We want you to think in packages instead of dlls. We still compile sensenet into multiple dlls, but you do not have to know how many there are and copy or reference those libraries manually. That is one of the coolest advantage of moving to NuGet.

Even if you want to modify the core source code (we would be glad if you decide to help our community by contributing to the project!), you can create your own personal NuGet packages using the scripts we also publish, and distribute those modified packages in a custom (public or private) NuGet feed.

Do you deliver a full ECMS through NuGet, seriously?

We are aware that NuGet was designed to distribute small components that contain a few libraries – and sensenet is much more than that. We publish configuration files, database scripts and other file system content along with dlls. After importing the necessary packages into your solution, you will still have to make a few steps manually and complete the installation process in the command line, but at least it is a lot easier than before.

To be able to pull this off, we had to split our packages into two parts: there is a base package that you can import into any kind of project, because it contains only libraries. And there is a corresponding ‘install’ package that you should import only into your web application project. Do not worry, it is easier than it sounds, see the details in the following article:

Have feedback on this post? Let @sensenet know on Twitter.

Need help or found a bug? Contact us.