Allow Me To Share My Toolset Choices for Developing On .NET

There was a question in a tech facebook group I co-manage about what tools you’d use if starting a new project today.


I don’t know for sure. It depends -of course- is the expected answer. For example, there’s some idea I had I mind I considered using MongoDB or CouchDB for, while still using .NET, and then I wasn’t sure if I go extra mile in DB I’d go for Node or Rails as well or would prefer .NET for my personal productivity. I also often use Node/Bower when checking libraries with many dependencies.

So, for this question, I thought what tools I might use in a company project. Thinking back, I found that most tools I use now are good enough for what they do. So, I thought I’d list these.

These tools are my personal experience though. While some of them are widely adopted in Readify, some others may have been specific to some clients or Readify teams I worked with. Every team is free to choose the tools that work best for them and make it easier to deliver high quality deliverables in sensible time, so, even if you are at Readify, your mileage may vary…

The Tools

Server Side Web


  • SQL Server (or SQL Azure, although I don’t like SQL Azure, because it’s not compatible with some scripts generated from SSMS, which I sometimes use to generate migration scripts)

  • DbUp for DB migrations (there are some other nice options now)

  • Special SQL views + Web API OData + MS Excel for reporting

Client Side Web

  • Angular.JS on the client when I have the choice, Knockout.JS and jQuery UI (being deprecated now) at some big client I keep going back to every few gigs

  • LESS for CSS, or SASS (SCSS) when the CSS is handled by one of our favourite design agencies

  • Chrome devtools for web debugging (obviously), unless it’s IE issue of course.


  • Phonegap (most just the open source part of it, Cordova) and Ratchet CSS framework (considering alternatives, like TopCoat) for mobile development, with Angular.JS

  • Considering Xamarin as their work seems to be VERY cool, and I recently get access to their stuff via my company (OT: Also considering Neo4j DB for similar reasons).

IDEs and Text Editors



Internal Communication

  • Several kinds of wikis used by different clients, often with OneNote

  • HipChat for team communication, sometimes Skype and/or Lync as well

  • AnswerHub (Stackoverflow clone) for internal questions forum where I can safely quote client sensitive information in my question

  • Yammer for internal company social network

How about you?

What tools do you you use when developing?

Let me know in the comments, via email, or on twitter!

Enforcing ASP.NET MVC Conventions With Unit Tests, Or Solving The AJAX HTML Redirect To Login Page Problem

This blog post is about an ASP.NET MVC workaround we implemented in a previous project. We solved the problem by enforcing using a class that extends one of ASP.NET MVC classes, which in itself created another problem, as new developers joining the project may always use the old class. The solution to this problem was not something that I invented, but it’s also not a very common practice.

So, if you are interested, here’s the entire story…

Detecting Session Timeout In AJAX Requests

We wanted to solve a problem where in an AJAX heavy ASP.NET MVC application, if the user triggers an AJAX action after staying inactive for longer than our application timeout, the call to the controller action, which normally gets a JSON response, would instead get the HTML of the login page.

This is a known issue in ASP.NET (particularly System.Web). A feature that’s on by default is returning a redirect to the login page instead of a HTTP Unauthorized Status code (401). After the redirect the response returned is a successful (HTTP Status Code 200) load of the login page. That means even our Angular.JS error interceptors (or jQuery handlers, etc.) don’t notice there was an error.

A fix for this was turning this feature off. We inherited the Authorize attribute as below:

SuppressFormsAuthenticationRedirect is the property that disables the login redirect. Microsoft set it to false by default so that it’s backwards compatible.

ASP.NET MVC doesn’t recognize AJAX requests through Request.IsAjaxRequest() via Accept header or so. It does via checking X-Requested-With header. Most AJAX-capable frameworks like jQuery and others offer a way to intercept all requests and add extra headers, for example, in that app, we configure Angular.JS to include the header with some code similar to this:

Enforcing The Convention

The obvious problem with the previous solution is that we are ignoring The Power Of Defaults. Any other developer who may join the project needs to know that using Authorize is a no-no, and even for old devs (myself included),
it’s very easy to just forget and use Authorize not AuthorizeRedirect just out of habit.

Solving this problem was quite easy though, we added the following test to our Unit Tests project:

I hope the code is self explanatory. We check the web project assembly for all ASP.NET MVC Controllers, then we check the Controllers and all their Action methods for existence of the AuthorizeAttribute. We filter those that use the correct attribute (AuthorizeRedirectAttribute), and we Assert that there are no the no Controllers or action remaining, otherwise, we tell the developer which Controller or Action needs to be fixed, and how to fix it as well.

