I’ve been a little late to the NuGet bandwagon. Overall I am really happy with the service that NuGet provides. It is not all smooth sailing though and the following are the pain points I have hit:

• Packages aren’t all strong named so our solution can’t be either
• Package dependencies being updated might break other packages that depend on them
• The amount of binding redirects added to config files is not always desirable and don’t always work
• TFS get latest on a solution does not bring down NuGet package changes

My Using WinMerge with TFS post has to be consistently the most viewed post on this site. I have finally been able to get around to posting updated reg files to support VS2012 on both x86 and x64 platforms (see the bottom of that post for the links). These reg files will configure VS2012 to use Winmerge for TFS diff/merge operations (no Visual Studio restart is required).

Enjoy

I really like Microsoft’s Code Contracts. The concept is absolutely great, but I’m starting to wonder if using them is worth it. Here are the pro’s and con’s as I see them.

I’ve been taking the pain today with an issue that provided a lot of misdirection. The setup is a build agent that uses a remote PowerShell session to install a setup package from the build output. The setup package also includes the facility to remote deploy a database to a data tier machine.

It always worked from my local machine and manually from the deploy machine. I never worked from the build workflow.

I have installed the latest SDK that came out this morning and I hit a compilation hurdle straight away.

My solution is starting to get to be a decent size with many third party technologies involved, Code Contracts being just one of them. My website project is failing to compile with an issue raised by the code contracts rewriter.

I have a scenario where a web application is using WIF to manage federated security. The system will get a SAML token from an STS for the authenticated user. The token is only going to contain the NameIdentifier claim (a typical Windows Live token for example). This means that the application itself needs to manage the account information related to an authenticated user.

The application will store the first name, last name and email address of the user. These values will be populated into the IClaimsPrincipal for an existing account using a custom ClaimsAuthenticationManager implementation.

I have been writing unit tests for my classes that use code contracts (Contract.Requires<T>) just like I did with the old style guard clauses basically since code contracts were released. My reasoning for testing them has always been that the unit test code should not make any assumptions about the implementation of the SUT and ideally should have no understanding about how it is implemented. Instead it should just test the behaviour.

If a method that takes a reference type as a parameter and a value must be supplied, then the expectation is that the method will throw an exception if null is provided. I have always believed that this behaviour should be tested regardless of whether this is implemented as a traditional guard clause, a Contract.Requires on the method implementation or a Contract.Requires on the interface or base class.

There is an issue with the Azure 1.6 SDK that I often hit when I run a cloud project. I get around 3-5 debug sessions with my cloud project before Visual Studio starts throwing an Invalid access to memory location error.

This issue seems like it is hitting many other people as well. This is a significant pain point for working with Azure projects and there is currently no suitable workaround or fix that I can find. Sometimes shutting down the emulator and trying again works. Most often however, the IDE needs to be recycled. Having to do this each fifth F5 is a productivity killer.

This post puts together the code posted in the previous two posts (here and here).

The following code is what I am using the spin up the Azure storage emulator, Azure compute emulator and IISExpress so that I can run my system through its integration tests.

The system I am currently working uses the development fabric in the Azure SDK for working with Azure web roles and worker roles. I am also using a local WIF STS site to simulate Azure ACS. This allows me to integrate claims based security into the system without having to actually start using an Azure subscription.

The local STS is running on IISExpress. Like the previous post about running the Azure emulator for integration testing, the STS also needs to be spun up to run the system. The following class provides the wrapper logic for spinning up IISExpress.