Category: .Net (Page 1 of 2)

Splitting out your build file into smaller manageable chunks is a good practice to keeping them maintainable. Incorporating existing build files into your main one can sometimes be tricky, particularly when dealing with targets that depend on paths. Where you assumed you were executing one build file in a certain directory, suddenly you need to be able to run it from the root directory as well.

To maintain backwards compatibility (able to run it from the existing directory and a higher, root directory), I make use of nant’s ability to override property values (not supported by ant). Here’s the snippet of code I used:

<include buildfile="differentDirectory\deepdown\nested.build"/>
<property name="nested.build.root" value="differentDirectory\deepdown"/>
<if test="${file::exists('nested.build')}">
  <property name="nested.build.root" value="."/>
</if>
<echo message="Running nested build from ${nested.build.root}"/>

All of the tips I wrote a long time ago for speeding up Visual Studio 2005 still apply. I’ve found that the preferred replacement for Cool Commands is the Power Commands plugin that Microsoft now provides.

I remember looking at a few codebases in C# and it surprised me how many people encapsulate some of their system well, yet treat their application configuration as a different thing. Many times I’ve seen code that looks like: ConfigurationSettings.AppSettings["DatabaseConnectionString"]; alongside the thing that is using it. In fact, I often see this code repeated in various parts of the system wherever anyone needs to draw on application configuration.

Global variables are bad
Most good programmers seem to realise that most global variables are bad, yet this is exactly what I think accessing the application configuration is like. If you want to change the way your configuration is loaded (i.e. programmatically or from a database) think of how many places you now need to change it, let alone how it effects the order in which you instantiate objects.

My advice: Separate the use of configuration from where it declared
I try to follow the pattern isolating the configuration into a single class depending on the access method, such as:

• DatabaseBackedConfiguration
• FileBackedConfiguration
• DefaultInMemoryBackedConfiguration

Each of these classes them implement several roles depending on what configuration they might provide such as:

• HibernateConfiguration
• ApplicationConfiguration
• ArchivingConfiguration

Having smaller roles makes it clearer what sort of configuration is really needed for a particular consumer, and it allows me to change the decision about how that configuration is now provided to it. It enables me to do things like specify different environment configurations and do so in the method that I prefer.

About 60 people (only of which three or four were female) crammed into a tiny room near Red Lion Square last night for the London DotNet Users Group meeting. I have no idea what the normal turnout rate is, though I guess the topic (TDD) probably drew quite a lot of people. Three people presented and the meeting ran for a total of three hours until 9:30pm at which point, we left for the pub and stayed until closing.

The three presenters for the evening and the topics included:

• Zi Makki: TDD and the Data Access Layer
• Sebastien Lambla: The MVP pattern
• Ian Cooper: Best Practices for TDD

The first presenter covered some techniques for dealing with integration points with a database. I noticed that he used Coderush (all those bright colours and arrows hurts my eyes!) instead of Resharper though I think he was using VS2008. It seems that Coderush also lacks a way of extracting a class into a file for a different assembly or at least it wasn’t used. I’m pleased the presenter used BDD styled should as I’ve found these help focus the person writing the test. He finished with some very useful tips though I was worried by one of his final statements, “Avoid Integration Tests”. I think as a principle, fine. For someone in the early stages of learning TDD (think of the Shu in the Shu Ha Ri), it’s a dangerous blanket statement they may follow as integration tests can be useful points of feedback as well.

The second presenter talked about the Model View Presenter Pattern although after seeing his implementation, and I think it is probably more an example of both the Supervising Controller and the Presentation Model. I find it interesting to see how far Sebastien pushed the databinding features of ASP.Net. It’s given me some thought about how I might actually give databinding another real chance. I’m really interested to see how this works in an update mode in this same world. I also learned here that the Macbook Air isn’t great for doing presentations where you need to write code (the buttons are too small!)

The final presenter, Ian Cooper talked over lots of best practices around Test Driven Development. Ian has plenty of great things to say and one of my only issues was that there was probably far too much content on the slides to cover in just an hour.

One of the other topics that wasn’t covered and I think is important for newbies to TDD is understanding when to or when not to use it. As I wrote in a previous post, if you’re doing TDD all the time, you’re doing something wrong.

I really enjoyed talking to other people who went along and I’ll definitely be back again sometime.

I’ve been playing around with some of the new features of C#3.0. I installed VS2008 and the new Resharper 4.0 EAP available here. I expect most of the Jetbrains EAP stuff to be pretty buggy and I’ve already had it crash on me more than five times today. Still, being able to refactor and navigate around files is worth the buggy trial.

Out of the box support for the new language features looks interesting as well as some of the new tools and refactorings in place. Interestingly, default settings suggests constant use of the new var keyword replacing the class declaration you should be using. I’m a little uncomfortable with this as the default setting though it could be because I’m not used to seeing C# code like that.

I started playing around with extension methods, trying to convert the ReflectUtil I wrote back in this post. After a rewrite, some of the APIs looked a bit better although at the cost of making some private inner classes and delegates public. I’m not sure if I like it yet and still trying to think of some guidelines for when to use it. I think definitely having all the extension methods grouped together would help – either in one big Extension class (if you don’t have too many) or in a [Class]Extension class so they’re much easier to locate. If you find youreself writing StringUtil classes, consider converting them to Extension classes. Right now, extension methods only work on instances, so if you want to be able to add static methods, vote on the topic here. I’m not yet convinced it’s that useful just yet though.

Lambda expressions look especially nice although now it’s just plain confusing how you have three ways to do something and there’s really little benefit out of the two more verbose ways. Use this to replace anonymous delegates with a less verbose method.