Room For Improvement

The drawback of this is that our Unit Test project had to reference the ASP.NET MVC assemblies and gets more stuff than most tests should need. We can overcome this by moving our “convention” tests into another project completely, but for this project the conventions were very few and it seemed fine.

Of course the same method can be applied to any other convention you enforce in your project. One obvious example is ensuring all Controllers inherit from a custom base Controller class instead of the ASP.NET MVC class directly. I know people who already do this, as I mentioned in the opening the technique is not new by any means, but it’s worth even more popularity.

Speaking of improvement, the code for this test class was optimized a bit while writing this blog post, there is always room for improvement :)


In case you were reading the code carefully, the IsNullOrEmpty() method I used in assertions is a custom extension method we had in the project, a very simple one as you may expect:

And That’s it!

I hope you found the technique useful if you haven’t used it before, or found the post a good place to reference it to those who didn’t.

Serializing A PagedList Using JSON.NET In ASP.NET MVC – Gotcha And Workaround

Recently I discovered that there’s no one standard way for AJAX-driven server-side paging in ASP.NET MVC (in Web API, you can expose an IQueryable). For the case in hand, I decided to use PagedList for the server bit of the game.


The PagedList interface looks a bit like this (for demonstration only, real code is a bit different, check its source code for the real stuff):

It provides nice properties for paging, and exposes itself as enumerable and has an indexer. Apart from this snippet, the library also provides an extension method ToPagedList() to apply to any enumerable and allow it to populate the properties from it (by enumerating on it, and by calling the Count() method).

We were also using JSON.NET for JavaScript serialization, which is pretty much defacto standard nowadays.

The JSON.NET Serialization Problem

JSON.NET has a nice implementation, if you serialize a class that implements IEnumerable<T>, and you don’t have a special treatment rule for it (via what JSON.NET calls “Converter” classes), when you serialize an instance of the class to JavaScript, it will be serialized as a JavaScript array, where the enumerated objects are the contents of this array. Makes lots of sense right?

Well, yes, except when you have a custom collection like PagedList, and you want to treat it as an object that has several properties, not as an array. JSON.NET does provide a solution for this actually, all you need to do is apply the [JsonObject] attribute to your class.

Unless you don’t own the source code of this class.

In this case, you need to inherit from it. By doing this, I lose the nice ToPagedList() extention method (because it creates an object of the PagedList class directly), but luckily it does nothing but calling new PagedList() with the parameters we give it, so, we don’t lose much.

Here’s how my implementation looks like:

Apart from having to copy the constructors to pass parameters to the base ones, have you noticed the extra Items property in there?

That’s because the Subset member it includes is actually a field, not a property, and JSON.NET won’t serialize that by default, I could override it somewhere else, but since I’m fiddling with this here, it made sense to just stick a property to the class.

Bonus: A Bit More On Implementation

In my actual code, I have added the Dynamic Linq NuGet package, and assumed a single property for sorting (which was fair for the situations where I intend to use this), so, I complemented the code above with another class that looks like this:

This allows the controller to instantiate an instance of the SerializablePagedList class, pass it all the way to whatever repository method I have.

The repository method will take it as a parameter, work out what IQueryable it needs, and instead of passing it to UI, it calls CreatePagedListFromQueryable(), which returns an innocent-looking PagedList object (because SerializablePagedList inherits PagedList) that the repository can pass back to the controller, which can serialize it to JavaScript without a problem, then the rest is all JavaScript code to work out how create the paging parameters, and how to use the returned paging hints.

Even more, now that I think about it, maybe I should change the return type to SerializablePagedList, to make the Items property visible to the developer (because they’d think it’s magic, and in coding, magic is BAD). I’ll leave this as an exercise for you :)

Final Words / Disclaimer

The motivation behind this post is that I found the problem of serializing PagedList using JSON.NET a challenge and I wanted to help others work it out faster than I did. Is this how I’d recommend doing paging? Well, I don’t know, but if it’s what you choose, I hope that I have saved you some time.

And more importantly, is it good enough to be the defacto standard I mentioned I was after in the beginning of the post? Not really. I think it’s not bad, but definitely not the best. I’d love to see less clever (read: hacky), and more simpler solutions.

Videos from ALT.NET Sydney Usergroup, 30 July 2013

