Search results matching tag 'tsbt-dev'

IntelliTrace iTrace Files

ianhu — Mon, 16 Nov 2009 08:00:00 GMT

If you are not familiar with the new IntelliTrace feature in Visual Studio Team System 2010 than you might want to first check out either my or John Robbins’ introductions to this feature as a general overview of IntelliTrace would be helpful before digging into this article.

What is an iTrace file?

In my introduction article linked above I talked a little about how IntelliTrace captures the current state of the debugger at multiple points during a program’s execution and, when F5 debugging, allows you to debug back in time to previous debug states in your program. This in and of itself is a very handy feature, but in this day and age it’s often hard to have a bug with an easy and consistent repro that you can debug on a local dev box.

The solution to this lack of a local repro is that not only does IntelliTrace enhance your local debugging experience, but it also saves all the collected debugger data points into a trace log file (.itrace extension) that can then be opened and debugged using Visual Studio later and on a different machine. The analogy for this scenario is that of a black box in an airplane in that iTrace files provide a “voice from the grave” from crashed programs that allow for a developer to debug in and around the point of failure after the fact.

Integration with Microsoft Test and Lab Manager

One of the big new testing features being added in Visual Studio Team System 2010 is the Microsoft Test and Lab Manager (more info on MTLM on their blog site here). MTLM is a standalone tool that focuses on the tester role by providing a TFS-integrated UI for managing test cases and lab environments without the overhead of a full Visual Studio installation. Since one of the key focuses of IntelliTrace is to try to eliminate the “no repro” disconnect between developers and testers we knew that we needed to get IntelliTrace integrated with MTLM. This integration is accomplished via a combination of TFS and iTrace files. I’ll detail the scenario more in a future blog post, but at a basic level at anytime during a test run a tester using MTLM can choose to file a bug on a specific test step failure and when that bug is filed an iTrace file of all the recent debugging events and exceptions is automatically collected and attached to the bug. Then, when the developer opens up the bug in Visual Studio, they can just click the iTrace file linked in the bug and be debugging into the exact execution path in which the tester was seeing the failure.

iTrace files collected during debugging

Whenever you are running a normal F5 debugging session from the Visual Studio IDE with IntelliTrace turned on you are collected an iTrace file in the background. Now in this scenario you can pretty easily be using IntelliTrace features like browsing back in debug history without ever noticing that this file exists, especially since to keep your system from getting clogged with iTrace files we clean these files out when Visual Studio is shut down. So if you ran into something interesting while debugging from the IDE with IntelliTrace you will need to copy the iTrace file out from its saved location to keep it from being cleaned up. Just look under the following file path to see the iTrace files that have been collected during the current VS session: C:\Users\All Users\Microsoft Visual Studio\10.0\TraceDebugging. With both the IDE scenario and the MTLM scenario iTrace files will be truncated at a specific size (currently set to 100MB by default) to keep from filling up your hard drive. This truncation value will discard older events from the log and can be changed from Tools->Options->IntelliTrace->Advanced.

Collecting iTrace files from the command line

If you want to collect iTrace debugging files without having Visual Studio up and running we’ve provided the IntelliTrace.exe command line tool. IntelliTrace.exe will get its own blog entry sometime in the future but if you want to try figuring out how to get it running just try starting with the /? command for help. Intellitrace.exe is located in your Visual Studio install at “Team Tools\TraceDebugger Tools.”

Working with iTrace files in Visual Studio

(Note: All screenshots are from my current working build and will look a little different from Beta 2 builds)

Regardless of if you collected your iTrace file via MTLM, Visual Studio or IntelliTrace.exe when you first open it up in Visual Studio you will end up with a document that looks somewhat like the below.

