The story of my open source project turned SaaS

This story begins roughly 5 years ago.

I was working mainly on Line Of Business applications in Asp.Net MVC and a recurring task was to setup a way to create PDF docs, for business flow or reporting.

In the past I used a lot Cristal Reports, it had a very nice editor that users that weren't programmers could use with ease. Sometimes, though, it was problematic when installing on new servers and it was expensive, especially for projects where the requirements did not involve producing new layouts frequently.

Then I found the wkhtmltopdf command line tool, tried it and looked at opinions on the web. The first experiences where great, it was fast and the PDF docs came out pretty nice. And it was free...

It required some manual installing and some code to write. It wasn't that easy. The code was a bit strange, it involved spawning a external process, not a usual activity for web development.

Project after project I copied and pasted this "strange" code and every time I did, I tweaked it a little bit more. Made the helper method easer to use. And finally found a way to integrate it in the Asp.Net MVC flow.

This constant improving led to a very nice code interface. It turned using wkhtmltopdf in Asp.Net MVC from "hard" to "trivial". What an evolution! I was quite content with my work, so I thought about sharing it with the community.

I looked at Github and Nuget. It didn't look that hard to wrap the helper classes in a library and make it available on Nuget. So I did! It took just a few hours, all the work was already done! Just some wrapping and configuration for the Nuget package. I named the project "Rotativa", Italian for rotary press.

Made some "marketing" activity, like answering questions about PDF creation on Stackoverflow, writing posts on CodeProject and this blog. Not long and the project went ahead under its own steam. Got a few pull requests, some really useful. Downloads on Nuget started flowing rapidly. People started talking about it.

And so came the problems. People reported issues on Github, wrote to me directly, added questions on Stackoverflow and so on. Most of them weren't for bugs in the library code. Some were for wkhtmltopdf issues or problems with the original HTML and CSS, a lot were for installation problems. The latter were almost impossible to debug, they depended on what was installed on the server, what graphics library were supported, what security policy was enforced and so on; with all the possible variants a server or web hosting environment can have. This debugging activity took some time, a lot more then the time spent to publish the library and the code. Friends suggested I should have charged for support.

More and more of those issues were related to using Rotativa in Azure web sites (AKA app services).

On the other hand Rotativa gave me lots of dev love and recognition. Lots of praising. But from a professional standpoint, it gave me nothing. At least here in Italy, in the MS/.Net field, not a lot of the people that hire developers or manage software project even know what Github is or care if you created a popular Nuget package. Open source software? A weird and dangerous activity.

So I more or less abandoned the project. Preferring activities like watching TV and sleeping (sometimes simultaneously).

But a thought just kept lingering in my mind: Why not helping all the Rotativa users with wkhtmltopdf compatibility problems by setting up a service on Azure so that you wouldn't need to install wkhtmltopdf to use Rotativa. I would charge for that and, perhaps, make it profitable and finally make all this effort worthwhile.

I knew that this would be a big effort, with a lot of question marks but somehow I sensed a feeling of inevitability. I just had to do it. I could, so I would have to. That force was strong enough to overcome my (tired old man) laziness. One step at a time, just doing what was absolutely necessary to get to the next step and get more feedback.

So here we have it: RotativaHQ (stands for Rotativa Headquarters).

Perhaps I'll add some details to the story on another post, if anyone is interested.

How to unit test PDF creation in .Net

This is a quick recipe to set up in an easy way unit testing for PDF documents in .Net.

The idea, since it wouldn't be possible to verify the layout of a PDF, is to check its text contents.

In order to do so we can use the iTextSharp library. This library enables creating and editing PDF documents. It's commercial but is free for this kind of usage, as long as you don't make it part of a commercial solution.

First of all you should install iTextSharp Nuget package:

PM> Install-Package iTextSharp

Then you can use the following simple method to check if a given text is present in a PDF binary:

What’s new in Rotativa 1.3

The long awaited update of Rotativa has finally arrived. It has important new features, that meet users requests and add new ways of creating Pdf files.
Adding to that I finally managed to add badly needed test automation and I hope I can add more tests in the future.
I should give credit to Scoorf for submitting a nice pull request on GitHub that holds much of the new features. Merging his pull request gave me the opportunity to learn about branches in Git, I should say it’s really easy and very effective and safe way to manage collaborative code.

