Thoughts on Software

Archive for the ‘C#’ Category

Unsupported Project Type: Why won’t my Visual Studio project load?

leave a comment »

One of Visual Studio’s least helpful habits is that when you open a solution and one of the projects cannot be loaded, it simply gives you the unhelpful message the the project is of an unsupported type. Great. So what to do next?


The basic problem is that you are missing an indeterminate something that Visual Studio requires to load that project. For example, if the project type is MVC 3, you need MVC 3 installed on the machine you are opening the project on. Unfortunately, Visual Studio won’t tell you which project type it can’t load …


There are a couple of steps required to resolve this:

  1. Find out which project type is missing
  2. Install the missing software and reload


The information as to which project type is missing can be discovered from the .csproj file for the non-loading project. First, open the project in Notepad or similar and look for the ProjectTypeGuids tag:



This tag contains the Project Type GUIDS: ie, the identifiers which tell us what project types might be causing our exception. Now we need to work the friendly names for each GUID. I generally use this article as a starting point as it contains many of the common GUIDs:


Search through this page for each GUID in turn:

{E3E379DF-F4C6-4180-9B81-6769533ABE47} = ASP.Net MVC 4
{349c5851-65df-11da-9384-00065b846f21} = Web Application
{fae04ec0-301f-11d3-bf4b-00c04f79efbc} = Windows (C#)

In this case, the culprit is likely ASP.Net MVC 4 and sure enough, I had MVC 1, 2 and 3 installed but not 4 and so the fix is simply to download and install MVC 4.







Written by andrewlocatelliwoodcock

April 22, 2014 at 16:19

Waterfragile: Agile development in the Enterprise

with 3 comments

Waterfragile is my term for the most popular development methodology in use in Enterprises today.

Waterfragile is a heavily modified Agile methodology that adopts the best practises of Agile and Waterfall: the flexibility of Agile to adapt to changing (increasing!) requirements with the rigour of Waterfall to deliver promised features on a promised date. Waterfragile teams take on Agile overhead such as scrums, sprints, retrospectives, etc. but do not take on the bits they can’t be trusted with such as responsibility for the release or deciding which features should be included in each release or the deployment schedule. In fact, one of the central tenets of Waterfragile is that feature sets should only ever grow throughout the release cycle. Advanced Waterfragile practitioners refine this further by removing the ability to de-scope features as this focuses the team on developing 20 hours a day to meet the all-important external deadlines.

To do Waterfragile properly, only the development team should do scrums, sprints, etc. (it’s a development paradigm after all, no point wasting business analysis and test team time on this stuff!) and they should be slotted within a fully waterfall analysis, test and release cycle. If you fail to properly integrate the development team into the waterfall cycle, they may well miss their deadlines or skip features. Test teams should be fully prepped to pick up on all small visual defects – there’s no point spending too much time testing deep feature behaviour as that’s what development’s unit tests are for. Test teams should work to their own schedules and not waste time preparing tests ahead of the start of their test cycle so as to maximize their workload throughput.

Remember: what you are aiming for is separation not only of concerns but also of goals and responsibilities – teams should never be measured holistically on the successful delivery of a project but only on their part of it and the person responsible should never be the one making the decision as this can lead to dropping of features, missed deadlines, etc. The ability to add features, never remove them and still hit deadlines is Waterfragile’s killer feature – a minimum feature set and absolute delivery schedule can now be included in PowerPoint presentations about the project and as we all know “set in slide” is simply “set in stone 2.0”.

Done right, Waterfragile delivers all the benefits of Agile (faster release cycles, ability to make late changes to requirements) without losing any of the benefits of Waterfall (feature sets and delivery dates known months if not years in advance), a development methodology that has never failed to deliver even once over the last 40 years.

Written by andrewlocatelliwoodcock

November 14, 2013 at 19:08

How to distinguish HTTP POST action methods at runtime: Checking HTTPContext Server Variables

leave a comment »

Following on from my last post, there is an alternative method for distinguishing whether we are dealing with an HTTP POST. Before, I suggested checking the ActionDecriptor to see whether there was an HttpPost attribute applied. An alternative to this is to check the ControllerContext for the REQUEST_METHOD server variable. If this is “POST”, then this is an HTTP POST.


public static bool IsHttpPost(ControllerContext context) 
    return context.RequestContext.HttpContext.Request.ServerVariables.Get("REQUEST_METHOD").ToUpper() == "POST"; 


Written by andrewlocatelliwoodcock

January 26, 2012 at 18:03

Accessing Model validation errors from the Controller

with 16 comments

MVC performs automatic model validation whilst it is binding the model, so as soon as we hit the Controller action method that is being called, we have access to a validated model. In fact, as discussed in my last post, we actually have access to the results of model validation in the method’s ActionFilters, including the first ActionFilter: OnActionExecuting, which fires before we even reach the action method.

MVC Exposes the results of this validation through the Controller’s ViewData.ModelState property. This is directly accessible in the Controller by calling ModelState and is most often used to check whether a model passed validation:


if (ModelState.IsValid)
    // model passed validation, so do some work here


But if ModelState.IsValid returns false, ie the model failed validation, how can we see the collection of errors?

Read the rest of this entry »

Written by andrewlocatelliwoodcock

December 16, 2011 at 20:17

How to create an ActionResult from a string

with 2 comments

There are times when for whatever reason you want to return a string from a call to an Action method instead of a formal View; perhaps you want to return a Base64 encoded image or display the contents of a file, for example. ASP.Net MVC actually makes this very straightforward to do but it is not that well documented: use the Content method of the Controller as in the example below:

Read the rest of this entry »

Written by andrewlocatelliwoodcock

November 18, 2011 at 22:13

Posted in ASP.Net MVC, C#

Tagged with

Shaver Framework API: ShaverView

with 5 comments

Following on from our in-depth introduction to Shaver and the first part of Shaver’s API, the second part of the API is the ShaverView:

ShaverView is an abstract class that implements the IView interface and provides a set of extension points. Just like ShaverViewEngine, ShaverView cannot be used directly but is intended to provide a framework and API. Have a look at Logging View EngineMailer View Engine and PDF View Engine to see examples of how this is done.

The API is made up of three abstract methods that must be overridden by each implementation (Setup, ActOnHtml and RenderView), a virtual method that may be overridden by an implementation if required (CaptureHtml) and two static helper methods (GetViewData and GetTempData), that extract view and temp data from the controller context.

ShaverView’s constructor accepts two parameters the ControllerContext and an instance of IView. Not co-incidentally, these objects are supplied to ShaverViewEngine’s CreateReturnView method and it is intended that View inheriting from ShaverView will be instantiated in the ViewEngine’s CreateReturnView method. Once again, have a look at Logging View EngineMailer View Engine and PDF View Engine to see examples of how this is done.

The constructor calls the API methods in the following order:

  1. Setup – performs any setup tasks required
  2. CaptureHtml – captures and returns the HTML rendered by the Razor View Engine
  3. ActOnHtml – acts on the HTML returned from the CaptureHtml method
Setup and ActOnHtml, as previously described, are abstract methods and must be implemented by each concrete View Engine using the Shaver framework. CaptureHtml is a virtual method: it provides a default implementation that captures the HTML output generated by the Razor View Engine but can be overridden if necessary. ActOnHtml accepts the HTML returned from the CaptureHtml method as well as the ControllerContext and the IView object and performs whatever custom tasks are required by this particular implementation of the Shaver framework.
The Render method is required by the IView interface and simply calls the RenderView abstract method. RenderView must be implemented by any concrete implementation of the Shaver framework and is intended to perform the rendering tasks required by the particular View Engine.

Written by andrewlocatelliwoodcock

November 8, 2011 at 22:31

Shaver Framework API: ShaverViewEngine

with 4 comments

Following on from the last post, let’s start our discussion of the Shaver API with the Shaver View Engine itself:

There are a couple of things to note: firstly, ShaverViewEngine inherits from RazorViewEngine so that we can re-use and co-opt all the power of the Razor View Engine without re-inventing the wheel: Shaver is about doing unexpected, unenvisioned things with existing Razor syntax not developing a new syntax!

Secondly, there are only two methods: CreateView and CreateReturnView. CreateView overrides Razor’s implementation of the standard CreateView method and uses it to create an IView object which is then passed, along with the ControllerContext to the virtual method CreateReturnView. Custom View Engines that implement the Shaver framework can perform any custom tasks required within their own implementation of CreateReturnView: it is the output of CreateReturnView that is returned to MVC, not the output of CreateView as might be expected. We are letting Razor do the hard work here – it already does it really well, we just want to make it easy to do something different with the output!

CreateReturnView is the first extension point in our Shaver API.

Note also that Shaver itself provides no code to register custom view extensions: Shaver is an abstract View Engine and as such does not provide complete functionality only an API. As such, it makes no sense to attempt to register custom view extensions within the Shaver View Engine itself, this is a task for each concrete implementation such as LoggingViewEngine.

Shaver cannot in fact be used directly: note that it is an abstract class: we need a concrete implementation of the Shaver framework to instantiate – Shaver cannot and does not do the job on its own. Have a look at Logging View EngineMailer View Engine and PDF View Engine to see examples of how this is done.

Next: the Shaver API: ShaverView

Written by andrewlocatelliwoodcock

November 7, 2011 at 20:54

Shaver Framework: a more in-depth look at the View Engine

with 9 comments

In my last post, I introduced the open source Shaver View Engine. In this post, I will expand on what Shaver is, what it does (and doesn’t do) and how it does it.

Read the rest of this entry »

Written by andrewlocatelliwoodcock

November 7, 2011 at 13:53

Introducing the Shaver Framework: an Open Source Project for ASP.Net MVC

with 4 comments

After my presentation at the MTUG Dev Day earlier this month, I have been asked a number of times for the source code of the sample custom view engines I used in my talk. The delay in posting the source code has been due to the fact that when I started looking at it, I realized that what I had done, with a bit of refactoring and re-engineering, could be made into quite a useful open source project. Hence the delay!

But finally, I am ready to announce the existence of Shaver, an ASP.Net MVC Open Source Project that allows the extension of the Razor View Engine to allow views to be written in standard Razor syntax but used to produce any type of output you want. Most custom view engines for ASP.Net MVC offer different syntax for writing your views in; Shaver reuses standard Razor syntax but allows you to perform any task you want with the output. Examples included in the project include a logging view engine, a view engine that converts HTML / CSS to PDF and displays the generated PDF instead and a mailer view engine that can produce a mail merge from a standard Razor view.

The possibilities are potentially endless …

In the hope that this will prove useful, I have now released this project under the GNU LGPL on GitHub: Shaver. Please have a look, play around with it, offer any constructive criticism and suggestions and let me know what you think!

Next: in-depth introduction to Shaver

Written by andrewlocatelliwoodcock

October 27, 2011 at 19:40

Unit Testing Session State Dependent Code in ASP.Net MVC

with 2 comments

It can be pretty tricky to unit test code that’s dependent on Session State, a situation I needed to address recently when developing my talk for the MTUG Developer Day, largely because Session State is dependent on having a properly initialized Controller and a Controller, as it is built on top of ASP.Net is not an easy thing to initialize!

The MVCContrib Testhelper can help here though as it has a handy method to … initialize a Controller!

Here’s a sample:

var controller = new XXXController();

            // MVCContrib TestHelper is initializing the Controller for us INCLUDING session state!
            var builder = new TestControllerBuilder();

The InitializeController method performs all the necessary tasks to initialize the Controller including preparing Session State and we can now unit test code that depends on Session State.

Written by andrewlocatelliwoodcock

October 25, 2011 at 20:26