Note that at this point we’ve just opened up the document summarizing the debugging session. No debugging session has been started and the time to open up the document should be pretty minimal. At the top of the document you will see a chart showing all the threads that were running during the life of this debugging session. Below that there are a series of lists containing more information about Threads, Exceptions, Test Events, System Information and Modules for the debugging session. Currently, the Exceptions list is expanded out and showing all the exceptions that were encountered during the debugging run. The exception that is currently selected in this list is represented in the thread timeline by a vertical red bar. This bar helps you match up exactly where in your program’s execution an exception was being thrown. In addition to supplying the thread, HResult and message of the exception we will list out the stack of each thrown exception in the textbox below the exceptions list.

Threads List:

The threads list provides a table view of the threads active during your debugging session. The actively selected thread will be highlighted in the thread chart above, and vice-versa.

System Info:

The system information section contains a set of information about the computer that this iTrace file was collected on. It seems pretty basic, but this info has already come in useful several times for me during my development work. In particular knowing the OS, the number of processers and the CLR version have been useful to me when investigating bugs that QA has provided me with iTrace files for.

Test Data:

I don’t have a picture of this right now, as I’m going to be speaking more about this when I cover MTLM integration in greater depth. When you collected an iTrace file via MTLM (since this file was not collected via MTLM the section is grayed out) the test data section will contain info on all the test steps that were logged via MTLM during the execution of the tests.

Modules:

As expected, this control lists out the modules that were loaded during debugging.

On all of these controls there is a search box above the list. If you are looking for a specific module or exception just start typing into one of those boxes to narrow down the results being shown in the list.

Starting a debug session from an iTrace file

Up until now we’ve been dealing with the information that you can glean from the summary page of an iTrace file. But while it can be quite informative the real point of the summary page is to allow the user to jump into debugging close to some point of interest. Lots of information can be collected during a debugging session and if you were to just jump into debugging an iTrace file blindly it could take a while to get to the correct location to start diagnosing a failure.

From an iTrace summary page you can jump into debugging from a thread, from an exception or from a test event (with a caveat that I’ll mention later for test events). For threads you can double click on a thread in the thread chart, double click on a thread in the threads list or click the “Start Debugging” button. Any of these options will start up the debugger and jump you to the last event that we collected on that thread. We chose the last event as in many cases an iTrace log captured a failure or crash so starting at the end point makes more sense than starting at the beginning of the log when all was running smoothly. For exceptions, you can either double click the exception in the list, or click the “Start Debugging” button below the exception list. Starting debugging on an exception will start the debug session exactly on the exception event selected (see picture below). Note that starting the session is a slightly slow process and it might take a bit for the debugger to get up and running. Test data function much the same as exception with the only difference being that since test events are not represented in our debugging UI debugging context will actually be set to the event in time nearest the selected test event.

This entry is mainly focused on the iTrace file and summary page so I’ll cover more about the IntelliTrace UI during debugging later. But as for now, you can look at the picture above and see that debugging has been started and our context has been set to the exception that I clicked in the summary page by looking at the source location and the autos window.

Up next

Coming up next I’ll be talking more about the various controls that you can use to move around in IntelliTrace debugging data and what data we will be showing in the Visual Studio UI.

Historical Debugging in Visual Studio Team System 2010

ianhu — Wed, 13 May 2009 07:00:00 GMT

Historical Debugging in Visual Studio Team System 2010

What is Historical Debugging in a nutshell?

If you’ve been in the development world for any length of time you’ve probably ended up in a situation like one of the following more than a few times.

· You’ve received reports of a crash from a tester, but on your local box you can’t get the bug to reproduce.

· You’ve received a crash dump from the tester along with the bug. But the callstack that actually caused the crash was just a cascading effect and you can’t trace the bug back to the root issue.

· The bug that you are currently working at resolving has an extremely long set of reproduction steps and you just accidentally stepped over the function that is returning bad data.

· You know that some part of your program is hitting the registry way too often, but while stepping through all that you see are .Net framework calls and you are unable to isolate which of them is doing all the extra registry work.

