Category Archives: Uncategorized

Stop that Build! Don’t waste time building projects in Visual Studio

Leave a reply

Some time ago, I ran across this conundrum:  Why does Visual Studio continue to build projects when a dependent project failed to compile?

So, I took it upon myself to figure out how to stop the Visual Studio compiler from building projects unnecessarily.  That is:  stop building immediately after it encounters an error.

My solution took the form of a Visual Studio macro.  

  For the uninitiated: that means writing some Visual Basic code to manage the IDE.  

  For the initiated:  You can cringe with me…  😛

So, I opened the Visual Studio Macros IDE and attached an event handler to the BuildEvents object in the EnvironmentEvents module with the following code snippet:

    Private Sub BuildEvents_OnBuildProjConfigDone(ByVal Project As String, ByVal ProjectConfig As String, ByVal Platform As String, ByVal SolutionConfig As String, ByVal Success As Boolean) Handles BuildEvents.OnBuildProjConfigDone

        '-- When the build of a project fails
        If (Not Success) Then

            '-- Cancel the remaining builds in the Solution
            DTE.ExecuteCommand("Build.Cancel")

            '-- Write a polite message to the OutputWindow that's logging all information about this build
            DTE.ToolWindows.OutputWindow.ActivePane.OutputString(vbCrLf & vbCrLf & "Build failed while compiling " & Project)

        End If

    End Sub

Pretty simple, and prevents Visual Studio from running through all of the projects.

Next time, I’m going to attach a timer and start recording my build times to see how the solution has grown.

How to put NuGet in your DVCS

Leave a reply

Something I struggled with some time ago was what appeared to be a conflict of rules.  Consider the Joel Test, where rule #2 states:

Can you make a build in one step?

In order to accomplish this, most developers place copies of any library dependencies into their source control.  With the advent of NuGet, this seems even easier:  just push copies of your nuget generated packages folder into source control as well.

However, in today’s world of distributed version control systems (DVCS) like git and Mercurial it is strongly discouraged that you place binaries into the repository.  This leads to an impasse.  How do we allow a 1 step build, while keeping NuGet out of the repository.

I solved this problem for my team by writing a simple batch file and adding the command-line nuget.exe to the root of my solution folder. 

I added ignore statements for my packages folder, but added the repositories.config file to the git repository.   My .gitignore looks something like this:

I then built a simple batch script to assist in reloading the nuget packages for my solution.  The batch file looks similar to the following:

 1: nuget install Fritz.TomatoTasks.Webpackages.config -OutputDirectory packages
 2: nuget install Fritz.TomatoTasks.Web.Testpackages.config -OutputDirectory packages
 3: pause

To note:  the INSTALL command asks nuget to grab the versions of packages specified in the packages.config files from the nuget repository and install them.  The -OutputDirectory switch specifies that the files are to be written into the standard packages folder.

Each time I add a project to the solution, I copy and paste a line into this file.  This prevents us from having to worry about the storage of binaries, and we can add a command to our continuous integration server’s script to call this file in order to rebuild the solution from source control.

Do you have a way to improve my process?  Let me know in the comments below or on Twitter at:  @csharpfritz

Only 7 lines of code please

Leave a reply

I ran across this question at Programmers.StackExchange discussing a coding guideline that states “Methods should not exceed 7 statements”.  I find these types of guidelines and the reactions to them quite amusing.

Let’s not forget the SOLID modeling principles before I begin to ramble.  Go ahead and review them for a minute.  I’ll wait…

Got it?  ok…  Programming Guidelines are written by Alpha Geeks for more intermediate and junior coders.  A rule like this one is set forth to force the uninitiated to think about how they can break down their objects and methods into much smaller, re-usable chunks.

 Consider this:  if the junior developers on your team are writing methods with 7 lines of code or less, you’re reducing the chances they’ll publish code with high cyclomatic complexity.  You’re project should end up with much simpler, less complex code just because of this rule.

Senior developers and architects who write boiler-plate code may violate this rule.  If you know WHY this rule is in place, then you know the hows, whens, and wheres about violating the 7 lines of code rule.  Those individuals are thinking about keeping complexity metrics down, and code coverage high.

Should you be writing 7 line methods?  A quick glance through one of my personal projects and the only ‘large’ methods I find are in unit tests…  and I’m okay with those.

Try using this rule for a week and see how it forces you to craft your code.  You might be surprised what you get.

Scrum Practice: The 15:5 doc

Leave a reply

As my role within our scrum project team has evolved into a lead developer, I find myself in more and more design and collaboration tasks with my developer teammates.  I was initially going through oral and white board design sessions with my team to convey how the technical design for the sprint was evolving.

However, our team has grown to 5 developers (including myself), 2 QA analysts, a product owner and our scrum master. I’ve found that my verbal communication approach is simply taking too much time away from coding.  In discussion with my director and our scrum trainer, we settled on a practice called the “15:5 document”.  I have not found discussion of this technique on the web, and will share what I have found over the past week of using this approach.

The 15:5 document receives its name because it takes 15 minutes to write, and only 5 minutes to understand.  This document is a complementary document to the User Story, and I store them as an attachment to the User Story in Team Foundation System (TFS).  This isn’t a full-blown design document, but more of a place-setting.  It is the springboard of tribal knowledge a developer needs in order to get about 40-50% into the design of a user story’s tasks.  The remainder of the design is confirmed through periodic code-reviews when builds are pushed.

Typically, I load the document with:

  • An entity-relationship diagram from Visio or a photo of one scrawled on a whiteboard
  • Some bullet points describing the diagram
  • A sample database table design if necessary
  • A scribbled wire-frame of what the UI may look like

I was thinking of putting together an MSWord template for this type of document, but these 3 sections seem too easy to simply build out as I write out my designs.

Give it a shot…  I’d appreciate any feedback or options of other scrum design practices.  You should see more scrum flavored posts in the coming weeks as I adjust to this role.

    Personal Asp.Net with IISExpress builds

    Leave a reply

    Recently, I ran into an issue where my team wanted to run their local Asp.Net project builds so that their IISExpress instances were visible to the other team members.  This is a non-trivial setup, as a simple checkbox in the Asp.Net project properties window activates IISExpress to host the project, but does not make it visible outside of the local machine.

    To configure IISExpress to answer to other names (besides localhost) the following steps are needed:

    From an administrative command prompt issue the following command:  

    netsh http add urlacl url=http://mymachinename:50333/ user=everyone

    “mymachinename” is the hostname that you want to respond to, and 50333 is the port that Visual Studio assigned to my project.  Your port may be different, change this value to match the port that Visual Studio assigned to you.

    In the applicationhost.config file at %userprofile%DocumentsIISExpressconfigapplicationhost.config find the website entry for the application you are compiling and add a binding like the following:

    <binding protocol="http" bindingInformation=":50333:mymachinename" />

    Finally, restart IISExpress to force the web server to re-load the settings you have just changed.  This should allow the service to answer to the appropriate host.

    However, if you would like to configure Visual Studio to launch and browse to “mymachinename” instead of localhost, you need to change 1 more setting in your web project’s config.  On the “Start Action” section, set this to start with a ‘Specfic Page’ and key in the appropriate full machine name and port combination in the textbox to the right.

    This preference entry is saved in the YOURWEBPROJECT.csproj.user file. By making this decision, you will allow the .csproj file to be checked in to your source control without impacting the other members of your team.