ASP.NET Package Managers
.NET has always seemed slightly behind the likes of Java and Ruby in terms of trying out new ideas. It seems we in the .NET community let them try things out and if it works we make our own version. Package Management is the latest example of this.
In a nutshell package managers are tools for managaing the dependencies of a product. They aim to greatly simplify the retrival and mangament of the libraries and resources your applications need. Two of the main Package Managment products at the moment are OpenWrap started by Sebastien Lambla, and NuGet, supported by Microsoft. There are some differences between the two, outlined here, and it is not clear at the minute which of these two projects will become the de facto choice. NuGet is closley bound to Visual Studio 2010 which has both its advantages and disadvantages. Here is a brief demo of both of them, starting with OpenWrap:
Before doing any work in Visual Studio we start by running this command:
D:\playpen\> o init-wrap MyProject
This does a number of thing for us, including setting up the folder structure OpenWrap needs to house our new project and creates a wrap descriptor file defining all the projects dependencies in OpenWrap's own DSL.
We can then load up Visual Studio, and create any sort of project you want (without a solution directory) inside the 'src' directory made by OpenWrap, then run this command:
D:\playpen\MyProject> o init-wrap -all
This has the effect of removing this line from the project file:
<Import Project="$(MSBuildBinPath)\Microsoft.CSharp.targets" />
And replacing it with openWraps own custom MSBuild script, effectively putting OpenWrap in charge of our dependencies.
<Import Project="..\..\wraps\openwrap\build\OpenWrap.CSharp.targets" />
So supposing we want to add the ORM framework NHibernate to our project, we just run the 'add-wrap' command and OpenWrap will fetch all the correct versions of all the required libraries, if you now return to Visual Studio you can just start coding without worrying about having the right references.
D:\playpen\MyProject>o add-wrap nhibernate
# OpenWrap v1.0.0.0 ['D:\playpen\MyProject\wraps\_cache\openwrap-1.0.0.47636484\bin-net35\OpenWrap.dll']
Wrap descriptor found.
Project repository present.
Trying to add package.
Project repository: openwrap up-to-date.
Project repository: SharpZipLib up-to-date.
Project repository: openfilesystem up-to-date.
Project repository: Ninject up-to-date.
Project repository: log4net up-to-date.
Project repository: NHibernate-3.0.0.3001 added.
Project repository: Iesi.Collections-1.0.1 added.
Project repository: Antlr-3.1.3.42154 added.
Project repository: Castle.Core-2.5.1 added.
System repository: NHibernate up-to-date.
System repository: Iesi.Collections up-to-date.
System repository: Antlr up-to-date.
System repository: Castle.Core up-to-date.
System repository: Iesi.Collections up-to-date.
System repository: Antlr up-to-date.
System repository: Castle.Core up-to-date.
Now lets have alook at NuGet, It offers a similar command line experience to those that want it, with the Package Manager Console Visual Studio window, or you can rely entirely on the GUI. You need to start by installing the Visual Studio 2010 extentions from here. Once that is installed, just create a project as you normally would, now when you go to add a reference to a library, there is a new 'Add Library Package Reference' option, choosing that shows this dialog:
So if we wanted to add a reference to NHibernate as we did in the OpenWrap example we just search for 'NHibernate' and then click install, and all the required references and any associated web\app config changes are done automatically for us, and we can begin coding.
Behind the scenes a new 'Packages' directory has been made inside your solution that contains all the relevent dlls managed in folders according to the dll's version. Also added is a packages.config file, that defines all the libraries required, so that NuGet can keep track of what references are being used.
<?xml version="1.0" encoding="utf-8"?>
<packages>
<package id="Iesi.Collections" version="1.0.1" />
<package id="Antlr" version="3.1.3.42154" />
<package id="NHibernate" version="3.0.0.3001" />
<package id="Castle.Core" version="2.5.2" />
<package id="Castle.Windsor" version="2.5.2" />
</packages>
For a more in-depth intro to NuGet, read Scott Hanselmen's blog post here.
In summary these projects filling a vital hole in the .NET stack, by doing some legwork allowing developers to spend more time using all the amazing libraries out there and less time figuring out how to set them up.
Dan Garnys
Developer Knowledge Sharing
The typical day of a software developer, like most workplace roles, is full of time pressures. You have to demonstrate that a particular piece of functionality behaves as per a user's story by the end of the week, and delivering late will impact the projects budget.
So you need to get it done, and move onto the next as soon as you can. When the project finishes, you move straight onto another. And that's not to mention the hundred possible day to day distractions.
The result is that day to day demands can easily distract the community of developers in your company from taking that important step back to consider the bigger picture, a vital ingredient in quality software development.
Without taking some time out to get all developers together for reflective consideration of processes and technologies you are using to deliver software, you can end up grinding away with the same familiar yet flawed or outdated methods, which make projects harder to deliver with the required quality and on time.
You can also end up with isolated project teams, unaware of what each other is doing - a novel solution to a problem may not be shared across all developers.
Projects should always end with a post-mortem. This usually involves everyone involved on the project: the PM, consultants, developers, testers, designers. Thus it is an invaluable project review, concerned with the successfulness of planning, meeting targets and deadlines, customer satisfaction, communication etc. However it is not a place for a developer code review, as it will be relatively non-technical, and only involves the subset of developers who worked on that project.
Therefore we need a different kind of review - a regular code review of a particular project (whether just started or long finished) or a technology, involving the entire development team. The goals should be:
- To discuss and debate interesting, new or problematic processes and technologies, including everything from macro architecture to tiny code fragments.
- To have as many developers as possible critically questioning why things were done as they are.
- To highlight what code performed well, was easy to extend and maintain, and is easy to read and understand.
- To highlight what code performed poorly, was hard to extend and maintain, and is difficult to read and understand.
- To share software engineering tips, tricks and technologies across project teams, so everyone learns from other teams.
- To share business knowledge across project teams, so everyone learns the business rules of new clients, what the solution does and how it benefits the client.
For example, in just a one hour session over some lunch to review a recently completed Windows Forms application, we covered the following topics:
- AutoMapper, it's pros and cons, when to use it, problems encountered integrating it with Castle Windsor dependency injection container.
- Accessing NHibernate entity collection properties (e.g. lists) - protection of a private instance, and exposing collection add and remove methods.
- NHibernate configuration conventions.
- Persisting 3 closely related entities in one database table using NHibernate, discriminating them using a table column. Pros and cons of this approach, how successful it was.
- Managing database transactions in a Windows Forms application - use of conversation attributes, discussion of what application layer should be responsible.
- Use of Behavior-Driven Design principles and rich domain objects, what effect this had on ease of development, readability and testing.
Topics like these are discussed day to day by developers within a team or between yourself and the person sitting next to you. The benefit of getting this discussion out into a larger debate involving all developers at the same time has been invaluable at Perfect Image.
James Allen