With Visual Studio 2010 Team System Editions we are introducing a new Historical Debugger aimed at getting rid of these developer pain points. The Historical Debugger plays a role similar to that of a black box in a plane. We keep track of important points in your programs execution and allow you to play back what happened at those points at a later time. We’re very proud of the current experience that we offer with the Visual Studio debugger so we’ve worked hard to surface all this new historical data in a way that is both useful and consistent with what you would expect from debugging in Visual Studio.

A little more depth on the Historical Debugger

In the previous section I’ve mentioned some scenarios that the Historical Debugger is meant to help solve but I’ve not mentioned much about how the Historical Debugger actually works aside from the black box analogy. To get an overview about how the Historical Debugger actually works I’ll do a quick little rundown on what the Historical Debugger collects, when it collects it and how you can view this information after collecting it. I’m going to keep to rather general terms for now, but in later blog posts we’ll dig down deeper into each area and talk more about how to configure and use the Historical Debugger from within Visual Studio.

What does the Historical Debugger collect?

Consider what you usually see in Visual Studio when you stop at a breakpoint during your program’s execution. At a basic level, you will probably see a source file with an arrow in the margin indicating where you currently are in program execution. You’ll probably also have access to a window showing your local and watch variables, a window showing your current callstack and some intellisense values for variables in your source code. Also, you might be digging into some more advanced windows like the threads window or the memory window available in the debugger. With a few notable exceptions the basic data that we will be collecting with the Historical Debugger will be a subset of the information normally available to you when doing standard live debugging.

The first thing that might strike you about this is “Isn’t collecting all this information going to slow down debugging my application by some crazy amount?” Trust me when I say that this worry is the proverbial Sword of Damocles that dangles over the head of our team. As big of an issue as this is, I think that we’ve come up with some pretty clever solutions to collect a useful amount of information without perturbing normal debugging patterns (more of these solutions will be mentioned in the “when does the Historical Debugger collect?” section below). A big part of this process was selecting what information is most commonly used during debugging but without picking anything that overly bloats our log files or slows down debugging too much. For starters, every time we stop to collect data we will grab your current code context and the current callstack. Second, we will get the value for any primitive data types that would appear in the locals or watch window at that point, we also get the primitive values for up to one level deep on any objects that would be in the locals or watch windows .Third, to the immense relief of those doing multi-threaded debugging, we will collect the data on the currently active threads.

When does the Historical Debugger collect data?

Above, we’ve talked a little about the debugger information that the Historical Debugger collects. But now we need to address how often this information is collected. After all, even if we are collecting a tiny amount of information collecting it too often will quickly lead to your program being slowed down to a halt and generating massive log files. To make Historic Debugging useful we need to provide the user with some solid default settings for how often they collect data and allow for some tweaking to adjust these default values.

When designing the Historical Debugger we based it around two main default levels of data collection. The first level of collection is based around the concept of collecting debugger data at specific points of interest in your program called diagnostic events. Diagnostic events are locations that we have selected as being common points of interest for customers when debugging a managed application. These diagnostic events are selected by Visual Studio and are meant to cover a broad range of programming types. An example diagnostic event that is included with the Historical Debugger would be RegistryKey.SetValue. If this diagnostic event is enabled you well collect a full set of Historical Debugging data every time that RegistryKey.SetValue gets called. These diagnostic events will act like checkpoints when you go back to examine your historical data. We of course allow for you to tweak which sets of diagnostic events will be enabled anytime you are debugging.

We think that we’ve selected diagnostic events that will be useful across a broad range of scenarios, but there will be plenty of times where the area you are interested in debugging after the fact will not have any diagnostic events of interest in it. For this scenario we’ve added an option to also collect debugging data at all method entry points in your program. Also, in this mode we will collect additional data on the parameters that were passed into each method. As would be expected this mode will increase the overhead that the Historical Debugger creates, so be aware of the effect it will have on your applications performance when debugging. Overhead aside, we believe that the data collected in this mode can be very useful especially in that it give a better idea of the shape of your program as opposed to just diagnostic events.

How do we show the Historical Debugger information?