Continuing my experiments of recording the few events I attend in Sydney using a simple Galaxy S4 phone, this time I’m posting videos from Sydney ALT.NET usergroup gathering in July.

Of course if you are interested in all the videos I put online, including a few tutorials I have created myself instead of just recording, check out my channel on YouTube.

Now to the videos…

Applications of the Reactive Extensions framework

By Niall Connaughton, @nconnaughton on twitter

Moving to HTTPS

By James Crisp, @jtcrisp on twitter

Final Note

Please let me know if you find these videos useful. I may not be able to do much about the quality in the short term, so, it’s worth knowing if the videos as-is are helping, or I need to pause until I get better tooling than just my phone camera and a simple webcam.

So, check out all the videos on YouTube, leave comments ion them, and let me know the topics that interest you, which may in the future turn into tutorials I create myself, or suggestions to ask usergroup leaders to look for presenters to talk about.

Manually Compressing Any ASP.NET Page, PageMethod, MVC Action, HTTPHandler,..

Compressing A Single ASP.NET Response Manually

This post is about compressing your HTTP result without using IIS Dynamic Compression. I’ll save the story to the end and give you the code first:

Well, this shows how to do the compression itself. Depending on how you do ASP.NET, you probably will call it differently.

In my case, I called it manually from an ASP.NET Webforms PageMethod (more on why below), but if you are using ASP.NET MVC for example, you probably want to wrap it in an ActionFilter and apply that to the action you want to compress its output. Let me know in the comments or on twitter if you have a problem implementing it in a particular situation.

IIS Dynamic Compression

IIS 7+ has built in dynamic compression support (compressing output of server-side scripts like ASP.NET, PHP, etc.). It’s not by default because compressing dynamic content means running the compression for every request (because it doesn’t know what the server-side script will generate for every request, the point of using server-side programming is generating dynamic content!).

Static compression on the other side (caching static files like styles and scripts) is on by default because once the static resource is compressed, the compressed version is cached and served for every future request of the same file (unless the file changes of course).

General advice: I’d say if your server side scripts expect to return large text-based content (say, large data, even after paging, etc. like large reports or whatever), always turn dynamic compression on, at least for the pages that expect to return large data sets of text.

In many cases though the majority of large files will be scripts (and possibly images) will be the larger parts though, which are often taken care of (for scripts for example) by IIS static compression or ASP.NET Bundling.

Download Visual Studio Updates For Offline Installation

In case you don’t know already, Visual Studio 2012 Update 2 was released April 4th (Official AnnouncementDownload PageRelease Notes).

Like the previous Visual Studio update, you get a very small EXE file, which you run to download the update from the Internet, install it, and then delete it. This means that if you need to install the update on multiple machines, you may need to download it multiple times.

In this post, I’ll show you how to get the EXE to download the files to a known location so that you can use it on multiple machines, my sample update will be Visual Studio 2012 Update 2.

Offline Download Instructions

  1. Download the standard small EXE file, for VS 2012 Update 2, the filename is VS2012.2.exe
  2. Open a command window at the same folder you downloaded the EXE to

    One easy way to do it is open the folder with Windows Explorer, and write "powershell" (or "cmd" for standard command prompt – both without quotes) in address bar

  3. In command window, write

    Note the "/layout" flag, this tells the EXE you want to download the files and keep them, instead of install and delete them. Also note the file name may be different for different updates (or if you saved it with different name)

  4. When a wizard similar to installation shows, choose the download folder at the first step and press "DOWNLOAD".   

    download location

    I suggest that you create a new folder to store the files to, what you are downloading is an EXE with the same file name as what you downloaded, and a "Packages" folder containing all different bits of the update

  5. Wait as the download completes. This will take time, long time. That’s why we want to do it fewer times, right?


    Once finished, you can copy the downloaded folder to other machines, and use the EXE next to (NOT inside) the "Packages" sub-folder to install the update without requiring any extra downloads.

The instructions are also found at the end of the download page, but it seemed that not many people noticed it, which is why I wrote this post.

Gotchas & Going Forward…

Note that the download tool isn’t exactly like your preferred download manager. Don’t expect download speed optimizations or error-proof resume for network failures, etc..

There is a feature request for the Visual Studio to include the update in an ISO file that you can download use the best way you like instead. If you want to see this happening, please vote it up here:

Creating Explicit Route To Website Homepage In ASP.NET MVC

Typically, you have this standard piece of routing configuration:

Which does the job of matching “/” to HcomeController‘s Index action.

