While working through some of the Excel scenarios lately I've come upon some more ways to test Excel.

Create an Excel Application instance with the default workbook.  Doing this will drastically speed up your tests.  Do this in the fixture setup & assign it to a property of the test class.  This way, no more startup and tear down of the Excel object for each test.

public Application ExcelApplication { get; set; }

[TestFixtureSetUp]

public void CreateExcelAppAppropriately()

{

    ExcelApplication = new Application();

    ExcelApplication.Workbooks.Add(Type.Missing);

    ExcelApplication.Visible = true;

}

That will give you a good kick start when you end up with a few dozen or more tests.  Starting up and killing the Excel Instance on each test can be brutal in overall performance.  For the shutdown of the tests, as long as you have clean code and don?t have odd Excel threads or something running off everywhere, the fixture shutdown can be as simple as below.

        [TestFixtureTearDown]

        public void QuitExcelAppAppropriately()

        {

            foreach (Workbook workbook in ExcelApplication.Workbooks)

            {

                workbook.Close(false, false, Type.Missing);

            }

            ExcelApplication.Quit();

        }

One other thing I like to do is add a boolean value that sets the Excel instance to stay visible and not close after the tests.  I create a private bool and then set it in any test I?m currently working with.  When I?m done I just remove the assignment and let it default to false.  This way the Excel instance doesn?t stay open for the build & tests on the build server.

private bool reviewExcelPostTests;

[TestFixtureTearDown]

public void QuitExcelAppAppropriately()

{

    if (reviewExcelPostTests)

        return;

    foreach (Workbook workbook in ExcelApplication.Workbooks)

    {

        workbook.Close(false, false, Type.Missing);

    }

    ExcelApplication.Quit();

}

That's it for my Excel tips today, I'll have some more coming in the near future.

When creating an Excel Application there are some things to keep in mind.  Recently I was creating some tests, which I'm not sure if they'd be "unit test", but they do test Excel.  I created a fixture setup and a fixture tear down that would create my Excel Application object that I?d want to test again.  The code I ended up with is shown below.

[TestFixture]

public class ConnectionManagement

{

    public Application ExcelApplication { get; set; } 

    [TestFixtureSetUp]

    public void CreateExcelAppAppropriately()

    {

        ExcelApplication = new Application();

        ExcelApplication.Workbooks.Add(Type.Missing);

    }

    [TestFixtureTearDown]

    public void QuitExcelAppAppropriately()

    {

        foreach(Workbook workbook in ExcelApplication.Workbooks)

        {

            workbook.Close(false, false, Type.Missing);

        }

        ExcelApplication.Quit();

    }   

}

Now if anyone has a better idea on how to test Excel and knowing the code will work against the actual Excel Application, PLEASE, let me know as this doesn't feel like the best way to do this.  I keep getting the sinking suspicion that there should be a better way to test Excel Application Addins, Spreadsheet code and such.

If you receive this error, "TF31005: Team Foundation cannot retrieve the list of team projects because it cannot connect to Team Foundation Server", or if you are debugging and the code you see on screen is not what is being stepped through or you see VS stepping through white space lines, try this out.

Clear out the cache here on Vista...

C:\Users\userName\AppData\Local\Microsoft\Team Foundation\2.0\Cache 

...or try clearing out this directory on XP/Server 2003.

C:\Documents and Settings\userName\Local Settings\Application Data\Microsoft\Team Foundation\2.0\Cache 

This should get the ball rolling for Visual Studio & TFS Synchronization again.

UPDATE:  This thing kept nagging me throughout the day until Denis (coworker) finally got into the logs and found this "Invalid length parameter passed to the SUBSTRING function".  This occurs, usually, right after a SP1 upgrade on the TFS Server.  After poking around a while Denis found this KB.  After running a simple update statistics...

use tfsintegration

update statistics tbl_security_identity_cache