For the most part the Historical Debugger information will be shown in the normal debugger windows such as the watch window, the locals window and the thread window that you already know and love. Although as mentioned above we do only collect a subset of total debugger information, so don’t expect to see everything when debugging historically. When you are in the middle of a normal debug session you will be able to just step backward to the most recent diagnostic event (or method enter / callsite if you are collecting them) from there you will be able to move about between the various points that we collected data during your current debugging session. As we dig into the new historical debugging UI in later blog posts I’ll talk more about the features that we’ve integrated into VS to help make this navigation easier.

In addition to being able to move back in time from a normal debugging session you can also save off historical debugging data in a separate .tdlog file and open this later or on another computer. This tdlog file is a key component of what we call the “no repro” scenario, the scenario in which testers pass off a bug to developers but developers are unable to recreate and debugger the error condition locally. We’ve provided integration with Camano (our new standalone test case management tool) and TFS to make it super easy for testers to attach tdlog files to any bugs that they file. Now when developers open up a bug they will be able to also open up the attached tdlog file and debug to any point where historical data was collected to help track down the issue.

What’s next?

This goal of this little intro was to tell you the very basics about the how the Historical Debugger works. In the upcoming weeks I’m going to start rolling out more articles that provide in-depth detail about how the Historical Debugger works and about how you can use it from Visual Studio 2010. Expect more pictures of how the UI will actually look and function as well as more samples about how Historical Debugging can help to solve common (and uncommon) programming issues.

First Virtual VSTS Usergroup September 18, 6:00 PM SLT

Charles_Sterling — Tue, 16 Sep 2008 07:00:00 GMT

Despite loving the book snowcrash I am not a huge fan of Second Life – but I am sure having a VSTS User Group in Second life will make all the difference in the world!

For more information please see:

http://www.tsug-ve.com/

TSUG VE for Second Life will meet online every month. We will target the third Thursday of each month at 6PM SLT but times and dates may vary based on holidays and speaker availability. Sign up and we will send you a monthly email reminding you of the time, the topics and speakers, and the SLURL to join the meeting.

We will start the meeting at the scheduled time but hope that members will find a reason to show up before the prescribed time to socialize, share stories and ideas, and help build community. Once the meeting is called to order, we will have a short ‘sharing session’. Approximately 15 minutes will be spent in a introductory, administrative or (hopefully) sharing session where members can share their successes, ideas and tools.

The Team System Users Group (TSUG) Virtual Edition (VE) is dedicated to creating a community for Microsoft’s Visual Studio Team System users and enthusiasts wherever they may be. The group will provide a social forum, education opportunities at all levels, and the ability to share our Team System successes and stories with each other.

Lots of Free VSTS Training

Charles_Sterling — Tue, 16 Sep 2008 07:00:00 GMT

I just found out last night that our partner group has done a great job of pulling together lots of VSTS. While the training is targeted partners/ISV’s it does not require you to be partner just to register.

Also despite some of the training is 2005 it is still very relevant!

-I am watching the Visual Studio Team Systems for Database Professionals (Part : 3) and Tim from IT Mentors is doing a great job.

Visual Studio 2008: Visual Studio Overview

9/22/2008 08:00 AM PDT | 60 minutes

Web Seminar | Level: Introductory

Available On-Demand Starting on September 22nd! High-level look at the product family, from the free Visual Studio Express Editions to the Visual Studio Team System. Matches different developer scenarios with a product or set of products.

Visual Studio 2008 Fundamentals: Application Lifecycle Management

9/22/2008 08:00 AM PDT | 60 minutes

Web Seminar | Level: Intermediate

Available On-Demand Starting on September 22nd! Application lifecycle management is about seeing the “big picture” when it comes to software development. This session highlights the business-case scenarios for Application Lifestyle Management and Value-Up Software Development, and demonstrates how Visual Studio Team System provides the best tools for the job.

Live Presenter Office Hour: Questions about Visual Studio Team System Tools