The reason it works is simple, the id parameter is obviously  optional, the action parameter if not present will be set to Index, so, this routing will match “/home/index/”, and similarly will match “/home/”. But the controller also will be set to HcomeControlimageler if it’s not present (the Controller suffix is a convention in class name), so, this matches “/home/” and “/”.

Using Explicit Route

Until here, there is no point of this blog post. So, lets say for whatever reason you are using other routing rules, because your desired routes don’t follow this very convention or because you don’t want to couple public URL structure to internal class names or have another reason to make your routes explicit, how do you set a route for the homepage or website root “~/” URL in this case?

One possible case is to have this exact default route still there, but make sure it’s at the very end of your route registrations, after all other have been registered, so, it has the least priority in matching. The drawback is that it’s still more generic than its purpose, technically allows using it for other actions than the one handling the homepage, and every request to homepage will go through all routes tried first (which is usually not a very slow thing to be honest).

So, a nicer way is to be able to have an explicit homepage route. Maybe even one that can be put on the top of route registrations to make the request to our homepage the fastest ever (although again, it’s not a big deal or difference, but nice to have). Turns out the way is VERY easy, just set the URL to an empty string “”.

Yeah, that’s it (the “name” doesn’t matter BTW, and you can obviously use whatever controller/action too). Even if you are using the default routes, you can combine it with them, and put it before them too. Empty string will NOT match any URL that is not empty (you can argue all other requests are matched against this, but comparing a string against an empty one must be VERY quick, right?)

Note that this all is application specific, so, the root here is website root “~/” not server root, so, this should still work if your website is hosted under some virtual directory too.


p>Not that it matters a lot, but thought some of you would be interested :).

Have fun.


Grouping ASP.NET MVC Controllers And Views By Features

If you don’t like your folders to be named after blah software pattern (that happens to be MVC), and would like instead of having “Views” and “Controllers” folders (not many use “Models” folder), to see things like “Administration”, “Members”, “FeatureA”, “FeatureB” etc. folders in your web application instead, it’s not that hard.

Putting Controllers Next To Their Views, Literally

The easiest (likely not most convenient) way to do this is to move your controller class files to their corresponding view folders! Controllers are picked up by ASP.NET MVC by base type and class naming convention, not location or filename, so you can put them anywhere in the project and they’ll still be picked up.

This is how it works for the default ASP.NET MVC 4 “Internet Website” template:


The obvious problem now is that it’s harder to find them. Depending on how you usually work, you can renamed the file to make it show first (Add a couple of underscores to it for example), or maybe it doesn’t make a difference at all if you locate files by CTRL+ , (comma) or CTRL+SHFIT+T (if you use Resharper).

I’m kind of with the 2nd option (leaving them as they are, and locating them using keyboard), especially that you usually shouldn’t have so many actions in your views, and not have have so many partials in the same folder anyway, so, even finding the controller in the Solution Explorer shouldn’t be a big problem (compare the “Home” controller ease to the ‘”Account” controller).

Replacing Views With Features

The first way still feels dirty, controllers in the “Views” folder? Isn’t “Views” part of the MVC pattern language also? Let’s rename that to “Features” (or whatever makes more sense to you). Then our application will look like:


But then we need to tell the RazorViewEngine to look for views in our new folder. There are several ways to do this, I’ll go for the stupid one for simplicity. In your ASP.NET MVC 4 global.asax.cs file, add the following to Application_Start:():


The code is very straight forward. We just replace the “Views” in what the engine looks for to be “Features”.

there is another place that we’ll still need to modify, the “_ViewStart.cshtml” file has the default Razor layout file set with full path, change it to:

Now the website should work fine.

Starting With Features

If you were to just add another folder called “Features” and under it add the various feature folders, each including the Controller and Views(s) used with it may (make more sense,, maybe even leave things like “Shared” in the original “Views:” folder and delete the “controllers” one),, these are the changes that would still be needed:

  • Manipulating the RazorViewEngine so that it looks for views in that features folder. Instead of replacing the existing entries, we insert new ones (copy existing ones to a List<string>, insert the new values at position 0 so that they are looked up first, and returning this as array to the view engine property).
  • Copying the “web.config” in the “Views” folder (not the one in the root of your web application) to your features folder
  • Copying the “_Appstart.cshtml” file from the “Views” folder to your features folder, as this is what provides common view initialization like setting the default layout file

Or Just Use Areas!


