Archive for the ‘Maven’ Tag

Easier automated builds and continuous integration with Naven: A .NET port of Maven

I love Apache Maven. I really do. It increased my productivity and quality on java projects so much! I stopped worring about the small and repetitive details about my build process.

But here in 4N1, we have a lot of projects in .NET, and we could not find a good, easy and free tool like Maven for the .NET world, so we decided to start our own.

Naven comes to the rescue!!!

Naven is a port of the Maven concept, meaning that you don’t need to specify a build process, you just need to inform how your application is, and Naven will “create” the build process for you. Implemented as a command line application (but with the real logic in a C# 4.0 API), Naven can be used as a build automation tool and executed inside a continuous integration server, in fact, here in our CI server(Jenkins) we use it already.

We also did Naven to help spread build automation and CI concepts, making it easier for someone to automate their build process.

Apache Maven has a POM (Project Object Model) to define the caracteristics of your projects. Since the .NET world already have a POM (the *.csproj and such files), Naven only needs a AOM (Application Object Model). The AOM is a file that contains the basic information about your application.


Basically, a Naven application has components. The currently supported are:

  • Solution: References an existing .Net solution.
  • Project: References an existing .Net project.


In the Naven world, a build process is divided in phases. Phases are nothing more that steps of a build process. The currently supported are:

  • Initialize: Deserializes the AOM file and initialize all necessary objects.
  • Validate: Validates the AOM file looking for errors (EX: pointing to an invalid solution, a non existent project file, etc)
  • Resolve Dependencies: Since version 0.2.0, Naven integrates with Nuget, meaning that if you have projects that specify their dependencies in a Nuget file (package.config) it will install the packages for you.
  • Compile: Using MSBuild, executes the compilation of the components of your application.
  • Tests: Using NUnit, Executes the automated tests of your application.

Besides the “out-of-the-box” phases, you can extend the Naven build process using NAnt, on the “custom phases”. They happen before and after their respective phases:

  • AfterInit
  • BeforeValidate
  • AfterValidate
  • BeforeResolve
  • AfterResolve
  • BeforeCompile
  • AfterCompile
  • BeforeTest
  • AfterTest


A Goal is something that you want Naven to do with that component. The currently supported are:

  • Resolve: Tells Naven to resolve the dependencies of the component. In the current version you don’t need to specify this Goal because it will process all “packages.config” files found.
  • Compile: Tells Naven that the component should be compiled.
  • Test: Tells Naven that the component have tests that should be executed.

NOTE: In the current version you need to manually specify the Goals, but we are planning to apply the concept of Convention over Configuration, and try to figure it out what are the expected Goals for a particular component, for example, adding the Test goal automatically for all projects with the name ending with “.Tests”.

Here is an example of a concrete Naven AOM file:

<?xml version="1.0" encoding="utf-8"?>
<DotNetApplication xmlns="" xmlns:xsi="" xsi:schemaLocation="">

  <!-- Application name -->
  <Name>Sample App Name</Name>

  <!-- Application description -->
  <Description>This is just a sample application.</Description>

  <!-- Path where Nuget packages will be installed -->


    <!-- Represents an existing solution -->
    <Solution Path="Solution.sln">

        <!-- Tells naven to compile this solution. Normally this would be the solution that contains all the projects of your application. Here in <a href="">4N1</a>, we normally have a "main" solution, will all the projects. Its easier and faster to compile a lot of related projects. -->

    <!-- Represents an existing project -->
    <Project Path="SampleProject.Tests\SampleProject.Tests.csproj">

        <!-- Tells naven to run the tests on this project. Naven will look on the .csproj file to find out
	where the compiled assembly is.-->

      <!-- Inside a "custom phase", you can use all NAnt tasks (as long as you include their assembly in the same folder Naven executable) -->
      <echo message="This is happening after Init"/>
      <echo message="This is also happening after Init"/>
      <property name="Environment" value="SomeValue"/>
      <echo message="This is the environment: ${Environment}"/>

How to use it?

Just grab the latest release(v 0.3.0) on the Naven repo, unzip it, create your Naven AOM file and execute the command line, like this:

  • nvn.exe PATH_TO_THE_AOM_FILE Resolve
  • – To resolve the dependencies of your application.

  • nvn.exe PATH_TO_THE_AOM_FILE Compile
  • – To compile your application.

  • nvn.exe PATH_TO_THE_AOM_FILE Test
  • – To compile and test your application.

Properties Support

When extending Naven native build process with NAnt, you may need to supply additional properties values when invoking Naven by command line. Just like NAnt /D:PropertyName=PropertyValue switch, you have a similar mechanism in Naven:

  • nvn PATH_TO_FILE GOAL /p=PropertyOne:ValueOne /p=PropertyTwo:ValueTwo

On the “custom phases” implementation, you reference those defined properties just like normal NAnt properties:

<?xml version="1.0" encoding="utf-8"?>
<DotNetApplication xmlns="" xmlns:xsi="" xsi:schemaLocation="">
  <Name>NAnt Support Application.</Name>
  <Description>An application that shows the NAnt support.</Description>
      <echo message="This are properties references: ${PropertyOne}, ${PropertyTwo}"/>

What are the next planned features?

Naven has a lot way to go to get even just a little bit closer to the great tool Maven is. With that in mind, we have planned a few features already.

  • Convention support: By parsing the main solution file or searching for project files below the base folder.
  • Support other agents: An agent (for now) may be a DependencyResolver, a Compiler or a Tester. Naven code is made with dependency injection concepts, so we could change the default agents used. The ones available now are only:
    • MSBuild for compilation
    • Nuget for dependency resolution
    • NUnit for testing
  • Additional phases: We plan also to extend the Naven build process, to include some additional phases. Some of them may be:
    • Package: Creates a package of your projects/applications in Nuget format.
    • Install: Install the package in a package manager, probably a Nuget server for now.
    • Deploy: Deploy the application/project on a server.

For all this, we really would like to receive some help or opinions, specially because Naven is Open Source, and also because we hope it make your life easir. 😀 Feel free to check it out, download it, use it, and contribute. The 4N1 team thanks you.