9/18/2008 09:00 AM PDT | 60 minutes

Live Q&A | Level: Introductory

Dial in during this live, one-hour session to discuss the tools in Visual Studio Team Suite. Topics to be covered include distributed systems designer (Architecture Edition), schema management tools (Database Edition), code analysis tools (Development Edition), code profiling tools (Development Edition) and testing tools (Test Edition).

Application Lifecycle Management (ALM) in Visual Studio 2008 Web Seminar Series

9/22/2008 08:00 AM PDT - 9/22/2008 09:00 AM PDT

Application lifecycle management is a comprehensive approach to envisioning, architecting, developing, deploying and maintaining a software solution. In this series, application lifecycle management will be examined from a number of perspectives, including the business analyst, project manager, architect, developer and tester.

Application Lifecycle Management (ALM) in Visual Studio 2008 Part 1 (Part : 1)

9/22/2008 08:00 AM PDT | 60 minutes

Web Seminar | Level: Advanced

Application Lifecycle Management (ALM) in Visual Studio 2008 Part 2 (Part : 2)

9/22/2008 08:00 AM PDT | 60 minutes

Web Seminar | Level: Advanced

Application Lifecycle Management (ALM) in Visual Studio 2008 Part 3 (Part : 3)

9/22/2008 08:00 AM PDT | 60 minutes

Web Seminar | Level: Advanced

Application Lifecycle Management (ALM) in Visual Studio 2008 Part 4 (Part : 4)

9/22/2008 08:00 AM PDT | 60 minutes

Web Seminar | Level: Advanced

Unit, Web, and Load Testing with Visual Studio 2005 Team System

On Demand | 60 minutes

Web Seminar | Level: Introductory

During this session, our presenter will cover the breadth and depth of the unit, web, and load testing technologies that are bundled with Visual Studio Team System. First, we will take a look at Unit Testing, how you generate Unit test skeleton classes from existing source code, how you modify the unit test classes to meet your particular needs, how you execute tests, how you analyze the code coverage for your unit tests, and how you view test results. Next, we will dive into Web Testing

Architecting Connected Systems: System Designer

On Demand | 90 minutes

Virtual Lab | Level: Advanced

During this lab, you will: Familiarize yourself with the System Designer In this lab, you will perform the following tasks: Create a new System Designer Project Model an existing application Integrate it with another system

Architecting Connected Systems: Logical Data Center

On Demand | 90 minutes

Virtual Lab | Level: Advanced

In this lab, you will perform the following tasks: Create a Logical Datacenter Project Expose and connect services across zones Import Web Server settings

Architecting Connected Systems: VSTS ASMX

On Demand | 90 minutes

Virtual Lab | Level: Advanced

In this lab, you will perform the following tasks: Build a Web Service Design a custom class Add Data Bindings Deploy a Web Service

Architecting Connected Systems: Team Foundation Server

On Demand | 90 minutes

Virtual Lab | Level: Advanced

In this lab you will learn to: Add a member to your software development team Migrate existing assets Model an existing application and integrate it with another system

On Demand | 90 minutes

Virtual Lab | Level: Advanced

Visual Studio Team System 2005 Hosted Trial and Basics Training

On Demand | 90 minutes

Virtual Lab | Level: Advanced

This Virtual Lab offers a free-form environment to explore Visual Studio Team System at your own pace. There is also a link to the Visual Studio 2005 Team System Basics Training documentation in the lab to try some of the tasks as well.

Microsoft Visual Studio 2008 for ISV Developers (4 parts)

On Demand

Introducing Visual Studio 2008 (Part : 1)

On Demand | 60 minutes

Web Seminar | Level: Intermediate

Visual Studio Code Name "Orcas" (4 parts)

On Demand

Visual Studio Team Systems Web Seminar Series (6 parts)

On Demand

Visual Studio Team System Fundamentals (Part : 1)

On Demand | 60 minutes

Web Seminar | Level: Introductory

