MiniProfiler v3.0.10-beta1 Released

I have been a big fan of MiniProfiler since soon after its initial release, so soon after I joined Stack Exchange (2013-10), I made an effort to try to get involved with the development work. Lots of work had been completed already by Jarrod Dixon, Marc Gravell, Matt Jibson, Sam Saffron, Nick Craver and the other members of the team to get MiniProfiler to version 3, and this has been in use for a number of months already on the Stack Exchange sites (including Stack Overflow). A few items remained on the ToDo list before the new version could be released on nuget, and I volunteered to work on these. All of the remaining items have now been completed and a few minutes ago I pushed the new 3.0.10-beta release up to nuget.org.

Note: if you are going to install the pre-release beta nugets, be sure to include “-pre” in your command: PM> Install-Package MiniProfiler -Pre

Release Notes:

  • First public nuget release of v3.0
  • Includes new nuget package updates:
  • CustomTiming replaces SqlTiming as the general timing storage. Sql is now just one case. More adaptable for different timing types.
  • Lots of bug fixing, performance enhancements
  • Move from the old location to here.
  • SqlServerStorage is rewritten to use different tables, corresponding to new CustomTiming approach. If you used SqlServerStorage in v2.0 this is a breaking change. In this case be sure to see the newtable creation script
  • Add MultiStorageProvider as new option for being able to designate multiple storage locations.
    • Will store in all listed, retrieve from the first possible location where there is a match
    • Implements IStorage so it can be set for the session using MiniProfiler.Settings.Storage, or for the individual request.
    • Set MiniProfiler.Current.Storage to any IStorage (including MultiStorageProvider) to customize the storage for any single request (example)
  • New nuget for Entity Framework 6. Initialize in with MiniProfilerEF6.Initialize();
  • Updated for newest versions of SqlCe and SqlLite

I also just updated the MiniProfiler.com site to include up to date information (based on the new release) on nugets and basic usage, and changed up the UI a tiny bit (now using Bootstrap).

Issues and Pull Requests are welcome on GitHub, and any feedback is also welcome on the community site.

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.

Force WebAPI to return JSON by Default for Html GET Requests

Currently, the default response type of for Web API requests is XML. By the time it comes out of beta, it will be the default (source - this is mentioned by Hanselman towards the end of the post). However, if you want to activate this right now, how should you do it?

Two steps:

  1. Set a JSON formatter as the first Formatter in the Web API Config Formatters collection
  2. Set “text/html” as an accepted media type for this formatter

WebAPI includes a JSON Serializer by default: DataContractJsonSerializer. However, no one wants to use it, and for good reason: lots of issues with different types, slow performance, bad date formatting and more.

Thankfully, WebAPI allows you to switch customize the data formatters used for different content types. Bloggers have recommended a number of different approaches. What seems to be the most promising is Henrik Nielsen’s JsonNetFormatter (using Json.NET to handle the JSON serialization) combined with a fix for a DateTime serialization issue (Hanselman also implies that this will be the default in post-beta WebAPI).

After you add the code for the JsonNetFormatter, you can set this up as the default Json data formatter by doing the following:

protected void Application_Start()
{
    ...

    JsonSerializerSettings serializerSettings = new JsonSerializerSettings();
    serializerSettings.Converters.Add(new IsoDateTimeConverter());
    GlobalConfiguration.Configuration.Formatters.Insert(0, new JsonNetFormatter(serializerSettings));

    ...
}

Once you have done this, any request that comes in to the API that asks for json (setting a header to accept content of type application/json, utilizing the facility in WebAPI for content negotiation) will receive Json content formatter using the JsonNetFormatter class. However, if you want to just test this out in your browser, you will still get XML content. This is because a plan request from your browser is for type text/html, which translates to xml in the Web API universe. Though the Json will be returned automatically if you explicitly request json content (or if you use a function that requests this content type, like the $.ajax function in jQuery), if you want to test out the json in your browser, you will be out of luck using the standard configuration.

To get around this, you need to set the JsonNetFormatter to support the “text/html” media type. This will allow it to respond to requests made from the browser (and since the JsonNetFormatter is now the first Formatter in the Formatters collection, it will be used by default). You can do this as follows:

protected void Application_Start()
{
    ...

    JsonSerializerSettings serializerSettings = new JsonSerializerSettings();
    serializerSettings.Converters.Add(new IsoDateTimeConverter());
    var jsonFormatter = new JsonNetFormatter(serializerSettings);
    jsonFormatter.SupportedMediaTypes.Add(new MediaTypeHeaderValue("text/html"));
    GlobalConfiguration.Configuration.Formatters.Insert(0, jsonFormatter);

    ...
}

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.

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).