C# Tea Time

Environment Agnostic Tests

What is an environment agnostic test?
This is a test which will execute successfully no matter how the environment is configured assuming that the product which you intend to test is available on the machine.

What are some possible environment variables?
Operating system, platform, OS language, product language, product sku, product settings, additional applications, etc.

As seen here there are many variables and one thing that my team expects is that our tests will execute the exact same way under all circumstances providing that the test is executing in a supported scenario. This leads to a rather large automation matrix that must be tested against before we ship (this will be another post), but it also leads to a very well defined and efficient test infrastructure.

The above expectation sparked a discussion because we were executing a joint run that included both VB IDE and C# IDE tests, which resulted in some of the C# tests failing. They were failing because in order to execute a joint run with both VB and C# tests, all tests must execute under the VB profile. All tests must execute under this profile, because the VB tests are not environment agnostic (yet!) and all of the C# tests are (well should be).

We will be discussing this topic more in our team meeting on Monday in order to assure we are all on the same page and I will make it one of my missions over the next few months to ensure my teams tests will execute flawlessly under any supported circumstances.

My questions for you are what kind of tests do you execute? What expectations do you have for your environment? Have you had similar discussions at your company?

DevDiv Source Control

A question that I was recently asked on a trip was what source control system we use and what it looks like. I've spent quite a bit of time in this space for our team and will try to answer the question with this post.

What source control provider does your team use?
During the Visual Studio 2008 product cycle the primary tool for source control was an internal tool called Source Depot. While not all teams used Source Depot, yes some used TFS, it was the primary source control provider and it was what most of the internal tools were built against and we didn't have time to rebuild them to completely target TFS. Any important branch, Main, Beta1, Beta2, RTM  was in Source Depot. The move had started though... we are beginning to dogfood TFS and tools where getting ported.

Once 2008 was shipped the entire division focused on moving to TFS. This is now the only supported source control provider moving forward for new and future work. We will continue to support Source Depot for a while as our 2003, 2005 and 2008 source code lives there and we must continue to support those products.

What does your source control structure look like?
Generally our source code tree is about 3 levels deep. The top level root branch is referred to as Main, child branches of Main are referred to as Product Unit (PU) branches and child branches of PU branches are referred to as feature branches. Some teams have one PU branch and one feature branch. These teams generally just use the PU branch as a staging area when taking integrations up or down. Other teams will have multiple feature branches that will regularly integrate up to the PU when their work is complete. It's often interesting for individuals to see that each PU within the division functions as their own entity handling check-ins, integrations, builds and the number of branches differently. While most of the teams function in a similar fashion almost every team has some quirk in their process. My team as long as I have been a part of it follows the single feature branch and single PU branch model.

How many integration\merge conflicts do you normally have to deal with?
This really depends on how the branch structure is setup and how much your team needs to change shared code vs. team specific code. Generally I would say the number of conflicts my team sees on average is around 30 - 40. Though the other day when I was doing an integration of QA code only I had around 5,000 conflicts. Fortunately I didn't have to resolve each of these by hand, because the owner of the files just said they wanted to take what ever was in the destination branch and to ignore the incoming changes. This was a blessing.

Is your test code under source control and if so where do the sources live?
Yes all of our test code is under source control. It is treated very similar to the product code and is branched with the product code. While this was probably the answer that you expected the test code has not always lived with the product nor was it branched accordingly. This was a recent change in the last three years. I feel this was the correct change, though I still feel some in the division might not agree. When we added the test sources to the product source control I believe it almost double the size of the depot in size and tripled the number of files.

How long does it take to sync all of Main?
I don't have any data on this. I will work on getting some and make another post out of it in the future.

Disposing Your Finalizers

Yesterday I was bitten by a bug in our test infrastructure where the code was attempting to dispose of an object in the finalize method. It took me a bit longer then I had hoped to track down the issues, but in the end I did track it down and fixed it.

Here is some example code where the bug exists:

class Logger : IDisposable
{
    private StreamWriter Log { get; set; }

    public Logger(FileInfo file)
    {
        Log = File.CreateText(file.FullName);
    }

    public void Write(string msg)
    {
        Log.WriteLine(msg);
    }

    ~Logger()
    {
        Dispose();
    }

    public void Dispose()
    {
        if (Log != null)
        {
            Log.Dispose();
            Log = null;
        }
        GC.SuppressFinalize(this);
    }
}

You may be looking at this code and asking what is wrong even after you glance over the MSDN article, Overriding the Finalize Method. The first sentence of the article is, "A Finalize method acts as a safeguard to clean up resources in the event that your Dispose method is not called." At a quick glance one might think the following. A dispose method is designed to be called multiple times without adversely affecting the object and the framework has a notion of a Finalize method that will always be called, so why don't I just call the Dispose method from Finalize?