Visual Studio Team Edition for Software Architects (Part : 2)

On Demand | 60 minutes

Web Seminar | Level: Introductory

Visual Studio Team Systems for Database Professionals (Part : 3)

On Demand | 60 minutes

Web Seminar | Level: Introductory

Visual Studio Team Edition for Software Developers (Part : 4)

On Demand | 60 minutes

Web Seminar | Level: Introductory

Visual Studio Team Edition for Software Testers (Part : 5)

On Demand | 60 minutes

Web Seminar | Level: Introductory

Visual Studio Team Foundation Server (Part : 6)

On Demand | 60 minutes

Web Seminar | Level: Introductory

Visual Studio 2008 Virtual Training (4 parts)

On Demand

Visual Studio Team Edition 2005 for Database Professionals (2 parts)

On Demand

Getting Started (Part : 1)

On Demand | 90 minutes

Virtual Lab | Level: Advanced

Managing Change (Part : 2)

On Demand | 90 minutes

Virtual Lab | Level: Advanced

Microsoft® Visual Studio® 2008 (8 parts)

On Demand

Introducing Microsoft® Visual Studio® 2008 (Part : 1)

On Demand | 60 minutes

Web Seminar | Level: Intermediate

Web Development with Microsoft® Visual Studio® 2008 (Part : 5)

On Demand | 60 minutes

Web Seminar | Level: Intermediate

Microsoft® ASP.NET AJAX and Microsoft® Visual Studio® 2008 (Part : 6)

On Demand | 60 minutes

Web Seminar | Level: Intermediate

Microsoft® SilverlightTM and Microsoft® Visual Studio® 2008 (Part : 7)

On Demand | 60 minutes

Web Seminar | Level: Intermediate

Building Better Web Services with Microsoft® Visual Studio® 2008 (Part : 8)

On Demand | 60 minutes

Web Seminar | Level: Intermediate

Microsoft Visual Studio Team System 2008

On Demand

The new version of Visual Studio Team System introduces many new enhancements across all team roles. These enhancements are also present in Visual Studio Team System 2008 Team Foundation Server. This six-part Web seminar series will provide an overview of Visual Studio Team System 2008.

Microsoft Visual Studio Team System 2008 System Introducing Application Lifecycle Management (Part : 1)

On Demand | 60 minutes

Web Seminar | Level: Intermediate

Microsoft Visual Studio Team System 2008 Team Foundation Server (Part : 2)

On Demand | 60 minutes

Web Seminar | Level: Intermediate

Microsoft Visual Studio Team System 2008 Architecture Edition (Part : 3)

On Demand | 60 minutes

Web Seminar | Level: Intermediate

Microsoft Visual Studio Team System 2008 Development Edition (Part : 4)

On Demand | 60 minutes

Web Seminar | Level: Intermediate

Microsoft Visual Studio Team System 2008 Test Edition (Part : 5)

On Demand | 60 minutes

Web Seminar | Level: Intermediate

Microsoft Visual Studio Team System 2008 Database Edition (Part : 6)

On Demand | 60 minutes

Web Seminar | Level: Intermediate

Microsoft® Visual Studio® Team System 2008

On Demand

Available On-Demand Starting August 25th! Microsoft Visual Studio Team System 2008 is a comprehensive platform for Application Life-cycle Management. In this series of courses we will examine each of the components that make up this platform: Team Foundation Server, Architecture Edition, Development Edition, Database Edition and Test Edition. Upon completion of these courses, you will have the fundamentals necessary to understand and use Visual Studio Team System.

Introduction to the Microsoft® Visual Studio® Team System 2008 Team Suite (Part : 1)

On Demand | 60 minutes

Web Seminar | Level: Advanced

Microsoft® Visual Studio® Team System 2008 Team Foundation Server (Part : 2)

On Demand | 60 minutes

Web Seminar | Level: Advanced

Microsoft® Visual Studio® Team System 2008 Architecture Edition (Part : 3)

