ReportGenerator - New release with coverage by test support
Since my last blog post about ReportGenerator a couple of features have been added. In this post I will describe the most important changes.
Since my last blog post about ReportGenerator a couple of features have been added. In this post I will describe the most important changes.
Some time ago somebody on Stackoverflow asked how to integrate OpenCover results into CruiseControl .NET. After being asked again, I decided to write a tutorial to show how CC.NET has to be configured.
I created a demo project that uses NUnit, OpenCover and ReportGenerator to generate HTML coverage reports that are integrated into CC.NET.
After setting up Windows 8 and SQL Server 2012 my ASP.NET applications were not able to access my SQL databases.
Whenever I have to setup a PC in the future, I don't want to waste my time (again) to figure out how I have to configure the users correctly. Here is what I did:
ReportGenerator 1.3.0.0 has just been published. The new release offers some new features which I want do describe in this post.
Recently I was asked to implement a reusable filtering mechanism in an ASP.NET MVC application. To be more concrete: A website shows a grid containing arbitrary data. The user should be able to enter a filter for each grid column.
The filters should be generated based on the type of the displayed objects. With that functionality, it is possible to filter every grid in the application with very little effort. Moreover I added a possibility to add custom search criteria.
I'm currently working on an application which uses reflection to create a generic UI. Therefore I was interested in the performance impact of reflection. In this post I will do a comparison between the various possibilities to access a property.
This week Daniel Lang published an interesting article about unnecessary overhead in simple applications.
In a nutshell he proposes an architecture called "Poor-mans CQRS". In his sample he uses an ASP.NET MVC application. The controllers retrieve their required data directly from the database (Query), and updates are performed in service layer (Command).
In this post I will provide a (simple) application, which is based on the Entity Framework. It shows the principle and explains how unit tests can be written without querying a real database.
In this post I will do a performance comparison of the most popular IoC containers.
Of course performance is not the only criteria when choosing a container for a project. Perhaps you need features like interception, then not all containers are suited. But if the container is "only" used for wiring up dependencies, why not choose the fastest one?