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.
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.
I posted previously about manually spinning up Azure storage emulator in the development fabric so that it can be used with integration tests. Ever since then I have been using a vastly updated version of the code I previously published.
This updated one might be helpful for others to leverage as well. This version allows for starting and stopping both the storage emulator and the compute emulator. It makes its best attempt at automatically finding the Azure project service directory and the service configuration for the current build configuration. If this does not work for your scenario, then you can also manually provide this information.
One of the TFS instances that I am responsible for started failing to process its Analysis Services cube a few days ago. The nature of the environment is that I can only do a reboot after hours. I also wanted to try to find out what was wrong before resorting to a reboot so that we could try to fix the problem rather than just doing a band-aid.
The topology of the TFS deployment is the following:
- TFS App Tier – also hosts SSRS
- TFS Data Tier – SQL Server, SSIS and SSAS
- TFS SharePoint Tier
- TFS Controllers
- TFS Build Environment
- CI Host Platform
[Full Analysis Database Sync]: [Full Analysis Database Sync]: