Could not load type ‘System.Web.Razor.Parser.SyntaxTree.CodeSpan’ from assembly ‘System.Web.Razor

I am working with an ASP.net MVC4 project with WebAPI, and upgraded/installed a number of nuget packages (and stupidly did not test after each one). When the dust settled, I tried to load an API page in my browser and got the following error message:

“Could not load type ‘System.Web.Razor.Parser.SyntaxTree.CodeSpan’ from assembly ‘System.Web.Razor”

Eventually, I was able to resolve the error by removing the following from my web.config and app.config files:

<runtime>
  <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
    <!-- Begin Remove -->
    <dependentAssembly>
      <assemblyIdentity name="System.Web.Razor" publicKeyToken="31bf3856ad364e35" culture="neutral" />
      <bindingRedirect oldVersion="0.0.0.0-2.0.0.0" newVersion="2.0.0.0" />
    </dependentAssembly>
    <!-- End Remove -->
  </assemblyBinding>
</runtime>

I would guess that one of the packages that I installed added this reference, which had a conflict with a different version of the same assembly in the GAC. In any event, it fixed the error (and did not cause any apparent new errors). Posting in case it may help you out with a similar error.

Error Loading MVC 3 Project after MVC 4 is Installed or in VS 2011

Since installing the ASP.net MVC 4 Beta, it has happened to me a few times that MVC 3 websites will not load when the solution is loaded into VS 2010 (I have also read about this happening with VS 2011).

You can fix this by doing the following:

  1. In the Solution Explorer, right click on the project that wont load and click on “Edit [ProjectName].csproj”. This will open up the project definition file in VS. You can also edit this manually using your favorite text editor, opening the file through Windows Exporer.
  2. Find the line in the file that starts with ProjectTypeGuids and remove the entry “{E53F8FEA-EAE0-44A6-8774-FFD645390401}” from the list (this is code that tells Visual Studio that it is an MVC 3 project – for some reason, including this in the project file after installing MVC 4 messes things up).
  3. Save the .csproj. file and [Reload] the project through the Right Click menu in Solution Explorer.

The project should now load properly (if the MVC project has been the startup project for the solution, you may have to reset this as well).

Fixing the “circular file references are not allowed” Error in ASP.net

If you get the “circular file references are not allowed” error in an ASP.net Website Project and you do not have any controls that have any obvious circular references, what does the error mean and how do you fix it?

See this blog post from Siderite Zackwehdex as well as this MSDN forum post: by default, in a Website Project, ASP.net compiles one dll per folder in an ASP.net project. So if you have the following setup:

/folder1/Control1.ascx > References Control2
/folder2/Control2.ascx > References Control3
/folder1/Control3.ascx

This means that the folder1 dll will reference the folder2 dll which will again reference the folder1 dll, causing a “circular file reference”.

Even if there is not a direct path between the controls, looping into a circular reference, but there is a direct path connecting the circular reference through other controls in the same directories, it can throw the circular file references error. For example:

/folder1/Control1.ascx > References /folder2/Control2a.ascx
/folder2/Control2b.ascx > References /folder1/Control3.ascx
/folder1/Control3.ascx

Ways to fix it:

  1. Rearrange the layout of your controls (or masterpages) to remove the circular references (normally this will mean moving one control to another folder – in the example above, move control2 to folder1). This is the preferred solution.
  2. Use batch=”false” in the compilation tag of the web.config file. This will cause a new dll to be created for each control/page in the site. This should fix the error but is really lousy for performance, so it should be avoided (especially on production sites).

(This has happened to me a couple of times already, so posting it here as a reminder to myself for the next time).

Repeater Failure and Disappearance on Row 28

I was working on an ASP.net application (1.1) the other day, changing the UI display of a page. This page basically consisted of a Repeater being populated with data from the DB, and binding javascript actions and styling info to the different rows to be output (each overall it was producing a Table, and each item was a TableRow). Although the look-and-feel was going to be changing, as well as the manner in which the data was to be retrieved, the actual data set up and binding was to remain the same as it had been. Piece of cake, right?

The programming was straight-forward enough. When I first tested the feature on a few records, it worked fine. However, when I tested it on more records, it didn’t work. And when I say that it didn’t work, I am not saying that I got back some ugly .Net exception. I mean that the HTML output by the server was completely devoid of the Repeater element. It was as if it just did not exist. Somehow, when I tried the load the page with a large number of records,¬† some weired thing happened in IIS that just completely abandoned the rendering of the Repeater element without even providing an error message. Completely weird.

After a couple of hours of debugging, I was able to determine that the error was not related to any specific data item. Rather, it always happened when outputting the 28th DataItem in the Repeater. 27 worked fine. 28 killed it. Racking my brain (and Google), I couldn’t find any reason why this would be happening. This exact same repeater worked fine on other pages, on the live site. There was no reason I could think of why this type of failure would happen, and why it would happen here.

My coworker SeanS suggested that perhaps this was related to my dev environment, perhaps some faulty memory or something like that. There was nothing else to go on and this did explain what was going on (and I knew that the feature worked for <28 rows), so I proceeded with development. And lo and behold, when I uploaded my changes to the staging site yesterday, it worked with any number of rows without any hitch-up.

Moral of the story: weird things happen on web servers and on dev machines. Not every error that you get is related to code (especially if the error is reported by the absence of output rather than an exception). If something like this is happening to you (and it is not reproducible on other platforms), it may very well be environment-related. Test this out before wasting more time and energy trying to sort it out through the code.

Declaring Custom Events in User Controls

I am constantly needing to search my code to find the exact syntax for how to do this, so for future reference (for myself and anyone else who finds this useful), to declare and call an event from a custom user control or inherited control:

public class CustomEventArgs : EventArgs {
  public CustomEventArgs(int propValue) {
    _propValue = propValue;
  }

  private int _propValue;
  public int PropValue {
    get { return _propValue; }
  }
}

public delegate void CustomEventHandler(object sender, CustomEventArgs e);
public event CustomEventHandler CustomEvent;

public void Function() {
  // Do Stuff
  if (CustomEvent != null) {
    CustomEventArgs e = new CustomEventArgs(x);
    CustomEvent(this, e);
  }
}

If you don’t need a CustomEventArgs class, just use the built-in EventArgs instead.

Porting .Net Assemblies to Mono using MoMA

For those who have not heard about it, Mono is a platform designed to allow porting of .Net-based applications to nearly every computing platform available (including Linux and Mac). It is open-source (sponsored by Novell) and is an essential tool for any developer who wishes to run .Net code on a non-Windows OS.

I am right now in the middle of a Desktop project being written with VS.net 2005, C# and Windows Forms technology. The powers-that-be (ie: the clients) have inquired to the feasibility of potentially porting over the code to Mac or Linux. My answer has been that if it is possible, we will have to use Mono to do it, but I cannot say anything more about its compatibility until more of the programming work is completed.

The process of porting over a completed .Net Assembly to Mono just got a bit easier. A tool called MoMA (Mono Migration Analyzer) has been released (written by Jonathan Pobst) that will do the following: given any .Net assembly (.dll or .exe file) it will go through the file and report back any potential issues that may arise using the assembly with Mono (most likely a .Net 2.0 feature that has not yet been implemented, or a calls to Win32 APIs that are not documented in the .Net API). Definitely a very helpful tool in debugging a .Net aseembly that refuses to compile in Mono.

Miguel de Icaza gives a more thorough step-by-step guide and review of his experiences using MoMA (though it doesn’t seem to be too complicated).