On Demand | 60 minutes

Web Seminar | Level: Advanced

Microsoft® Visual Studio® Team System 2008 Database Edition (Part : 4)

On Demand | 60 minutes

Web Seminar | Level: Advanced

Microsoft® Visual Studio® Team System 2008 Development Edition (Part : 5)

On Demand | 60 minutes

Web Seminar | Level: Advanced

Microsoft® Visual Studio® Team System 2008 Test Edition (Part : 6)

On Demand | 60 minutes

Web Seminar | Level: Advanced

Updated Team Foundation Installation Guide for Visual Studio Team System 2008

Charles_Sterling — Mon, 11 Aug 2008 07:00:00 GMT

Team Foundation Installation Guide for Visual Studio Team System 2008
The Team Foundation Installation Guide for Microsoft Visual Studio Team System 2008, which includes Team Foundation Server, Team Foundation Build, Team Foundation Server Proxy, and Team Explorer

http://www.microsoft.com/downloads/details.aspx?FamilyID=ff12844f-398c-4fe9-8b0d-9e84181d9923&displaylang=en

Agile Presentation at the Testers SIG July 29th

Charles_Sterling — Thu, 31 Jul 2008 07:00:00 GMT

A couple of people asked about getting Amir's presentation from the Testers SIG Tuesday... Well Amir has graciously posted it to their site for your convenience:

http://www.netobjectives.com/files/events/download/AcceptanceTesting_0807TestersSig.pdf

Thanks Again Amir!

