On Friday July 23rd I’ll be in Winnipeg giving a one day seminar on the nuances of Brownfield Application Development and how to get the most out of it. More about the day can be found here. I recently did the seminar at the PrairieDevCon and it was a blast. The day is filled chocka-block with content and ideas that pertain directly to Brownfield codebases and will work in Greenfield situations.

Registration can be found here and until July 2nd the session is available at a discount. Hope to see you there!

The way that we’re told to use Visual Studio is that we create a solution file and add into it one or more project files. Each project file then gets filled with different development artefacts. When you build inside of Visual Studio each project represents a compiled distributable file (exe, dll, etc). Many people carry this practice over into their build scripts. You might be one of them. I’m here to tell you why you’re wrong to be doing this.

Let’s say you’re starting a project. You open Visual Studio, select File | New Project and get things rolling. In a few minutes you have a Solution that contains a few Projects. Maybe you have one for the UI, one for the business logic and one for the data access layer. All is good. A few months later, after adding many artefacts to the different projects, something triggers the need to split the artefacts into one assembly from one DLL into two DLLs.

You set off to make this happen. Obviously you need to add a new Project to your Solution, modify some references, and shift some files from one Project into another. Say you’re stuck using an exclusive locking source control system (like VSS…shudder). You *must* have exclusive access to all the files necessary including:

• the sln so you can add the new project
• at least one existing cs/vb/fsproj which you’ll be removing existing code artefacts from
• any cs/vb/fs files that will be moved
• any cs/vb/fs files that reference the ones moving (using statements will need updating when you change the namespacing on the files being moved)
• possibly some resx files that need to be moved
• possibly config files that need to be changed or moved
• any automated tests that make use of the moving cs/vb/fs files

It’s a pretty damn big list of files that you will need to exclusively lock during this process. Chances are you will need to push all of your co-workers out of the development environment so that you can gain access to all of those files. Essentially you are, at this point, halting the development process so that you can do nothing more than split one DLL into two. That in quite inefficient in the short term and it’s completely unsustainable in the long term.

I can hear you now, “Well I use <git/mercurial/svn/etc> so we won’t have those issues”. Really? Think it through for a second. Go ahead, I’ll wait.

With the volume of changes that I listed above, you’ll likely want to be working in some kind of isolation, whether that is local or central. So yes, you can protect yourself from blocking the ongoing development of your co-workers by properly using those version control systems. But remember, you do have to integrate your changes with their work at some point. How are you going to do that? You’ve moved and modified a significant number of files. You will have to merge your changes into a branch (or the trunk) locally or otherwise. Trust me, this will be a merge conflict nightmare. And it won’t be a pain just for you. What about the co-worker that has local changes outstanding when you commit your merged modification? They’re going to end up with a massive piece of merge work on their plate as well. So instead of being blocked while you do the work, you’re actually creating a block for them immediately after you have completed your work. Again, the easiest way to achieve the changes would be to prevent any other developers from working in the code while modifications are occurring. Doesn’t that sound an awful lot like exclusive locking?

Now, I know you’re thinking “Pfft..that doesn’t happen often”. This is where you’re wrong. When you started that application development cycle (remember File | New Project?) you likely didn’t have all of the information necessary to determine what your deployables requirements were. Since you didn’t have all of that information, chances were good, right from the outset, that you were going to be doing the wrong thing. With that being the case, it means that chances were good that you were going to have to make changes like the one described above. To me that indicates that you are, by deciding to tie your Visual Studio Projects to your deployables, accepting that you will undertake this overhead.

People, possibly you, accept this overhead on every software project they participate in. This is where you’re wrong. There is a way to avoid all of this, but people shrug it off as “not mainstream” and “colouring outside the lines”. The thing is it works, so ignore it at your own peril.

There is a lot of talk in some development circles about decoupling code. It’s generally accepted that tightly coupled code is harder to modify, extend and maintain. When you say that a Visual Studio Project is the equivalent of a deployable, you have tightly coupled your deployment and development structures. Like code, and as the example above shows, it makes it hard to modify, extend and maintain your deployment. So why not decouple the Visual Studio Project structure from the deployables requirements?