...all was running flawlessly after that.  Only an 8 hour day lost.  :(  But hey!  At least this helps somebody out there!

I was trying to get some deserialized JSON objects to bind to my WPF application interface and was struggling.  I figured out what the fix was, I took the shortcut route on my objects and should have built them correctly.

My original objects where built as such:

public class ReportItem

{

    public string AccountId;

    public string Name;

    public string Id;

}

However, they should have appeared as follows:

public class ReportItem

{

    public string AccountId { get; set; }

    public string Name { get; set; }

    public string Id { get; set; }

}

The classes that will be bound need to have legitimate properties, not merely public members.

Now when I do a binding via the XAML

        <ComboBox 

            Margin="193,75,12,0" 

            Name="comboProfiles" 

            Height="23" 

            VerticalAlignment="Top" 

            IsEnabled="True" 

            ItemsSource="{Binding}" 

            DisplayMemberPath="Name" 

            SelectionChanged="comboProfiles_SelectionChanged" 

            SelectedIndex="0" />

and then bind at run time like this

var javaScriptSerializer = new JavaScriptSerializer();

comboProfiles.DataContext = javaScriptSerializer.Deserialize<List<ProfileItem>>(e.Result);

everything works flawlessly.

I haven't written up a tip o' the day in ages, so it was about time that I ran smack into one.  While working with ADO.NET Data Services I kept getting this AWESOME error message!

An error occurred while processing this request.

That being one of the most awesome, fully articulate, well written, useful, cool error messages ever created!

Ok, so if you're like me, and you'd actually like some idea of the underlying error, then here's the trick.  First, grab that web.config and make sure your services have the appropriate debugging attributes.

   1:    <system.serviceModel>

   2:      <behaviors>

   3:        <serviceBehaviors >

   4:          <behavior name="DebugEnabled">

   5:            <serviceDebug includeExceptionDetailInFaults="True"/>

   6:          </behavior>

   7:        </serviceBehaviors>

   8:        <endpointBehaviors>

   9:          <behavior name="TheReporter.AjaxConnectionServiceAspNetAjaxBehavior">

  10:            <enableWebScript/>

  11:          </behavior>

  12:          <behavior name="TheReporter.Services.AjaxConnectorServicesAspNetAjaxBehavior">

  13:            <enableWebScript/>

  14:          </behavior>

  15:        </endpointBehaviors>

  16:      </behaviors>

  17:      <services>

  18:        <service name="TheReporter.AjaxConnectionService" behaviorConfiguration ="DebugEnabled">

  19:          <endpoint address="" behaviorConfiguration="TheReporter.AjaxConnectionServiceAspNetAjaxBehavior" binding="webHttpBinding" contract="TheReporter.AjaxConnectionService"/>

  20:        </service>

  21:        <service name="TheReporter.Services.AjaxConnectorServices" behaviorConfiguration ="DebugEnabled">

  22:          <endpoint address="" behaviorConfiguration="TheReporter.Services.AjaxConnectorServicesAspNetAjaxBehavior" binding="webHttpBinding" contract="TheReporter.Services.AjaxConnectorServices"/>

  23:        </service>

  24:      </services>

  25:      <serviceHostingEnvironment aspNetCompatibilityEnabled="true"/>

  26:    </system.serviceModel>

Note the attributes that have words like "debugged" in them.  Throw those in and you're probably set.  Another thing you can do is to throw in the following code in your actual data service to enable verbose debugging.

   1:      public class RssStorageService : DataService<RssStoreEntities>

   2:      {

   3:          public static void InitializeService(IDataServiceConfiguration config)

   4:          {

   5:              config.UseVerboseErrors = true;

   6:              config.SetEntitySetAccessRule("*", EntitySetRights.All);

   7:          }

   8:      }

So that should provide some reasonable error messages instead of the awesome one at the top of this here post.   ...Oh but wait, there's more!  One last tip for this tip is the code attribute tag.  Throw this onto a particular method to add verbose debugging.

   1:  [System.ServiceModel.ServiceBehavior(IncludeExceptionDetailInFaults = true)] 

(I snagged these last two from here, the first part of this tip I snagged from here.)

The Scenario

A Continuous Integration (CI) Build, which I'll dub "Cib", takes approximately 1 hr & 30 minutes. The build takes into account various builds from various platform technologies; Java, .NET, and PHP. The emphasis of course being that no single stack is available. To build the end solution all of these stacks need to be rolled into the build.

At a build time of 1 hour and a half, there is little ability to accurately watch the build, assure check ins work, or to be accurately notified of what is or is not being included in the build if numerous check ins are occurring.

What instead needs to occur is a short build. Builds in a CI environment really should not take a long time to compile, if they do, you really lose most of the CI benefit. So how long is acceptable? I'd prefer something around 5 minutes, not much more, and definitely less if possible. In most scenarios, no matter how big the project, this is possible. So what are the solutions?

Just to get a few ideas I spoke to a few guys at work about their ideas. Both Josh W. (Code Recon & System Configuration Guru) and Robert S. (Build Management Ace) gave me some good ideas. A few other conversations were had about what others had done in the past and two solutions came up the most preferred first steps.

The Solutions

1. Split Em' Up; Functionally, Technically, Departmentally, or However. The first thing in a multi-technology stack environment is to split up the individual builds. If need be split up various solutions into independent development teams functional segments. At some point, the solutions or projects would be broken down enough to have reasonable build times. These smaller segmented pieces are what should be setup for continuous integration. With that completed, then keep a single large, long running build as a daily build. Whatever the case, just leave it solely as a build versus a continuous integration build.
2. Autonomous Continuous Integration Builds. Setup the builds autonomously on the build server and monitor only the build or build(s) that you need for daily development. On TeamCity this is super easy, probably is easy on VSTS, and I know it can be done with Cruise Control. It is important to monitor and be able to track any error that occurs during the segmented builds, specifically the one pertinent to a particular developers efforts.

Summary

I'm sure there are many other solutions. If you have any, please do leave a comment. Overall, the point is, continuous integration is NOT a long running build. At best, one could call that a scheduled build. A continuous integration build must be efficient and run in a reasonable amount of time. The safest range is between 2-5 minutes. Of course, less time is better.

Over the years I've tried various configurations for projects and solutions in Visual Studio. One thing I've noticed is there are definitely good ways to do things and bad ways to do things. My intention is to, with this entry and others, lay out what is good, efficient, and elegant practice in putting together Visual Studio Projects. Since I haven't posted a tip o' the day in a long while, I figured that would be a great category to drop these into.

Don't Add Projects Whimsically!

Projects after a while start to cause all sorts of problems. There are interdependency issues that come up, possible circular references, reference maintenance, obfuscation of logic, namespace telescoping, and the list goes on. Keep project organization simple. In MVC for instance, often a solution becomes littered with a project for the model, the assembler for the model, a project for the view, and maybe ever several projects for the controllers.

All of that should be fine in a single project! Yes, one single itty bitty project. The project can then be built into a single DLL and life is thus simplified!

So don't add projects "just because".

Daily Habits and attitudes of an Agileish Developer

1. Always talk to the other developers around you about what is going on, what you're doing, what they're doing, and know what is going to affect your work.
2. Pair up often to develop parts that you are both respectively working on.
3. If you need a break from social existence, do some mindless work, don't work on intricate parts of code.  If you can't verbalize and discuss what is going on, you don't need to be poking around in that particular code.
4. Get user stories, if questions about the story arise, ask questions, if the story doesn't make sense, get the story changed.
5. Make sure you can figure out a way to test your code, if you can't you're most likely designing something poorly.  If you can't test it in isolation you probably haven't thought it through all the way.  Sometimes though some code just has to be badly written.  :(
6. If you find yourself getting lost in code, refactor.  If you find you've written this piece of code before and deja vu is setting in refactor.  If you have more than 2-3 questions every few minutes about a piece of code, refactor.
7. If you can't read a story from the code and the code tests, refactor.

So I was messing around with ReSharper and I accidentally hit Ctrl-Q.  Amazingly I was hovering over the method I had just tossed some XML Comments on.  ReSharper displayed this awesome message with the documentation.

(Click to see the bigger image)

Anyway, you'll notice the XML Comments, method name, and the display box I have all tagged with gigantic red arrows.  I couldn't help but think, "check that out, way easier to read the green XML comments".

Meanwhile a few hours later I was poking around Haacked and somehow stumbled into this blog entry.  Go figure, I'm only 2 years late on figuring out this nifty documentation trick.

...and that makes reason number 234,987,123,203 to GET ReSharper!  Otherwise, you're spending too much time doing whatever you're doing.

A little post build event can help a lot when one has multiple assemblies that need to be utilized by an application.  Such as the entlib or composite library.  Just put the following script in the post build event and make sure to create a directory were the assemblies will go.  Boom - you got everything in one place were you want it!

copy /y "$(TargetDir)$(TargetName).*"  "$(SolutionDir)..\build\references\"