Skip to content


Could not load file or assembly FSharp.Core with .net 4.5 / NDjango / Win8

The Problem

With today’s release of the RTM versions of Win8 and Visual Studio 2012 I, like many others no doubt, have formatted one of my machines, thrown the new bits on, and kicked the tyres with some code. Unfortunately, when I tried Nancy, everything build just fine, but running any tests involving NDjango (F# based) blew up with:

Could not load file or assembly ‘FSharp.Core, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a’ or one of its dependencies. The system cannot find the file specified.

Or:

Could not load file or assembly ‘FSharp.Core, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a’ or one of its dependencies. The system cannot find the file specified.

All this works perfectly fine with .net 4, and .net 4.5 is supposed to be backwards compatible, but in this case it seems not. I haven’t done much digging, but if a strongly named assembly changes version between .net 4 and .net 4.5 I would expect an assembly binding to be in place to stop this kind of thing from happening – it’s possible that NDjango is doing something odd, but still, if it works in 4, it should work in 4.5.

This may or may not be an issue on Win7 if you’ve had .net 4 installed previously.

The Solution

Luckily, it’s very simple to add your own binding redirects to get things up and running again. These can either go in the app.config/web.config of your application, or you can put it in the machine.config – I wouldn’t recommend the latter though, as you may end up with an “it works on my machine” situation a few months down the line.

Either way, this is the section you need to add, it maps both 2.0.0.0 and 4.0.0.0 to the version that ships with .net 4.5/Win8 :

<assemblyBinding  xmlns="urn:schemas-microsoft-com:asm.v1">
    <dependentAssembly>
        <assemblyIdentity name="FSharp.Core" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
        <bindingRedirect oldVersion="2.0.0.0" newVersion="4.3.0.0"/>
        <bindingRedirect oldVersion="4.0.0.0" newVersion="4.3.0.0"/>
    </dependentAssembly>
</assemblyBinding>

A simple solution, and maybe this will just affect me, but this blog post will at least stop me from pulling my own hair out if this happens again :-)

Share:
  • Twitter
  • DotNetKicks
  • DotNetShoutout
  • Google Bookmarks
  • Digg
  • del.icio.us
  • Live
  • Technorati
  • StumbleUpon
  • email
  • Netvibes
  • Ping.fm
  • Print
  • Reddit

Technorati Tags: , ,

Posted in .Net, fsharp, Nancy.

Tagged with , , .


Nancy v0.8.0 – Best Laid Plans..

TL;DR

Nancy v0.8.0 is out, loads of cool new features such as static content (so you *finally* don’t have to do it yourself :-P ), basic authentication support, and CSRF protection, and enhancements to things like error handling (with fancy pants error pages) and the test framework. We also have a fantastic new logo by Nicolas Garfinkiel (codetothepeople.blogspot.com), and a new website – so go check out the Nancy site now :-)

The plan..

Once v0.7.1 was out of the way the plan was simple – work on diagnostics, hopefully interfacing with the guys from Glimpse, and get v0.8.0 – the “diagnostics release” out within 6 weeks or so. But things didn’t go entirely to plan…

A very nice problem to have..

We knew Nancy was getting a bit of a following, but we didn’t anticipate the level, and the quality, of the community contributions. We received lots of feedback, lots of great suggestions, and lots and lots of pull requests – before we knew it v0.8.0 was already looking pretty feature rich, without the diagnostics work we intended to be the core part of it, and time was tick tick ticking by. So, after a certain Mark Rendle started referring to this release as our “Duke Nukem Forever” release, we decided people had waiting long enough for an update and we “re-scoped” v0.8.0 so we could release the growing list of improvements sooner rather than later.

Taking a look at a GitHub comparison it shows v0.8.0 consisting of:

  • 186 commits
  • 226 files changed / updated
  • 19 different contributors
So 19 different people have contributed code to this release which, to me, is an amazing figure for an OSS project that’s not only relatively young, but also built using .net, which is frequently “bashed” by certain people for its alleged lack of community and its apparent ”do what MS says to do”, sheep like mentality.

So, what *is* in v0.8.0?

You can see the commits that went into v0.8.0 in the GitHub comparison, or take a look at the issue list for a list of features / bug fixes, but some of the highlights are:

  •  Static content conventions – now static content is supported out of the box with pluggable conventions for which files are server from where.
  • CSRF protection – currently only supported in Razor, Spark and SSVE, but it’s now possible to validate  ”tokens” (with or without a timeout) to protect your site against CSRF vulnerabilities. There’s a sample of this in the main ASPNet demo project.
  • The view cache should now be disabled in debug mode properly (yay!)
  • A new exception handling pipeline and built in error pages.
  • Basic authentication (as a new Nuget)
  • Protocol Buffers de/serialization support (as a new Nuget)
  • An awesome new logo (see below)
Plus plenty of other bug fixes, tweaks and behind the scenes changes.

Logo and website

Thanks to the efforts of Nicolas Garfinkiel (codetothepeople.blogspot.com) Nancy now has an awesome new logo – many thanks to Nicolas for the speed he put this together, and for putting up with Andreas and myself nitpicking so much ;-) You can see the new logo in “action” in the updated favicon, and on our newly launched Nancy site – go check it out!

Please note that we did have a redirect on that site, so if you get redirected to github you might have to press ctrl+enter (seems to work in Chrome) or clear your cache or restart your browser or something .. sorry :-)

Thanks