New features are:

ViewAsPdf action result

This basically works as the normal View action result but you get the Pdf instead of the Html response.

Basic syntax is:

     public ActionResult TestViewAsPdf(string id)  
     {  
       var model = new MyViewModel {DocTitle = id, DocContent = "This is a test"};  
       return new ViewAsPdf(model);  
     }  

It’s even easier then ActionAsPdf, plus you won’t have problems  with authentication and cookies.

UrlAsPdf action result

This action result enables to return any URL as pdf.

Pdf properties

Now are available new properties for the Action results. Those new properties are:

• Margins
• Size
  • Paper size (as in A3, A4 etc)
• PageWidth and PageHeight
• PageOrientation
• Post
• To set Post values
• and a handful of others…

Rotativa, how to print PDF in Asp.Net MVC

Creating PDF docs in Asp.Net MVC is a fairly common functionality requested by LOB applications. Usually either for reporting or, more often, for having printable friendly documents (invoices, receipts etc).
I used to design a Crystal report document and then evaluate it and convert it to PDF in the web application. The desing part was ok but what really bothered me was the problems that often came up with deploying it. Version mismatches could really turn it into a nightmare.

Lately I came up using the excellent wkhtmltopdf tool to convert html content to PDF. It uses the WebKit engine (used by Chrome and Safari) to render html. The nice thing about it is that I can leverage my knowledge of html and css to obtain a good looking PDF and also it's quite fast.

It's a exe file not a dll library (a dll actually exists but it's not managed code and it has some problems related to usage in a multi-threaded app). It has to be executed from the Asp.net app spawning a process, so it requires some unusual coding from a web development perspective. Another downside is that it requires some work to set it up: copying exe and dll files in the web app solution, make sure they get copied over when building and publishing and some config stuff needed to make it access authenticated actions.

It seemed to me a perfect candidate to become a Nuget package. It was fairly easy to build it, except some quirks when trying to modify package properties.

I've named it Rotativa /rota'tiva/, which is Italian for rotary printing press.

With Rotativa all it takes to print a PDF is:
1. Install using the Nuget package manager (search for Rotativa) or, more conveniently, with the package manager console, typing:

Install-Package Rotativa

2. Writing a controller action to return a view representing the desired PDF output. This means just coding as usual to serve the data as regular MVC action. Such as:

public ActionResult Invoice(int invoiceId)
{
    var invoiceViewModel;
    // code to retrieve data from a database
    return View(invoiceViewModel);
}

Nothing special here, just an action. Perhaps the view used will have a different master page (or layout page) then the other views of the web app (or you’ll define a separete css for the print media, see http://www.w3.org/TR/CSS2/media.html). You can test and “preview” the results just using the browser, since we are working with a regular action, returning a html result.

3. When the html is ok you can just setup a special action returning a custom ActionResult: ActionAsPdf. The code will look like this:

public ActionResult PrintInvoice(int invoiceId)
{
  return new ActionAsPdf(
                 "Invoice", 
                 new { invoiceId= invoiceId }) 
                 { FileName = "Invoice.pdf" };
}

ActionAsPdf requires a string parameter with the name of the action to be converted to PDF. It can accept a parameter with other route data, in this case we are defining the invoiceId parameter. You can specify the name of the file being returned using the FIleName property.

To link to the PDF file in other views you just have to insert a regular link to the PrintInvoice action. Something like

@Html.ActionLink(“PrintInvoice”)

if you’re working with razor views.
And voila, that’s all and it just works, even if the printed action is protected with forms authentication.

Source code is on GitHub https://github.com/webgio/Rotativa.

NHibernate sessions in ASP.NET MVC

If you've used NHibernate in a ASP.NET MVC project you probably encountered the problem of keeping session open in the view in order to retrieve model data. (even though if session is open then the view actually makes calls to the db under the hood, which maybe is not very MVC. But that's another story)

The idea is to pass controllers an instance of a NHibernate session which is unique for the http request.