The reason that you never want to call a Dispose method from a Finalize method is that the Finalize method was implemented to ensure that all unmanaged resources are cleaned up since the GC cannot handle these. Since the GC is allowed to clean up/finalize managed resources in which ever order it wishes if you run the above code enough you will notice that the StreamWriter object is finalized before the Logger object. At this point when the Logger object is finalized it attempts to invoke it's Dispose method, which in turn attempts to invoke Dispose on StreamWriter which throws because the object has been cleaned up.

To fix this code I removed the Finalize method, since it should have never been implemented as we are never allocating any unmanaged resources.

Here are some other resources on the topic.

• C# Destructor Syntax
• Implementing a Dispose Method

Orcas Beta 2 Automation Planning

I am in the process of finalizing the C# automation matrix for Beta 2. One of the scenarios that I feel receives very little coverage today, and that I would like some help with, is the interaction of Visual Studio with other software or machine configurations.

Have there been any pain points that you have run into when attempting to use Visual Studio in the past or install it that we could have made better? How is your dev box configured? Do you run as an admin or normal user? What about on Vista? Have you ever needed to install VS on a domain controller? What about a server in a DMZ that is seeing an issue that is not reproducible in the dev environment?

Anyway... let me know your thoughts and I'll see what I can do in order to incorporate this into our testing somehow.

Are there things that you would like to hear about from the C# testing/automation perspective?

Port 25

I was just walking through the hall here at MS an notice a poster with a penguin on it. The first (and correct) thing that crossed my mind what Open Source and Linux. The poster was an advertisment for Port 25 which is a community that offers a look into the Microsoft Open Source Lab.

 It doesn't seem that there is a lot going on in the community site right now, but I would expect to see more coming soon. It also appears that the team and Novell are both hiriing.

C# Orcas Bug Bash

Today at work I participated in my first bug bash after being at Microsoft for a little over 18 months. It was a lot of fun though one thing I have noticed was that due to my role in driving the automation there are a lot of things that I have become distant from in the IDE. Today was really a great time for me to sit down and really begin to digest all of the great language features that are coming in Orcas with the release of C# 3.0.

A bug bash is a time set aside for a team (usually a product unit PU) to step back from their everyday work and spend time using the product looking for bugs. The PU will usually break those participating into smaller teams of 3 - 5 people that will then work to find bugs. Each bug found is then rated, ranked and scored. At the end of the day prizes will usually be awarded for the best bugs found and then people have bragging rights around the office for a while.

So what has come out of our bug bash?

