Transforming web.config in TFS builds

XDT transforms (mostly known as web.config transformations) are most useful to perform transformations on your web.config at deploy time (for more details about web.config transformations you can take a peek at http://msdn.microsoft.com/en-us/library/dd465326.aspx). Say that you’re publishing a web application in the project configuration “Release”. If you have a “web.Release.config” file in your application, that file contains the transformation to be applied over the web.config. However, if you are using TFS builds to create the deployable outputs, you might find yourself in unexplored territory, because your XDT’s will not be ran as when you explicitly publish from within Visual Studio.
Microsoft might have inadvertedly shed some light on this subject, as they have recently made available a prerelease of an API to perform these XDT transformations which is available through NuGet here:  https://nuget.org/packages/Microsoft.Web.Xdt.
Knowing this, I’ve decided to explore this new API and put it to good use. I've created a CodeActivity to use this API and integrate the XDT transformations in my build process. Another alternative (I was previously using) is to rely on an external tool to do the transformations for you and invoke that tool from within your build process (see the Config Transformation Tool here: http://ctt.codeplex.com ).

So here’s a code activity to do just that: run XDT on your web.config depending on the project configuration being built:

Submit this story to DotNetKicks Shout it


Premature optimization

First of all, happy New Year!
Now, on the first post of the year, I would like to quote the great Donald Knuth: "We should forget about small efficiencies, say, about 97% of the time: Premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%. A good programmer will not be lulled into complacency by such reasoning, he will be wise to look carefully at the critical code; but only after that code has been identified."

I've been defending this for a long time, but I keep stumbling upon developers that disregard this rule of thumb. When faced with performance issues most tend to use an empirical approach: read the source code and attempt to make informed guesses on what may be the critical code. Most forget about code profilers that can accurately identify the critical code. I believe this is not only their fault, but also a fault of the education system, that failed to instruct and emphasize on the relevance of such tools.

Here's another quote (from Continuous Delivery): "Don't guess; measure". My experience tells me, that, most of the times, our informed guesses are not the main culprit of our performance issues. So, the best approach is to clearly identify the culprits and deal with them. What's the point in spending time solving an issue when there's another issued that on itself may represent a 50% improvement? We rarely have the time to perfect our code until we deem it as good and fast as we'ld like, so in such situations a programmer should be pragmatic (which I believe to be one of the most relevant qualities in programmers. By the way, if you haven't read The Pragmatic Programmer yet, it's time to start thinking about it).

Happy coding in 2013!

Submit this story to DotNetKicks Shout it


Webinar on Software Best Practices and ROI

I've recently seen a webinar that I would like to share with you. It concerns software best practices and their impact on companies, mainly focusing on these practices ROI. If you're trying to understand if best practices really work, or struggling to convince anyone of this, than this presentation just might be what you're looking for. I would like to highlight not only the content of the presentation, but also the Q&A session at the end of the talk.
The presenter is Steve McConnell, author for several renowned books. I've recently read his "Software Estimation: Demystifying the Black Art" and strongly recommend it!

I've asked for permission to publish the link for this webinar and Steve has given his blessing, so here's the link to a recording of Steve's talk.

Submit this story to DotNetKicks Shout it


Customizing your application resources

Picture this: You have an asp.net application in which you support multiple languages through the use of resources (global and local resources) and depend on the .NET framework to do all the hard work of loading the correct resources depending on the current UI culture. All is well until you have a requirement of customizing a handful of resources (either per user, per customer, or any other criteria you may think of).
Anyone who has enough knowledge of the .NET framework, tells you right away that you can create your own resource provider and take control of all the aforementioned mechanism. You can find several articles online, including MSDN articles with a detailed explanation of how to provide your own resource provider (here's an interesting article about it).
There are several online resources supplying examples of resource providers that load resources from the database and other similar approaches. However in this specific situation we would like to preserve the default provider behaviour and override only when the target resource has been customized. It seems pretty easy, right? We override the default provider, find if the target resource has been customized, if so, return the new value, otherwise, call the base class implementation, right?
Wrong! You can't extend it because the GlobalResXResourceProvider class (default provider responsible for resolving global resources) is internal, the LocalResXResourceProvider class (default provider responsible for resolving local resources) is internal and the ResXResourceProviderFactory class (provider factory responsible for creating instances of the global and local resource providers) is... guess what... internal! So, it seems Microsoft did not want us to extend this classes...
Right now we could opt to rewrite this providers ourselves OR we could avoid that hard work and opt to create our resource providers as proxies/surrogates (see the design pattern here) that end up invoking the default providers. The only question is how do we initialize these default providers if they are internal... It's not pretty, but I can only think of reflection. In this case, instead of accessing both default providers through reflection I chose to minimize the points of failure by creating only the default resource provider factory through reflection and calling it's public interface to retrieve the default provider instances.
So here's the how our brand new resource provider factory looks like:

Plain simple, just create our brand new customizable resource providers and pass them a "fallback" provider, which will be used to resolve any resource that hasn't been customized. Our new resource providers just have to determine if they should resolve the resource or if they should use the "fallback" provider (which will be the default provider). Something like this:

Nice and easy! Accessing internal stuff in the framework is obviously something to be avoided, but I think we're pretty safe here. Resource providers have been around for a while and I don't expect Microsoft to remove this class sooner.

Submit this story to DotNetKicks Shout it


Bug Hunting with NDepend

Here's another post about NDepend (one of my favorite tools of the trade)! I've recently installed the new NDepend v4 and here's how I've used it for the first time.
I was going through the logs of the asp.net application I'm developing and found reasons to believe that somewhere in the application an object was being written on the viewstate that wouldn't serialize as supposed and throw an exception.
Now, how do we find and fix this bug easily? Surely we could attempt to find in the solution for all uses of the Viewstate and reading that code, but that would be too much code to read, so I've decided to use NDepend to aid me.
So here's what I've though:
- most of the times we use the viewstate in this application is through a property on a page or user control;
- if it's a serialization error, we can ignore properties whose type is a primitive type as we're likely dealing with a class defined in our application;

Here's how I've done it:

From here I only had 3 source code locations to investigate! Much easier than going through the entire application, isn't it?

The ability to query your code (and now in a syntax much alike the linq queries I write day after day) is something very powerful, and every once in a while we might find a new way of use this power!

Submit this story to DotNetKicks Shout it



I think I can say that I know most of the relevant development tools related with the .NET world, so it's obviously not every day that I stumble upon a new tool worth of notice. But today (or rather tonight) was one of those days (or nights). Even more relevant is the fact that this one is free (at least for know, while its considered a beta version).
I'm talking about NCrunch (http://www.ncrunch.net/). It's a tool targeted for developers using Visual Studio and doing TDD. It aims to decrease the amount of time we loose compiling and runing our unit tests, by not requiring us to do it at all! That is, it compiles and runs our tests in background automatically. Even before we save the file with the unit tests source code!
I'm not going to write a full review, but I dare you to use a handful of minutes looking at the video presented in the NCrunch homepage to see the awesome features available.

Happy coding and testing!

Submit this story to DotNetKicks Shout it


Reviewing uCertify 70-515-CSharp MCTS exam prepkit (Part 2)

Hi again!

As I wrote in the last post, I'm reviewing a preparation kit for the 70-515-CSharp MCTS exam from uCertify.
Today, I'm here to write about what I've found to be the strengths and weaknesses of this product.

This is a full-featured product that pretty much covers everything this kind of tools should cover. I would highlight the following strengths of the product:
  • Easy and intuitive user-interface;
  • Rather complete explanations of why an answer is either correct or incorrect. Some other products I've seen before are only concerned about wrong questions, and dismiss explanations about the correct which may be as relevant as the explanation for wrong questions;
  • Extensive study materials covering most topics targeted by the exam. I didn't use them much myself, because I would rather take a peek at documentation supplied in msdn (links to these online resources are also supplied in a section of this product) and try the old "learn by doing" method. However there are people that would rather read the study materials and retake the tests, so I believe this is a useful feature.
  • Several kinds of test "layouts", from the traditional format, into adptative tests (which dynamically adapt the question complexity to your answers. That is, if you're getting your answers right, the complexity will gradually increase, otherwise they will decrease, thus showing you questions accordingly to your kownledge level).
and my favorite feature:
  • The hability to take quick tests.  Say that you only have a handful of minutes and you want to study a bit. Just open the application, and start a fixed time test, specifying how many minutes you wish to spend. Lacking enough free time to take complete tests, I found myself using this kind of tests a lot.

I would like to point out that despite the target of this application is to prepare yourself to take the 70-515 exam, you can also use it as a way of enriching and testing your knowledge. For instance, I find out that I have some serious gaps in ASP.NET MVC (which doesn't surprise me, knowing that I haven't developed any serious application in MVC). I just might be targeting MVC as one of the next things to investigate deeper.
Bottom line: if you've decided to take this exam, this kind of tools are definitely a good way of testing and evaluating your knowledge and I would recommend the uCertify product. But always remember that you might find different questions and topics in the real exam, so real-world experience is a must-have. Don't take your exam for granted just because you have good results in the preparation tool.

By the way, any readers of my blog are entitled to a 10% discount (in addition to any existing sale) on any test preparation software from uCertify (just use the discount code 'UCPREP' in the uCertify shopping cart).

Submit this story to DotNetKicks Shout it