.Net Development, Azure, DevOps, Ideas and Life...

Introduction Instrumentation, the process of auditing and logging in your applications, is a vital part of any enterprise solution. When you are developing applications with Service Level Agreements and specific Auditing requirements, logging is a big deal. Add in the complexity of the decoupled nature of the cloud with Service Orientated Architecture, piecing together a clear view of a business process from end to end can be a challenge. Microsoft has recently released the Semantic Logging Application Block ( SLAB ) to the enterprise library. This article will form the first part of a mini-series, detailing the benefits, pitfalls and examples of how to make use of it in your enterprise. Although new to the Enterprise Library, Semantic logging is not a new concept. It has been adopted for years under different names such as "structured logging", "strongly typed logging" and "schematised logging" to name a few. What is it? SLAB inherits event

CodeProject Azure Diagnostics is extremely powerful when setup correctly and being fully utilised. That said, quite a bit of burden is still left with us developers to pull out the juicy bits and present that as information that can potentially be consumed and mean something to the other, often not quite so technical, stake holders. Maybe more importantly from a developer standpoint is being able to fault find a collection of services when something does go wrong or is about to go wrong.  A useful tool which I have used with Windows Azure and comes in very handy for diagnosing and monitoring is  Stackify . It is online which immediately gets a thumbs up from me but the good part is that it supports all the Azure Diagnostics in near to  real time . You can see below that it is showing some useful stats from some Web and Worker roles.  There are a number of different views that can be selected such as the one shown below. Going beyond the stats which

CodeProject Introduction In part 1 of this mini-series, we will develop a trivial business logic layer from scratch with a TDD approach with the goal of achieving the following: Better code quality through Red, Green, Refactor Documentation that grows as we develop and remains up to date Automatic regression test harness This will primarily involve creating unit tests first , having them fail , making them pass and then refactoring the code to be of better quality and then re-running the tests. When using tools such as resharper  to aid in refactoring code , having the tests in place right from the beginning really gives you peace of mind that you haven't broken anything. It also helps the thought processes while designing and developing an application or feature to be more targeted. We will further develop the application in part 2 to add an MVC4 web client and continue the TDD story...  Some Background Test First  or Test Driven development is a valuabl