HTTPS everywhere is a common theme of the modern infosys topics. Despite of that when I google for implementation of HTTPS in ASP.Net MVC applications, I find only a handful of horrible questions on StackOverflow, about how to implement HTTPS only on certain pages (i.e. login page). There have been numerous rants about security holes awaiting for you down that path. And Troy Hunt will whack you over your had for doing that!

See that link above? Go and read it! Seriously. I’ll wait.

Have you read it? Troy there explains why you want to have HTTPS Everywhere on your site, not just on a login page. Listen to this guy, he knows what he is talking about.

Continue reading

One of the tasks have performed lately in our massive web-application is restructuring menu. And for the menu to work correctly we had to make sure that every page is somewhere on the menu.

For Menu generation we use MvcSitemapProvider. And for strongly-typed references to our controllers/actions we generate static classes via T4MVC. Task of making sure that every controller action (out of ~600) has a SiteMapAttribute is very tedious. And with development of new features, this can easily be forgotten, leading to bugs in our menu. So we decided to write a test. This turned out to be yet another massive reflection exercise and it took a while to get it correctly. So I’d like to share this with you.

Theory of the test are simple – find all controllers, on every controller find all the methods and check that every method has a custom attribute of type
MvcSiteMapNodeAttribute. But in practice this was more complex because we used T4MVC.

Continue reading

Note for yourself, when you are registering odata route in web-api configuration, it must be placed before the default catch-all route. I.e. :

Gloabal.asax.cs:

    protected void Application_Start()
    {
        // .. do stuff

        // This must be before registering all other routes    
        GlobalConfiguration.Configure(WebApiConfig.Register);

        AreaRegistration.RegisterAllAreas();

        RouteConfig.RegisterRoutes(RouteTable.Routes);

        // do other stuff...
    }

Of you place web-api route registration after MVC route registration, MVC routes will take priority and probably you won’t have OdataController in your MVC code.

And no, nothing magic about OData there, just standard routes registered in Asp.Net application.

After using MVC bundling and minification for a bit I run into a few problems. All of them are well known and will cause you trouble.

First of the problems I encountered – reordering of files in the bundle. When I add to bundle Main.css and then add MainOverrides.css I bloody-well mean it to stay in this order, cause overrides will not do anything if they are posted before the main file. Same goes to jquery and plugins.

Another issue I run into was image urls inside of css. When css files are bundled, they are output as:

<link href="/bundles/jquery-ui_css?v=U5E9COcCYIcH9HU1Qr9aiQotqSzLGT8YYDi6qhOpObk1" rel="stylesheet"/>

Continue reading

Generally Exceptions are usually thrown by parts of the code that encounter unrecoverable situation. Like famous NullReferenceException is thrown when code tries to access properties of object that is null. I’m sure you know this, don’t need to tell that 101 of programming again. My point is that exceptions are always thrown and it is down to other parts of code to catch exceptions and do something with them. Because if exceptions are not caught, the’ll bubble up to the top level and will crash your application.

I’ve never seen any methods that return exceptions. Never thought of exceptions as something that can be returned by a method. Have you?

Today I’ve spent some time doing work on bundling and minification in MVC5 project. I did open dotPeek decompiler to check how it actually works. And I came across this bit of code:

  Exception exception = this.Items.IncludePath(virtualPath, transforms);
  if (exception != null)
  {
    throw exception;
  }
  // do other stuff

I’m not posting full source code here, but it is available from MS Symbols server. That’s where dotPeek got the sources from

Note in the block above a method does something and exception is returned. It does not throw exception. Exception is thrown a level closer to user – method I’m showing you is public and I’m going to use it. Method that returns exception is internal and not accessible for consumer.

My first reaction was that this breaks Clean Code convention: method modifies state of application and does not return objects, or method returns information, but does not change anything. Basically commands and queries in CQRS: commands for writing, queries for gathering data.
Here we have a clear violation – method modifies program state and returns exception.

I went exploring deeper and looked through some other methods. The convention in this library is: private methods return exceptions. Public methods throw exceptions. This looks strange and new to me.

Remembering university course on machine code (a.k.a. Assembler, yes, I’ve done that one and loved it!) throwing an Exception involves walking execution stack which involves a lot of CPU cycles and tracing (details escape me now). This results thrown exception being expensive in terms of CPU cycles. A quick googling revealed a stack of answers and blog posts to confirm my understanding.

Given this, I presume this technique is used in the library to avoid performance penalty on throwing an exception. And the deeper the exception is thrown in the execution stack, the slower it is. Also this technique adds a lot of extra boilerplate code to methods. If you use traditional throw new Exception() then instead of this:

    Exception exception = this.IncludePath(virtualPath, (IItemTransform[]) null);
    if (exception != null)
      return exception;

you’d simply have this:

this.IncludePath(virtualPath, (IItemTransform[]) null);

Where private method would just throw an exception.

Bottom line. Unless this is used for purposes other than optimisation, don’t use this technique – it’s confusing and against conventions. And if you find your exceptions to be a bottleneck (enough to optimise it), you throw way too many exceptions and need to rethink your application. If there is other purpose to this approach, please tell me!

Now, as promised my other project is hosted and built on hosted Team Foundation Service and it took me a bit of fiddling before I managed to run NUnit tests on it. However, there is an excellent walk-through how to do that: http://www.mytechfinds.com/articles/software-testing/6-test-automation/72-running-nunit-tests-from-team-foundation-server-2012-continuous-integration-build

Much in the same way you can do xUnit:

  1. Download xunit.runner.visualstudio-x.x.x.vsix from Codeplex.
  2. Change file extension from .vsix to .zip and open with zip archiver.
  3. Copy all xunit.*.dll files to a folder that is mapped to TFS and check them in. I prefer to have these files in /BuildFramework folder

xUnit_VS

  1. Now, pretty much the same as with NUnit set up (If you have not done that before), you need to update settings for Build Controller. In VS go to Team Explorer -> Builds -> Actions -> Manage Build Controllers. And set “Version Control path to custom assemblies” to the folder where you have saved adapters for xUnit:

Build_controller

And you are pretty much done. You can now check in and your xUnit tests will run on hosted TFS (Presuming TFS is set up correctly to run your tests).

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.

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