p>If all you really needed was grouping features, and you don’t mind the Controllers, and Views folders under each feature (or maybe even like them), then you could just use ASP.NET MVC Areas feature and have all the application features split in corresponding areas.

However, I assume if you really wanted just that, you wouldn’t be looking for this post anyway :-).


Yes, I know, there is still more bloat folders in the ASP.NET MVC application. Some of them you may (or may not) use like “Content” or “Scripts””, some of them maybe shouldn’t be there or should have been in a different project, but this just to show some of what can be done using the existing hooks, especially that using them didn’t turn to be that hard.


Lowercase URLs in ASP.NET MVC, The Easy .NET 4.5 Way And Other NuGet Options

If you wonder why you should care about creating lower case URLs at all, or what this actually even means, skip to the appendix at the end.

Earlier, the easiest way I have found to create lower case URLs (URL paths, not query strings) was to use the NuGet package LowercaseRoutesMVC, and modify the routing code, to use the library’s own MapRouteLowercase() extension method, instead of the built in MapRoute()extension.

For example, instead of:

You write:

The .NET 4.5 Way

.NET 4.5 introduced a new property to the RouteCollection class instances (the “routes” parameter in the code above is an instance of it).

The new property is LowercaseUrls.. Remember that routing is not shipped as part of ASP.NET MVC code, but part of the NET framework itself. So, this property is available to you as long as your project uses .NET 4.5+, whether it’s ASP.NET MVC 3 or ASP.NET MVC 4.

Usage is very simple, just set the property before you map your routes (or after the mappings were added, works as well):

The Result

Either you are using the third party NuGet package, or the standard .NET 4.5 property, after making the changes to the routes, this is what you achieve:

Lowercase URL Generation

All helpers used in in ASP.NET MVC to generated action URLs registered in the URL route mappings will generate lowercase paths. For example, Razor code:

Will generate the following HTML:

Lowercase URL Resolution

Of course the generation wouldn’t be complete without revolving the lowercased URL path back to the correct controller action. In the above example, the “/account/logon” URL will be resolved (assuming the default routing used in the first example in the post) to the LogOn action of the AccountController controller.

However, this is not accurate in fact, because typically we all get this already. Routes in ASP.NET MVC are not case-sensitive by default, so, both /account/logon is the same as /Account/LogOn to ASP.NET MVC.

If you want to force redirection to the lower case paths, for SEO or else, you can (very easily) do that with IIS 7+ and Url Rewrite module. I learned about it by trying, but here is an example of how to use it, and also an official video.

Using The Built-In Way Vs. The 3rd Party Options

The obvious difference is that the NuGet package require you to change every route call explicitly while the built-in way takes over all routes. If you are decided that any non-lowercase route is a developer mistake, then the built-in option may be a better way to minimize developer human error, if you need control or need to exclude some routes from this, then maybe the NuGet package is more suitable.

Note that this specific package hasn’t been updated since last Novemeber, but there are other similar packages on NuGet anyway, and it shouldn’t be too hard to implement one yourself.

If you care about routes and URLs as much, you may also considering writing tests for them.


There is another NuGet package specific to ASP.NET MVC 4, which includes experimental ASP.NET Web API as well. The package is: LowercaseRoutesMVC4. If you are interested in the project source code and more,, check out the LowercaseRoutesMVC project page. Again, note that this has been last updated on November 2011.

You’d expect the built-in property to affect Web API as well as it’s part of .NET 4.5 not 4.0, and as mentioned before it surely works with ASP.NET MVC 4 as well as ASP.NET 3. I’d personally use it by default in any future project..

Appendix: Why Should You Care?


p>Lower case URLs have already become the de-facto standard for so long. Historically, when all path URL parts were one-to-one mapped to physical file paths (excluding hashes, and query strings), this required URLs to be case sensitive because Unix file paths are case sensitive (and hence, Linux and so, unlike Windows). Search engines also had to respect this as well, as there is no guarantee that /directory/file.html is the same as /directory/Filename.html, or /Directory/filename.html or /DIRECTORY/filename.HTML, etc..

So, in brief, it’s better for SEO, and it’s becoming the industry standard anyway (for those who care), as showed earlier, even Microsoft has made enforcing lowercase URLs although not the default but a really easy thing to implement (regardless of the technology you use, the URL Rewrite module is enforcing lowercase URLs on this blog for example, which uses PHP (WordPress).

By generating lowercase URLs combined with the Url Rewrite Module, you save the users extra redirection steps, unless they decide to write the URL in a non-lowercase manner themselves.