UPDATE: After initial excitement about xUnit, I needed to deal with some specifics. And now I don’t advise to move ALL your tests to xUnit. I’d recommend go into that slow and read through my rant here, before you commit to converting.

Nunit is a great testing framework. Only it is a little old now and new testing approaches are no longer fit into Nunit concepts. I’m talking about using Autofixture for generating test data. So I decided to see how xUnit will pan out for our projects and should we convert all our tests into xUnit or not.

Benefits of xUnit over NUnit are simple for me: AutoData attribute from Autofixture does not play nicely with NUnit due to architectural wirings. There are ways to have Autodata for
Nunit
, but this does not work nicely with Resharper 8.1 and NCrunch.

Continue reading

Before today I’ve heard of IlMerge tool. This allows you to bundle all your small .dll files into one. So if you deploy stand-alone applications, you only have to give a single file to your users. Today I decided to give it a go. And I was disappointed -( error messages were endless. IlMerge did not like this or that or some other assembly.

I quickly looked around and found Costura.Fody package that did exactly what I needed, only I did not have to do any work. All you need to do is install nuget package:

Install-Package Costura.Fody

And you are done. No, really. Build your project and check out the output. You’ll see a bunch of dll files as before. This is because input files are not deleted automatically. But if you check your executable – it is much larger now. And you can move it away from the rest of libraries files and it will work.

There are some settings available. Check the details on https://github.com/Fody/Costura.

Package installation will create FodyWeavers.xml file in the root of your solution – put your settings there. I needed to exclude debug symbols from the resulting file. Here is how my FodyWeavers.xml look like:

<?xml version="1.0" encoding="utf-8" ?>
<Weavers>
  <Costura IncludeDebugSymbols='false' />
</Weavers>

Also I did not care about “minifying” the libraries into one file when I built the debug, but I needed it for Release build. So in my .csproj file, at the very end I have this:

  <Import Project="Fody.targets" Condition=" '$(Configuration)' == 'Release' " />
  <!-- Below is the clean-up - removing the input dll files-->
  <Target AfterTargets="AfterBuild;NonWinFodyTarget" Name="CleanReferenceCopyLocalPaths" Condition=" '$(Configuration)' == 'Release' ">
    <Delete Files="@(ReferenceCopyLocalPaths->'$(OutDir)%(DestinationSubDirectory)%(Filename)%(Extension)')" />
  </Target>

By default the package only adds one line:

  <Import Project="Fody.targets" />

And usually this is good enough. But I’ve added checking for build type and also my OCD required to produce a clean output folder. All this is explained on the GitHub page, on the very bottom.

Overall, very nice package! It just works.

Lately I’ve experienced a very slow editing on Razor pages in Visual Studio 2013. I had a set of extensions installed, but nothing special: Resharper 8.1, Web Essentials and VSCommands. When I was editing Razor .cshtml file, every keystroke was painfully slow, especially when I was trying to edit C# code there: we have a lot of helpers and html generation tools, our view are almost html-free, only control builders.

Long story short, by disabling extension one by one, I’ve narrowed down the performance issue to Web Essentials setting that tries to auto-format HTML.

To fix that in Visual Studio 2013 go to Tools -> Options; select Web Essentials section and HTML sub-section; and disable Auto-format HTML on Enter:

web_essentials

I did write about uploading files to Azure Storage via REST API before. It turns out that implementation is very naive. As soon as I tried uploading anything larger that 64Mb, I hid a brick wall with exceptions.

Azure Blob Storage has 2 types of blobs: Page Blobs and Block Blobs. Page Blobs are optimised for random read-write operations. Block Blobs are storage. Here more about Page vs Block blobs. If you are just storing files in Azure, you’ll most likely will use Block Blobs.

It turns out that Block Blob storage has some limitations on the upload front. In one go you can upload up to 64Mb: 1024 * 1024 * 64. Add one extra byte and you get an error from the API (I
tested it). So instead of uploading large files, you need to cut them into blocks and then upload separate pieces of no larger that 4Mb. And once all the pieces (Blocks) are uploaded, you need
to commit them all and give order in which they should appear.

Continue reading

Being on holidays gives me a lot of time to go through MVC questions on StackOverflow. And a lot of questions come from misusing of ViewBag and ViewData. A lot of people leave out Model from MVC and just slap all their data into ViewBag. And this is bad.

I can understand why people are lazy: [sarcasm] creating an extra class can be very problematic, takes a lot of keystrokes [/sarcasm]. What people don’t realise is that ViewBag make them work harder.

ViewBag is a dynamic entity and it can contain any property it likes with any type it likes. So every time you do in controller something like this:

    public ActionResult SomeViewBagAction()
    {
        ViewBag.SomeText = "blah";
        return View();
    }

Continue reading

Entity Framework relies on models to have a default constructor with no parameters. But if you are working with DDD often you would like to have some parameters in your constructors. And then slam a protected default constructor just for EF not to throw exceptions.

So you end up with code like this:

public class Product
{
    protected Product()
    {
        // This is required for EF
    }

    public Product(String name)
    {
        Name = name;
    }

    public String Name { get; set; }
}

The first constructor must not be used by developers, so you make it protected – this is good enough for EF.

Continue reading

CQRS architecture seems to be very popular. And I’m on that wave as well. In short CQRS is separating all read-actions from write-actions. And you have different classes for reading and writing. Queries for reading. Commands for writing.

For queries you would have IQuery and IQueryHandler interfaces:

public interface IQuery<out TResult>
{
}

public interface IQueryHandler<in TQuery, out TResult> where TQuery : IQuery<TResult>
{
    TResult Handle(TQuery query);
}

For command you would have very similar set of interfaces:

public interface ICommand
{
}

public interface ICommandHandler<in TCommand>
{
    void Handle(TCommand command);
}

Continue reading

There are doubts about if you should test registrations in you IoC container. I have been intimidated by this blog-post for a while and did not touch container for writing our tests. However, we did have a problem in the past, when DI container could not create one of our controllers. And we have lost days trying to chase the problem – there was no meaningful error message, because the real exception was swallowed somewhere in transit. It turned out that we have violated DI principal of a simple constructor: “Do nothing in constructor”. I have blogged about this before.

Today I would like to show how we test our IoC container to check if it can create all our controllers. Because controllers are immediate aggregate roots that are used by an end user. And controllers in MVC are the final consumer in the dependency chain. So if you likely to hit a problem in a chain of dependencies, it is likely that you will catch it by creating all the controllers.

Of course, if you use IoC container as a service locator or Mediator pattern you will have to test container separately for the types you get out from container there (mostly Command Handlers and Query Handlers).

Continue reading

While writing and testing ASP.Net MVC application, many times over I needed to simulate HTTP Request and presence of HttpContext.Current. I need this mostly when I try to test code that interacts with MVC framework, like MVC Action Filters or custom Model Binders or testing routes.

ASP.Net MVC 4 is quite good in this matter – most of the framework can be replaced by a mocked object and there is a minimum number of static calls or sealed objects. So you can do the HTTP Simulation, but usually it involves a lot of boiler-plate code and many mock-objects to be set-up.

Continue reading