Testers SIG Recap (-and why DHCP didn't work in Virtual PC)

Charles_Sterling — Tue, 29 Jul 2008 07:00:00 GMT

Yesterday at the Testers SIG we had packed agenda and a packed house! Starting with an introduction to testing in Agile development by Amir at Net Objectives, did a walk through of recording a manual test, taking the recording and turning it into a coded test and finally adding additional functionality by recording control IDs and values to make decision points in our tests....

The feedback was great and the turn out was amazing (we almost ran out of donuts!!!).

Unfortunately the day didn't go without some hiccups. I wandered into the lab at ~11:00am to an unhappy lab tech and a nonplussed Naysawn Naderi. Friday Naysawn had everything working perfectly in a virtual environment. 9:00am Monday they copy the images to the 22 machines in the lab -and everything STOPS working. Unfortunately the real reason was masked by some networking issues in the building and the fact we were updating the images. After the session had started it was either Mark or Euan that noticed all the images had the same IP Address! -despite DHCP running <sigh>. I set two of the computers to use static addresses but it was too little too late for the portions of the lab connecting to TFS.

Turns out the dynamic IP address issued by the DHCP Server is based on the computers Network MAC address - and in this case all 22 computers were exactly the same. I did a quick look at the settings in Virtual PC to see if i could find a place to change this - but we don't have any UI for it<sigh>. If i had just hit the F1 key i would have found the answer(see below). I am guessing the only reason we hadn't hit this before is we just shipped the VHD over and created new the new VMC on the 22 hosts.

Cause: If you create an image of a host operating system that includes Virtual PC and virtual machines configuration files (.vmc files) and copy that image to another computer, each virtual machine configuration file included in the image contains a MAC address. The MAC address will not be reset automatically when you place the image on a new physical computer. As a result, the virtual machines that are copied onto the new computer will have the same MAC addresses as the virtual machines on the computer that was used to create the image.
Solution: Edit the .vmc file to remove the MAC address. Find the following line:
<ethernet_card_address type="bytes">0003FFxxxxxx</ethernet_card_address>
Remove the number so the line appears as follows:
<ethernet_card_address type="bytes"></ethernet_card_address>
After you remove the number, Virtual PC will create a new MAC address the next time you start the virtual machine.

An easy way to demo recording Ajax calls with the VSTS 2008 Web Recorder

Charles_Sterling — Sun, 20 Jul 2008 07:00:00 GMT

At Tomorrows .NET Usergroup meeting i want to demo a couple of the new features of Visual Studio Team System Test Edition. Namely the ability for the Web Test Recorder to Record AJAX requests and JavaScript pop-ups. To do this i needed to find an Ajax enabled site and an easy way to find a way of showing off recording Ajax calls. The easiest way i found was to create my own Ajax enabled page and compare the calls in the web recorder with the same page that isn't Ajax enabled. Starting with the non Ajax enabled page:

1. Create a New ASP.NET Web Site. File>New Web Site>ASP.NET Web Site. I left my website with the defaults for my machine: Location = File System and Language Visual Basic.

2. Add a Button and a Textbox to the default.aspx

3. In the click event handler of the button (just double click on the button) add the code Button1.Text = TextBox1.Text.

Protected Sub Button1_Click(ByVal sender As Object, ByVal e As System.EventArgs) Handles Button1.Click

Button1.Text = TextBox1.Text

End Sub

4. Run the Website to determine the URL for the page. For the mine it was: http://localhost:53814/WebSite2/Default.aspx

5. Create a web test and record clicking the button on the page. Test Menu>New Test>Web Test.

6. Looking at the Recorder - you can clearly see the HTML being recorded (See image below)

Converting this page to Ajax is as easy as easy as adding two controls - the ASP.NET Script Manager and the Update panel.

7. Open the page Default.aspx and from the toolbox and add a script manager above the button and an Update Panel

8. Move the Button and the Textbox into the UpdatePanel

9. Run a new Test Recording on the modified page. Menu>New Test>Web Test recording. Test Menu>New Test>Web Test.

10. You can see the exact same functionality is now being executed through Java Script -and being recorded whereas in 2005 the recorder would not have recorded those calls.

Andy Leonard talking about Team System Database Edition

Charles_Sterling — Sun, 20 Jul 2008 07:00:00 GMT

If you wanted to know more about Database Testing make sure and check out Andy Leornards show with Greg Low @ http://www.sqldownunder.com on Testing with Team Sytem Database Edition

Case studies galore!

jeffbe — Sun, 06 Jul 2008 07:00:00 GMT

Sometimes I get so heads down in the business of shipping our next version that I forget for a moment about customers using the current version. Fortunately, there are plenty of folks around me who work directly with customers on a regular basis such as the Team System Rangers and our very own Team System evangelist, Brian Keller…they don’t let me forget for very long. Recently I took a look at the updated list of case studies for Team System adoption and was happy to see that the list continues to grow by the week. According to the search engine at http://www.microsoft.com/casestudies, there are currently 102 (wow!) which are related in some way to Team System. Here are a few recent ones of note:

Chicago Bears: Football Team Connects with Fans, Drives Web Site Traffic with Desktop Application

‘The team-oriented features of Visual Studio Team System 2008 Development Edition helped us ensure that we didn’t introduce any defects while developing,” says Strawmyer. “For instance, the code profiling capabilities of the product quickly and clearly showed that there was no processor abuse or inconsistent use of memory.”’

Merrill Lynch: Merrill Lynch Creates Development Framework for Increased Productivity

‘Merrill Lynch upgraded to Microsoft Visual Studio Team System 2008 as soon as it became available. “We opted to use Visual Studio Team System because of its tightly integrated workflow, design, and development capabilities.”’

Starz Entertainment: Movie Provider Automates to Meet Higher Demand, Reduce Costs, Improve Brand Visibility

‘The collaboration and team features in Visual Studio Team System … make it faster and easier for a group of developers—we had eight working on MediaForge—to work together reliably.’

Thomson Reuters: Media and Information Provider Unifies Development Processes

‘Using Team Foundation Server, the team manages more than 2,000 work items, 70,000 changesets, and 200,000 files and folders. Since Online Services implemented Team Foundation Server, four other business units either have adopted it or have begun the implementation process.’

Anyway, there are many more out there if you’re interested in learning more about how other customers are using Team System.

Enjoy!