First off we need to "hijack" the ASP.NET mechanism that instantiate controllers to pass something in the constructor. In this case it's a ISession, but it could well be a repository class (which in turn gets a ISession passed in its constructor).

So a controller would look like this:

public class MyController : Controller
{
    ISession session;

    public MyController(ISession session)
    {
        this.session = session;
    }
...

I've used Unity dependency container to manage the instantiation of controllers. ASP.NET MVC lets you do that by overriding the DefaultControllerFactory.

This is as simple as writing this class:

public class UnityControllerFactory : DefaultControllerFactory
{
    UnityContainer container;

    public UnityControllerFactory(UnityContainer container)
    {
        this.container = container;
    }

    protected override IController GetControllerInstance(RequestContext requestContext, Type controllerType)
    {
        IController controller = null;
        if (controllerType != null)
        {
            controller = this.container.Resolve(controllerType) as IController;
        }
        return controller;
    }
}

To make the session instance "singleton" for the http request, all I need to do is write a simple custom lifetime manager for Unity:

public class PerRequestLifetimeManager : LifetimeManager
{
    public const string Key = "SingletonPerRequest";

    public override object GetValue()
    {
        return HttpContext.Current.Items[Key];
    }

    public override void SetValue(object newValue)
    {
        HttpContext.Current.Items[Key] = newValue;
    }

    public override void RemoveValue() {} // this does not appear to be used ...
}

Let's get everything together in Global.asax. We need to register NHibernate ISession in Unity configuration. It should inject it using a factory method (OpenSession method of a ISessionFactory instance).

Then we need to tell MVC to use our Controller factory, passing the Unity container of our ASP.NET MVC application.

To close open NHibernate sessions we add some code in the Application_EndRequest.

Here's the code to put in our Global.asax file.

protected void Application_Start()
{
    this.container = new UnityContainer();
    ISessionFactory sessionFactory = NHConfigurator.CreateSessionFactory(); 
    // NHConfigurator is my helper conf class

    container.RegisterType(
        new PerRequestLifetimeManager(),
        new InjectionFactory(c => {
            return sessionFactory.OpenSession();
        }));

    ControllerBuilder.Current.SetControllerFactory(new UnityControllerFactory 
(this.container));

    AreaRegistration.RegisterAllAreas();

    RegisterRoutes(RouteTable.Routes);
}

protected void Application_EndRequest(object sender, EventArgs e)
{
    Object sessionObject = HttpContext.Current.Items[PerRequestLifeTimeManager.Key];
    if (sessionObject != null)
    {
        ISession currentSession = sessionObject as ISession;
        if (currentSession != null)
        {
            currentSession.Close();
        }
    }
}       

Hope this helps!

Unit testing and the "constructors do nothing" rule

Introduction Writing unit testing code is really easy. It's not much more then writing some client code of the library you want to test and add some assert calls to check (test) if the code works as expected. With C# now we have lots of alternatives to do that. But is it just that? Not really! Let's briefly look at some principles behind unit testing. A unit test, as the name implies, should test just a unit a code. If it doesn't and it ends up depending on some other code then it becomes hard to tell why the test passes or not. Also, depending on other code makes test hard to make repeatable. Just think about testing a method that depends on some database operation, now you should take care of maintaing database state over repeated calls to your test suite. Being able to isolate units of code not also makes it more testable but also easier to work with and to refactor. This post will try to explain some good practices to make your C# code more testable. Constructors should do nothing This is an important rule you should enforce if you want your code to be testable. It also makes it easier to enforce SRP (Single Responsibility Principle). In the class constructor, objects should not be created, because if they are then your class becomes coupled to them and you are not able to inject testing objects during unit testing. Lets jump to some sample code.

    public class StringsCalculator
    {
        public int Sum(string x, string y)
        {
            int xi = 0;
            int yi = 0;
            int result = 0;
            if (int.TryParse(x, out xi) && int.TryParse(y, out yi))
            {
                result = xi + yi;
            }
            else
            {
                throw new ArgumentException("Strings passed are not integers.");
            }
            return result;
        }
    }

This class StringsCalculator contains a method Sum that takes two strings and tries to sum them if the can be parsed as numbers. It clearly does two things, converting strings to integers and summing them. So if we want to test does separatly we should separate the two responsibilities. Perhaps separating the string conversion in a class StringToNumber:

    public class StringToNumber
    {
        public int Convert(string stringNumber)
        {
            int result = 0;
            if (!int.TryParse(stringNumber, out result))
            {
                throw new ArgumentException("String is not a number");
            }
            return result;
        }
    }

Thus we can refactor our StringsCalculator class:

    public class StringsCalculator
    {
        StringToNumber stringToNumber;

        public StringsCalculator()
        {
            this.stringToNumber = new StringToNumber();
        }
        
        public int Sum(string x, string y)
        {
            return stringToNumber.Convert(x) + stringToNumber.Convert(y);
        }
    }

This looks better, but what about our test:

        [Test]
        public void SumStringsNotTestable()
        {
            StringsCalculator ss = new StringsCalculator();
            int result = ss.Sum("2", "3");
            Assert.AreEqual(5, result);
        }

It tests our class but this way it tests also the StringToNumber class so it's really not "unit" testing. So let's follow the "Constructors do nothing" rule by doing some refactoring. First off let's separate the two classes by putting a interface between them. In Visual Studio we just need to right click on the StringToNumber class and choose Refactor->Extract interface... and name it IStringToNumber. Next we need modify the StringsCalculator constructor to accept a parameter of type IStringToNumber.

    public class StringsCalculator
    {
        IStringToNumber stringToNumber;

        public StringsCalculator(IStringToNumber stringToNumber)
        {
            this.stringToNumber = stringToNumber;
        }
        
        public int Sum(string x, string y)
        {
            return stringToNumber.Convert(x) + stringToNumber.Convert(y);
        }
    }

Mocking objects Now we can refactor our test to instantiate the StringsCalculator object by passing to its constructor a mock object and not a StringToNumber object. To do this we can use one of the many mocking frameworks for .Net around. I chose the very nice RhinoMocks library, that's easy to use and quite complete. So here's our new test:

        [Test]
        public void SumStringsTest()
        {
            MockRepository mocks = new MockRepository();
            IStringToNumber stringToNumber = mocks.StrictMock();
            StringsCalculator ss = new StringsCalculator(stringToNumber);
            Expect.Call(stringToNumber.Convert("2")).Return(2);
            Expect.Call(stringToNumber.Convert("3")).Return(3);
            mocks.ReplayAll();
            int result = ss.Sum("2", "3");
            Assert.AreEqual(5, result);
            mocks.VerifyAll();
        }

As you can see we can instruct the RhinoMocks repository to expect two calls to the IStringToNumber. In this way we are able to verify the inner workings our our class, thus doing what is called white-box testing by calling the VerifyAll() method. Constructor injection Having all collaborators classes passed in as constructor parameters enables us to decouple nicely and test in isolation. But what about the client code using this classes, do they have to do lots of code to instantiate all those collaborators? Well there's a nice solution to this, dependency injection containers. In my case I'll use Unity, by using it to instantiate objects, client code doesn't have to prepare alkl those collaborators, Unity will take care of it, even in cascade if those collaborators themselves have other collaborators as constructor parameters. We can implement a integration test to verify our classes together:

        [Test]
        public void SumStringsUnityTest()
        {
            UnityContainer container = new UnityContainer();
            UnityConfigurationSection section =
                (UnityConfigurationSection)ConfigurationManager.GetSection("unity");

            section.Containers.Default.Configure(container);

            IStringToNumber stringToNumber = container.Resolve();
            StringsCalculator ss = new StringsCalculator(stringToNumber);
            int result = ss.Sum("2", "3");
            Assert.AreEqual(5, result);
        }

Unity configuration code could be conveniently located in a helper class. So, to summarize, we can say: Constructors do nothing, all collaborators are passed in as parameters so we can mock them in unit tests and let a dependency injection mechanism compose them in client code.

Separating layers and components with constructor injection and Unity

Ok, so how did I come to using Unity and constructor injection?

Anyway ... what is Unity? And what is constructor injection?

Unity is a "dependency injection container", (see http://www.codeplex.com/unity/ for details) in other words it is a library that implements mechanisms to easily apply the dependency injection pattern.

Dependency injection is a design pattern that aims at separating concerns, like separating from the application specific domain all the other concerns that are not strictly "about" the topic of the application (usually are more low level).

For example in a mp3 player app, connecting to the db to save personal info about the songs is not something that affects software functionality. If the db app changes or we decide that the info is going to be stored to a remote server through a web service, the functionality will still be there and the app will continue to work. It would be different if we wanted our app to be able to play iTunes audio books. That would be a change that affects the domain of the app.

So it's a valuable thing if we can separate those facet of the application from the "real" functionalities. This separation enables us to think more clearly and in a clean way about our application and not mix different concerns. Also we can unit test better and apply test driven development.

Let's see a sample app. What about the dear old "Hello world" functionality?! This app is about... saying hello... to you.. :-)
By the way this time we are going to log who are we saying hello to. How and where we are going to store this info is not really relevant to the app. We just want to able to call a method like Log(message), in the HelloWorld method of our class (MainClass, forgive the ugly name..):

   public class MainClass
   {
       ILogger logger;

       public MainClass(ILogger logger)
       {
           this.logger = logger;
       }

       public string HelloWorld(string name)
       {
           string helloMessage = "Hello " + name + "!";
           this.logger.Log("Said hello to " + name + "!");
           return helloMessage;
       }
   }

HelloWorld calls the Log method of an object implementing the ILogger interface. This way our application is not dependent upon a specific logger implementation, hence the inversion of dependency, the main application doesn't depend on the loggr, it's the logger that depends upon the ILogger interface defined by the app.

Here's a quick look to how the visual studio solution looks like:



It's very simple, we have a UnitySampleUse project, a MyLogger project and the test project UnitySampleUse.Test.

UnitySampleUse contains the ILogger interface. MyLogger contains MyLoggerClass that implements ILogger, so MyLogger contains a reference to UnitySampleUse. If we where going to instantiate a MyLoggerClass object inside UnitySampleUse we would have to reference and we don't want to make ou app depent upon MyLogger (plus we would have circular reference).

So who's going to glue things together and pass a ILogger object to UnitySampleUse?
Guess what... Unity!

The client of our code, in this case the test project (it could be a UI project or another library), uses Unity to instantiate ILogger, automagically composing our MainClass, passing in the constructor the concrete object implementing ILogger.
The mapping of the interface to the class implementing it can be stored in the xml config file (app.config), that, in our case, will look like this:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <configSections>
    <section name="unity" type="Microsoft.Practices.Unity.Configuration.UnityConfigurationSection,Microsoft.Practices.Unity.Configuration, Version=1.2.0.0,Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>
  </configSections>

  <unity>
    <typeAliases>
      <!-- Lifetime manager types should be inserted if you need lifetime managers -->
      <typeAlias alias="singleton" type="Microsoft.Practices.Unity.ContainerControlledLifetimeManager,Microsoft.Practices.Unity"/>
      <typeAlias alias="external" type="Microsoft.Practices.Unity.ExternallyControlledLifetimeManager,Microsoft.Practices.Unity"/>
      <!-- User defined type aliases -->
      <typeAlias alias="ILogger" type="UnitySampleUse.ILogger,UnitySampleUse"/>
    </typeAliases>
    <containers>
      <container>
        <types>
          <type type="ILogger" mapTo="MyLogger.MyLoggerClass, MyLogger">
          </type>
        </types>
      </container>
    </containers>
  </unity>

</configuration>

The test will need to instantiate the MainClass using Unity:

UnityContainer container = new UnityContainer();
UnityConfigurationSection section =
        (UnityConfigurationSection)ConfigurationManager.GetSection("unity");

section.Containers.Default.Configure(container);

MainClass mainClass= container.Resolve<MainClass>(); 

Unity will take care of calling the constructor MainClass(ILogger logger), injecting a MyLoggerClass object. Thus the type of dependency injection applied is constructor injection.

UnitySampleUse project can be compiled without having the source code of the logger and the client code (the unit test, or the ui etc) can switch logger implementation without change in the code by just referencing the new logger and updating the config file.

This way we can separate layers, for example our data access layer, very easily and at the same time keep all our application logic in one project.

Separating layers and building by components has never been easier.

This post is published on CodeProject