Hey all, now that I’m doing primarily Rails work (we’re hiring in Seattle by the way, email), I’ve just started a new personal blog at aaron-jensen.com. I’ll probably still post here occasionally when dabbling in the .NET world, but most of my thoughts will be on the new blog and twitter. Thanks!

Some time ago, I handed off maintenance of MSpec to Alexander Groß. He has continued to add features, fix bugs, tweak and fine tune various aspects of MSpec. I’m forever grateful for his efforts.

Over the past few days, he pushed several changes, some breaking, so I wanted to call them out here. Below his his note on the machine user group.

Hi all,

I’ve pushed some changes to MSpec over the last couple of days and wanted to let you know what changed:

- Runners for x86/AnyCPU, .NET 3.5 and 4.0 in one zip
Runners for all these architectures/CLRs are now in one package.
mspec.exe -> AnyCPU, CLR 2.0
mspec-clr4.exe -> AnyCPU, CLR 4.0
mspec-x86.exe -> x86, CLR 2.0
mspec-x86c-clr4.exe -> x86, CLR 4.0

This is possibly a breaking change as mspec.exe was x86 traditionally. Most unit testing frameworks (xUnit, NUnit) follow the same convention.

- Machine.Specifications.dll is not strong-named by default
We had to strong name our framework assembly to support some very specific scenarios.
https://github.com/machine/machine.specifications/issues#issue/34/comment/761201

We removed the strong name for our default build because SNs cause more problems than they solve. You can always build with signing turned on by running the build as follows:
build.cmd SIGN_ASSEMBLY=true

Builds started from inside Visual Studio will not be signed by default. There are two build configurations on our TeamCity server, one for the unsigned and one for the signed configuration:
teamcity.codebetter.com/project.html?projectId=project27

There’s an extra NuGet package for the signed build, see below.

- Assembly versioning
From now on releases will be versioned correctly. (We re-released 0.3.0.0 over the last couple of months.) The version number is generated by TeamCity. Builds on your local machine will compile as 0.4.0.0. You can override this:
build.cmd VERSION=0.4.3.2

For such a build, the zip and NuGet packages will have a “Testing” suffix, such that you can easily test these: Install-Package Machine.Specifications-Testing

build.cmd VERSION=0.4.3.2 SIGN_ASSEMBLY=true creates a signed Machine.Specifications.dll with version number 0.4.3.2.

- A better NuGet package
I updated the NuGet package for MSpec. That is, we have two packages: Machine.Specifications and Machine.Specifications-Signed. You correctly guessed what’s different The package contains the framework DLL (inside /lib) as well as the runners (in /tools).

The TestDriven.Net

- Versioning and the ReSharper runner
You will very likely encounter problems if you update Machine.Specifications (0.4.x) in your project but not the ReSharper runner (still 0.3.0.0, strong-named). The result is gray icons next to the specification nodes in the Unit Test Session window.

The problem can be solved easily by updating the ReSharper runner. The updated ReSharper runners now contains some logic to check if the runner is compatible the project and will display an error message if not.

Please let me know if you encounter any problems with the new builds!

Alex

You can check out the readme on the github project for more info and download links. Enjoy!

Recently I wanted to add a very simple sanity check to our sites’ build. Typically the Integration/Selenium RC tests would handle this sort of thing, but I wanted something light enough to go in continuous integration build so we would be protected from simple dll version mishaps, configuration errors, container issues, whatever. There’s probably plenty of ways to do this, and if any of you know of a better way, please let me know. In order to do it, I modified the Cassini source to run as more of a daemon, I created a simple rakefile to launch it and I use curl to verify a test url. For my test Url I simply made a Diagnostics Controller with an Ok action that returns a ContentResponse with “OK”. Pretty simple. If you need something like this, give it a shot and let me know what you think.

Download

Source

Update: Here’s a direct link to download the latest build of MSpec.

Many thanks again to Alexander Groß for adding packaging to MSpec. You can now download builds from here without having to build it yourself! Just grab the Artifact from the latest build.

Thankfully, the community has created a number of very helpful blog posts about MSpec. Unfortunately, I’ve been quite bad at aggregating them into a single authoritative source and documenting the few but somewhat obscure APIs and tools that make up MSpec. It is on my list of things to do but time has been rather… tight. I’d love to get it up sooner than later, as MSpec is getting more and more eyes on it and I want to make things as smooth as possible for new users.

That’s where this plea comes in, I’m looking for someone to help put together some documentation in one place, probably the github README.markdown. I obviously don’t have anything to offer other than fame and fortune (minus the fortune and probably the fame). Rest assured, though, that myself and the rest of the community (like kreiggers) would be forever grateful.

I’d be happy to edit and keep up to date the documentation once created so this wouldn’t be an ongoing effort, but I could use some help getting started. Ping me on twitter if you’re interested and we can brainstorm a bit. Thanks in advance and sorry for the spam.