It’s not that hard to do. You’ll need to write a build script that doesn’t reference the cs/vb/fsproj files at all. The .NET Framework kindly provides configurable compiler access for us. The different language command line compilers (vbc.exe/csc.exe/fsc.exe) allow you to pass in code files, references, resources, etc. By using this capability, you can build any number of assemblies that you want simply by passing a listing of artefacts into the compiler. To make it even easier, most build scripting tools provide built in capability to do this. NAnt and MSBuild both provide (for C#) <csc> tasks that can accept wild carded lists of code files. This means you can end up with something like this coming out of a solution-project structure that has only one project in it:

<csc output="MyApp.DAL.dll" target="library" debug="${debug}">
<sources>
<include name="MyApp.Core/DAL/**/*.cs"/>
</sources>
<references>
<include name="log4net.dll"/>
</references>
</csc>

<csc output="MyApp.Core.dll" target="library" debug="${debug}">
<sources>
<include name="MyApp.Core/Business/**/*.cs"/>
</sources>
<references>
<include name="log4net.dll"/>
<include name="MyApp.DAL.dll"/>
</references>
</csc>

<csc output="MyApp.UI.exe" target="winexe" debug="${debug}">
<sources>
<include name="MyApp.Core/**/*.cs"/>
<exclude name="MyApp.Core/DAL/*.cs"/>
<exclude name="MyApp.Core/Business/*.cs"/>
</sources>
<references>
<include name="log4net.dll"/>
<include name="MyApp.DAL.dll"/>
<include name="MyApp.Core.dll"/>
</references>
</csc>

Likewise, we could consolidate code from multiple projects (really file paths is what the build script sees them as) into one deployable.

<csc output="MyApp.UI.exe" target="winexe" debug="${debug}">
<sources>
<include name="MyApp.DAL/**/*.cs"/>
<include name="MyApp.Business/**/*.cs"/>
<exclude name="MyApp.UI/**/*.cs"/>
</sources>
<references>
<include name="log4net.dll"/>
</references>
</csc>

Now, when it comes time to change to meet new deployables needs, you just need to modify your build script. Modify the inputs for the different compiler calls and/or add new compilations simply by editing one file. While you’re doing this the rest of your co-workers can continue doing what they need to provide value to the business. When it comes time for you to commit the changes to how things are getting compiled, you only have to worry about merging one file. Because the build script is far less volatile than the code files in your solution-project structure, that merge should be relatively painless.

Another way to look at this is that we are now able to configure and use Visual Studio and the solution-project structure in a way that is optimal for developers to write and edit code. And, in turn, we configure and use the build script in a way that allows developers to be efficient and effective at compiling and deploying code. This is the decoupling that we really should have in our process and ecosystem to allow us to react quickly to change, whether it comes from the business or our own design decisions.

Recently I needed to create a custom WinForms label-like control that allowed for the text to be displayed in a rotated fashion. Our needs were only for four rotation locations; 0 degrees (the default label position), 90, 180 and 270 degrees. There were other complicating factors, but for this post we’ll only concentrate on this component of the control.

To rotate text using the Graphics.DrawString method you only have to do a couple of things. First you have to use the Graphics.TranslateTransform method, then the Graphics.RotateTransform method, and followed by the Graphics.DrawString. Here’s what it looks like.

using (var brush = new SolidBrush(ForeColor))
{
var stringFormat = new StringFormat
{
Alignment = StringAlignment.Near,
LineAlignment = StringAlignment.Near
};
e.Graphics.TranslateTransform(transformCoordinate.X, transformCoordinate.Y);
e.Graphics.RotateTransform(rotationDegrees);
e.Graphics.DrawString(Text, Font, brush, DisplayRectangle, stringFormat);
}

What you see are the three steps that I outlined above. Let’s start at the bottom and work our way up. The code exists inside of a UserControl’s overridden OnPaint event. The DrawString method makes use of some of the properties on the control, like Text and Font. It also uses the DisplayRectangle property to set the boundaries for the drawing to be the same size as the control. This is one of the keys to making the rotations work. The other key is to provide the DrawString with the StringFormat settings. By setting them to be StringAlignment.Near for both the Alignment and LineAlignment, you are declaring that the text’s location should be based in the top left of the DisplayRectangle’s area.

Graphics.RotateTransform is how you set the rotation value. In the case of our control, we would be putting in a value from the list of 0, 90, 180, and 270. As you might expect the rotations are clockwise with 0 starting with the text in the ‘normal’ location.

Graphics.TranslateTransform is where the last piece of magic occurs. It is here that you set where the top right corner of the text drawing area will be located in the DisplayRectangle’s area. Here are some images that will help clarify the situation.

When you need the text to appear the same as “Text Area” does in the above image (rotated 0 degrees), you need to set the TranslateTransform X and Y parameters to be those that are designated by the “X” in the image. In this case, it’s X=0 and Y = 0.

The picture above shows you what you should be displayed when you are rotating the text “Text Area” 90 degrees. Again, you need to set the TranslateTransform, but this time the values are slightly different. The Y parameter is still 0, but the X parameter equals the height of the text. You can get this value by using the following line of code:

var textSize = TextRenderer.MeasureText(Text, Font);
textSize.Height;

To render the text upside down we set the rotation to 180 degrees and then, again, determine the location of the TranslateTransform X and Y coordinates. Like we did for the last rotation, we will need to retrieve the text size to set these values. For this situation Y will be the text height and X will be the text width.

The final step is to make the rotation work for 270 degrees. Like all the others, we need to set the X and Y coordinates for the TranslateTransform method call. Here the Y value will be the text width and the X value will be 0.

This is simply the first step of many to making a control that will allow rotation of the text and locating it in one of 9 locations in a 3x3 grid representation of the control’s DisplayRectangle. More on that in another blog post though.

Friday past brought the end to the first incarnation of the PrairieDevCon in Regina. The conference had a great buzz of people, interest, conversations and learning about it. It really was a blast to be at it. Thanks to everyone who attended in whatever capacity since it was you that made this event so much fun and productive to be at.

Here are the materials from the sessions that I presented. There isn’t anything for the panel discussion since it was all off the cuff. If you weren’t there you didn’t get to add or absorb….sorry.

Intro To Aspect Oriented Programming: Slides, Code
ORM Fundamentals: Slides

Thanks again everyone and I hope to get invited back to do this all again next year.

Since I haven't written here in a while, I thought I'd toss out this quick tip while it's on my mind.

Working with Expression Blend for WPF or Silverlight can be gratifying.  Sketchflow in particular is a great way to rapidly develop clickable prototypes.  Of course, especially if you're working on a Blend project as a team, you'll want to be using version control with a source repository.  Turns out that Blend 4 has TFS 2010 integration built in (and it can be enabled for Blend 3 via patches for both Blend and TFS 2008).

However, if you're working in Blend, you may find the path to that a little convoluted.

See, you can't actually initially add a project to source control from within Blend. 

At first, I had created the project in Blend, and then when we got to the point where wanted to work on it as a team, we used the Source Control Explorer in Visual Studio 2010 to map the path and check the files into TFS source control.  However, there was no integration with Blend, which was painful, as files would have to be manually checked out through Visual Studio and then manually checked back in.  More painfully, new files added to the project would not be picked up and would have to be manually added. 

This frustrated me enough (and made me start worrying about potentially sticky bad-merging scenarios) to see if the Internet knew of any way to make Blend behave the same way as Visual Studio does with regards to source controlled projects... only to find that it's supposed to already be a part of Blend 4.  So why wasn't it working?

After a little poking and prodding, I finally realised that although the files were in source control, the solution and project files were not BOUND to source control.

This is not something you can accomplish via Blend.  However, if you close Blend, open the solution in Visual Studio, go to File > Source Control > Change Source Control..., select each item listed and click Bind, since the containing folder is already mapped to a source repository folder and the solution and project files are in source control it'll pick up the correct binding.  Save and close Visual Studio, and then open the solution in Blend again, and voila!  Blend is now aware of TFS!  You can check files in and out manually from the Projects pane, files will automatically be checked out when you edit them in Blend, and new files added to the project will automatically be added to source control, just like in Visual Studio.

This is one of those things that seems really self-evident after you recognize it, but you might be like me and not recognize it right away.  So here it is blogged for the benefit of your Google search results.

On our current project we are using MSBuild to build our application. This is my first time using MSBuild other than just tinkering and I have found it.... challenging to say the least. A lot of my challenges are lack of knowledge but the other half is the language itself.

The most recent challenge I wanted to write about was calling a target multiple times. Our scenario is this: We have to generate a batch file for each environment we are going to install in with environment specific settings. The issue I had was that for each environment we had that we were copying and pasting the steps and changing values for each environments. While this worked, as the number of environments grew the size of the build task grew and got harder to modify as requirements changed.

Ideally what we would have is a task that would generate a batch file based on a set of parameters that we could just call out to so I built this:

  <Target Name="BuildBatchFile ">
<Copy SourceFiles="install.bat"
DestinationFiles="MyApp.Setup\Release\install.$(BATCHENV).bat"
ContinueOnError="false"
SkipUnchangedFiles="false" />
<FileUpdate Files="MyApp.Setup\Release\install.$(BATCHENV).bat"
Regex="{ENV}"
ReplacementText="$(ENV)" />
<FileUpdate Files="MyApp.Setup\Release\install.$(BATCHENV).bat"
Regex="{VDIR}"
ReplacementText="$(VDIR)" />
<FileUpdate Files="MyApp.Setup\Release\install.$(BATCHENV).bat"
Regex="{INSTALLDIR}"
ReplacementText="$(INSTALLDIR)" />
</Target>

So this copies my template install.bat to install.[ENVIRONMENT[.bat and then does all the string replacements on it.

The issue is how to invoke this task with different sets of data. My first thought was this:

<CallTarget Targets="BuildConfigFile" />

Unfortunately, there is no way to pass parameters to a target. The only way to do that is to call MSBuild and set the parameters passed to MSBuild (this does feel wrong but I am not sure of a better way to do it so far)

<Target Name="BuildDeploymentPackage">
<MSBuild Projects="$(MSBuildProjectFile)"
Targets="BuildBatchFile "
Properties="BATCHENV=ALPHA;ENV=ALPHA;VDIR=PASIPrep;INSTALLDIR=C:\inetpub\wwwroot\MyApp;" />
<MSBuild Projects="$(MSBuildProjectFile)"
Targets="BuildBatchFile "
Properties="BATCHENV=SYST;ENV=SYST;VDIR=MyApp;INSTALLDIR=C:\inetpub\wwwroot\MyApp;" />
<MSBuild Projects="$(MSBuildProjectFile)"
Targets="BuildBatchFile " 
Properties="BATCHENV=TRAINING;ENV=TEST;VDIR=MyApp;INSTALLDIR=C:\inetpub\wwwroot\MyApp.TEST;" />
</Target>

The above target calls MSBuild to call its own build file and run the BuildBatchFile target with a set of parameters.

Hope this helps (or someone shows me a better way to do it)!

In the past I’ve had to take development teams and build their skills. It was part of what I was hired to do. “Build an app, and at the same time make our developers better.” I’m back at it again and today I had a chat with someone online about where do you need to start.

First you need to know what your goals are. Usually I find that management is, by asking me to make their developers “better”, looking to increase quality, decrease development time and increase maintainability. All of these are pretty vague and there’s certainly no one day course for each one, let alone all of them. So where do you start then?

One of the first lessons I learned while at basic officer training was that before getting my section/platoon/company working on a task I needed to know what their skills (special or otherwise) were. The lesson was all about resource management. I’m starting a new project complete with a new (to me) development team and once again I’m being asked to make them “better". I could go into a meeting room right now and tell them all how they should be doing TDD, BDD, DDD, SOLID, etc. Some (most I hope) of you will agree that these are practices that can make you a better developer. It would be far more prudent of me to walk into that room and ask instead of state though. I should take the lessons of my Drill Sergeant and initially put effort (and not much will be needed) into evaluating what skills (special or otherwise) the team has. That knowledge is going to set the foundation for how I will approach making these developers “better”.

One of the questions raised in the conversation I was having today was “When we talk about things that we can throw at developers to learn, something like DDD is (sic) beneficial. By the time someone reads the ‘blue book’ they should know quite a bit. Where would you place it (sic) relative to SOLID or the other good practices?” This raised the question of what knowledge in what order when dealing with under trained developers.

For me the whole idea revolves around one thing building on another. Yes you could dive straight into DDD, but wouldn’t it be easier if you understood something about SOLID, or OO Fundamentals? So what is my preferred order then? Depending on what the developers skills are I may start in different places, but usually the order would be something like this.

1. Tooling. Understanding and being effective inside Visual Studio and other tools that are used every day.
2. OO Fundamentals. Abstraction, Encapsulation, Polymorphism and Inheritance.
3. DRY. Simple code reuse techniques.
4. SRP. Single Responsibility is the foundation (in my mind) for all that follows.
5. OLID. The rest of SOLID.
6. Coupling. Why developers should care and how they can deal with it effectively.
7. Application Layers. How to use logical layering to build more flexible applications
8. TDD. With the foundation for good design acquired, developers are ready to learn how to apply those design skills.
9. DDD. How to think about business and translate it into code.
10. Frameworks. With the foundations built through this list, I feel developers are ready to understand how to use tools such as nHibernate, StructureMap, log4net and others.

I made the mistake that most developers have; jumping straight into frameworks. While it didn’t set my career back, I did need to take a step back and put concerted effort into building my way back up to frameworks again. The best part? With all of the fundamental and foundational knowledge, learning almost any framework is quite simple.

You can’t expect to blast into a room full of developers and expect them to follow this (or any list on this topic) to achieve overnight success. It’s going to take time. Time, effort and commitment. At least the transition from one learning topic to the other will be logical and smooth.

1. I use a password manager (Roboform) that integrates with my browser. This tool makes me remember one master password and then allows me to fill in login forms on websites with only needing to know one master password. This has let me use unique passwords on all the sites I login to. I see looking through my list of sites that I have 45 accounts on various sites and there is no way that I could remember 45 unique passwords.
2. I use encrypted pop/smtp/imap so as not to divulge my password. Most of the world still seems to use unauthenticated POP3 for some reason
3. I use the NoScript add on for Firefox that allows me to control if scripts run on a page or not
4. I use the ForceTLS add on for Firefox so that if I visit a http site that it will redirect me to an https site (unfortunately you have to setup this list on your own)
5. I never upgrade an OS. I always reinstall. Call me paranoid but it is hard for anything bad to survive a wipe and reinstall
6. I run the Secunia Personal Software Inspector that checks for security issues in third party apps and allows me to easily download updates
7.  I run Microsoft Security Essentials. A free, lightweight, and (from what I have read) accurate virus scanner. It reminds me of how all antivirus software starts out so lets hope MS does not bloat it up.

It’s been a hectic couple of weeks speaking at Winnipeg Code Camp, the Winnipeg .NET User Group and DevTeach Toronto. All the events were a blast to do. To those who attended, thanks for the great questions and conversations.

Session material is available as follows:

Introduction to Dependency Inversion and Inversion of Control Containers – Slide deck, Dimecasts
ORM Fundamentals – Slide deck
Software Craftsmanship – Slide deck