• There were 20 teams total that participated, 42 total individuals (PMs and SDETs from the C# team)
• As of 10:30 PM PST there had been 288 bugs logged
• Some will be resolved as by design
• Some will be duplicates

My First Review

Well it's that time of year at Microsoft and all employees were supposed to have the annual review completed by the end of today. I was getting a little worried there at first that I might not get my review completed in time because the C# team is pressing hard to complete all of our cool stuff for Orcas. Though my excellent manager scheduled my review this morning. I think that overall things went really well and I came out of the process with a few more things to shoot for over the next year. Well one year (actually 15 months) down and many more to come.

Soon To Be Recruiting

Today I booked my recruiting trip to Michigan Tech and the University of Chicago. It was actually quite painful booking the trip since there are only 3 flights in and out of Houghton each day. I actually was not able to get a flight in or out of the Houghton County Airport on the days I needed so instead I am flying into Marquette, driving to Houghton, then driving down to Chicago. I am very excited about the trip and looking forward to talking with some great candidates. If you are a student at either of these schools or live near by let me know. I have some free nights and would love to grab a beer and socialize a bit.

C# Language Service QA Exposed

We recently had a “pep” talk on the Visual C# QA team to talk about what our mission is and what some of our goals our. The mission hasn’t been fully baked so I won’t post it the specifics about this today, but expect to see something on this very soon.

I did get one thing out of this discussion and it’s that we want to the individuals on this team to take pride in the excellence of testing and quality assurance. One thing I’ve noticed is that we don’t communicate very and this is a problem.

I’ve decided that I am going to begin trying to post about daily issues that end in success and failure. This is in part to try and learn how to communicate effectively what is going on in my team, division and inside the company as a whole. I’ll be open, honest, and would love to hear your feedback.

Things on the list to talk about over the next few days/weeks are:

• Wrapping up MQ
• MadDog
• C# Automation (since I own that)
• Orcas M1 (starting next week)
• Thoughts on Scott’s Persona Post

Windows Hockey Jersey Pictures

Sorry this took a little longer then expected, but here is a picture of the Windows Hockey jersey's. One thing to note is that the jersey's we are selling will not have the XBOX patch on them.

Off Recruiting!

Well I am off on my first recruiting trip while at Microsoft. Ever since I joined the company I’ve wanted to be involved in our recruiting, interviewing and hiring process. I know the kind of impact an individual can have that is involved in these processes and I was willing to take on this responsibility. Today I am off to Grand Valley State University doing a little alumni recruiting, then I am on my way to Notre Dame and finally I will make an appearance at North Carolina State University.

If you’re a student at one of these schools or a student in the area and have access to the career fairs feel free to stop by, pick up some swag and talk to one of the employees out doing some recruiting. We are waiting for you to make an impact on us so that we can watch you impact our company.

Windows Hockey Jersey Questions

The Windows hockey jersey will be the dark Vancouver Canucks jersey manufactured by Kobe Sportswear. Check out Kobe Sportswear for sizing. Pictures coming soon...

Hockey Challenge 2006

Mark your calendars and grab your skates! Join us March 11th and 12th at Key for the 2006 Hockey Challenge!
 
Fundraising
My goal is to raise over $10,000 for the Ronald McDonald House of Seattle! Your donations are tax-deductible and I will begin tracking my progress this week on my blog. Please let me know if you are interested in making a donation to support the Windows Hockey Team and more importantly the Ronald McDonald House of Seattle.

Interested in a Windows Jersey?
This year, the Windows Hockey Team is selling jerseys identical to the ones worn by the team.  The jerseys are sold for $100 each and can contain your name and desired number.  If you are interested in purchasing a jersey (youth or adult size), please contact me for details.  The profits on the jerseys are tax-deductible and will support the Windows Hockey Team fundraising efforts.

Interested in a Windows or MSN Hockey Puck?
This year, along with the Team Jerseys we will also be selling Windows and MSN Hockey Pucks for $5.00. The profits are tax-deductible and will support the Windows Hockey Team fundraising efforts.

Interested in Other Sponsorship?
If you own a business or are just interested in other sponsorship opportunities please take a look at the Sponsorship Document.

Want Tickets?
This year, the event is being held at Key Arena on March 11th and 12th.  Windows is playing MS IT this year.  The game is on Saturday and your $20 ticket gets you in for the whole day, which includes four Challenge games as well as the T-Birds game that night. To purchase tickets follow the links below for the desired day you wish to attend select WINDOWS for your seating choice. By selecting windows your ticket purchases will count towards our teams overall fundraising goal.

Saturday Games
http://www17.serrahost.com/servlet/seattle-thunderbirdscom/Detail?no=308

Sunday Games
http://www17.serrahost.com/servlet/seattle-thunderbirdscom/Detail?no=309

Challenge 2006 Schedule

Saturday
Game 1 – IBM vs CommVault – 9:45 am
Game 2 – MSN vs MS.COM – 11:00 am
Game 3 – MSIT vs Windows – 12:45 pm (My Game)
Game 4 – VS Women vs Windows Women – 2:30 pm
Game 5 – Celebrity – 4:15 pm

Sunday
Game 1 – Army vs Navy – 12:30 pm
Game 2 – Police vs Fire – 2:15 pm
Game 3 – Thunderbirds – 5:05 pm
Game 4 – WAMU vs Starbucks – After T-Birds

About the Challenge:
The annual RMHC Hockey Challenge is one of the primary fundraisers for Seattle’s Ronald McDonald House.  Proceeds from the Hockey Challenge weekend and activities directly support operations at the House, enabling families with critically ill children undergoing treatment at Children’s Hospital to have a safe and home-like environment regardless of their financial situation.
 
The Hockey Challenge began in 1998, when hockey-playing Microsoft employees, with the help of the Seattle Thunderbirds, took an in-house rivalry public and decided to raise money for a good cause at the same time.  In 2001, Microsoft made a $2 million pledge to support the construction of expanded Seattle Ronald McDonald House facilities, and vowed to hold the Hockey Challenge event each year to raise money until the pledge was met.  The $2 million pledge was fulfilled in 2003, and the Hockey Challenge continues!  Hockey Challenge 2006 is an RMHC-managed event that has tremendous momentum and support from the local and national community, including Celebrity Chair Kiefer Sutherland.  Thanks to the continued support of Microsoft, the Seattle Thunderbirds, celebrities, sponsors, NHL alumni and hockey enthusiasts, RMHC hopes to raise $300,000 in 2006.
For more information, please visit http://www.rmhcseattle.org/fundraisingevents.php

CHAT: C# IDE, November 17th @ 1:00 PM PST

"Expansions, enhanced intellisense, type colorization, refactoring, improved code navigation, metadata as source, Edit and Continue! So many new features, you'll want to make sure you can hit the ground running. Or perhaps you have a question about what you are using today? Join the C# IDE team for a chat completely directed by your questions."

Lots of very cool new C# code-editing features will be coming your way as part of Visual Studio 2005. The team who is responsible for them will be at this chat to talk to you. See you there!

Chat Room: http://msdn.microsoft.com/chats/chatroom.aspx
Other Upcoming Chats: http://msdn.microsoft.com/chats/
Outlook Calendar Link: http://msdn.microsoft.com/chats/outlook_reminders/05_1117_MSDN_ide.ics

Detroit VS2005 Launch a Success!

I just returned from the Visual Studio 2005 Launch in Detroit, MI and I must say that it was an amazing turn out. The last number I heard was approximately 1,800 attendees.