So, a big thank you to everyone who contributed to this release – comments/suggestions, bug reports, fixes, features and even just giving kudos on Twitter – it’s all very much appreciated.

Now.. onwards and upwards to v0.9.0!

P.S. Andreas and I have recently recorded a Herding Code episode – so keep an eye (or ear) out for that.

Share:
  • Twitter
  • DotNetKicks
  • DotNetShoutout
  • Google Bookmarks
  • Digg
  • del.icio.us
  • Live
  • Technorati
  • StumbleUpon
  • email
  • Netvibes
  • Ping.fm
  • Print
  • Reddit

Technorati Tags: , ,

Posted in .Net, Nancy.

Tagged with , , .


Debugging xUnit Tests Using MonoDevelop

Introduction

After several months of neglect, we are currently working on getting the Nancy project ship shape on Mono. We’ve gotten to the point now where everything builds and runs just fine, but we have a few tests that fail when running on Linux/Mono. The failures we are seeing are obviously bugs in the tests/stubs/mocks themselves, and we need to debug them to see exactly what’s going on. MonoDevelop has some decent test runner features, but they appear to be heavily tied to NUnit which is a problem if you happen to use xUnit :-)

Debugging With xUnit

Luckily the solution is relatively simple, if a little clunky:

  1. Download the latest xUnit release and unzip it somewhere.
  2. Set whatever breakpoint you need in MonoDevelop and build the test project (in debug mode, obviously).
  3. In MonoDevelop, go to Run, Debug Application, browse to where you extracted the ZIP from step 1 and choose the appropriate xunit.gui.*.exe depending on your target framework/architecture (xunit.gui.clr4.exe in our case).
  4. The gui xUnit runner will popup – click Assembly, Open, browse to the output of your test project, select the assembly and press OK.
  5. Click Run All in the bottom left.

The runner will run the tests and you should break out into MonoDevelop whenever you hit a breakpoint.

Pretty simple, if a bit of a ballache – but hey, you shouldn’t need to debug your tests very often anyway :-)

Share:
  • Twitter
  • DotNetKicks
  • DotNetShoutout
  • Google Bookmarks
  • Digg
  • del.icio.us
  • Live
  • Technorati
  • StumbleUpon
  • email
  • Netvibes
  • Ping.fm
  • Print
  • Reddit

Technorati Tags: , , , , ,

Posted in .Net, CSharp, Nancy, Software, Uncategorized.

Tagged with , , , , , .


Switching from Cygwin to MSysGit – Git Thinks Everything Has Been Modified :-(

Introduction

I’ve been dabbling with git lately, contributing to the Nancy project, and I’ve been happily working away using Cygwin, which I already had installed, and all was fine and dandy. Things went slightly awry, however, when I decided to give MSysGit a whirl. Typing “git status” on my (unmodified) repository, that I’d previously used with Cygwin, showed every single file as modified.. argh!

Faking FileModes

A quick “git diff” showed this output for every file:

old mode 100755
new mode 100644

A brief Google later and it turns out that MSysGit “fakes” filemodes (unix permissions – the 755/644 part of the log above), whereas Cygwin, which is a more “complete” Linux implementation on Windows, does them “properly”. Now, by default, git tracks the filemode and considers it a change whenever it’s modified, so the “fake” modes coming back from MSysGit were making everything appear modified.

Solution

Luckily, the solution is very simple – tell git to stop tracking filemodes! I set this as a global option, but also had to set it on the repository too as it has a default value set in there. The following two commands sorted it out:

git config --global core.filemode false
git config core.filemode false

Conclusion

A simple fix to a, potentially, obscure problem; but I think if you’re using msysgit to work on non-Windows projects, that may have filemodes set for executable scripts, then this workaround may be required too. Apparently MSysGit does attempt to fake the filemode based on file extension, so things that *look* like they should be executable are faked to have +x, but it’s not going to be perfect.

Share:
  • Twitter
  • DotNetKicks
  • DotNetShoutout
  • Google Bookmarks
  • Digg
  • del.icio.us
  • Live
  • Technorati
  • StumbleUpon
  • email
  • Netvibes
  • Ping.fm
  • Print
  • Reddit

Technorati Tags: , ,

Posted in Misc, Rambling.

Tagged with , , .


Quick Add Reference Extension for Visual Studio 2010

Introduction

I mentioned this on Twitter last week, but completely failed to find it again today, so thought it was worth blogging for future reference Smile 

As I have blogged about in the past, the Add Reference dialog in Visual Studio is still pretty terrible in VS2010. Various extensions have made it more bearable by providing search support and other enhancements, but now you can avoid it completely (most of the time) with an excellent extension from Clarius Consulting:

http://visualstudiogallery.msdn.microsoft.com/en-us/dc06b54c-b6c4-4cf5-8203-a09c6979e881

Anyone that’s used ReSharper will instantly recognise the approach – just hit Ctrl+. for the VS2010 Smart Tag on something you don’t currently have referenced, and voila – an option to automatically add the reference and the corresponding using statement:

quickaddreference

Simple and effective – I haven’t had any problems with it since I installed it last week – go and give it a whirl Smile

Share:
  • Twitter
  • DotNetKicks
  • DotNetShoutout
  • Google Bookmarks
  • Digg
  • del.icio.us
  • Live
  • Technorati
  • StumbleUpon
  • email
  • Netvibes
  • Ping.fm
  • Print
  • Reddit

Technorati Tags: , , ,

Posted in .Net, Misc, Software.

Tagged with , , , .