- Posted by Peter Himschoot on March 3, 2010
Team System 2010 introduces the concept of team project collections (TPC). A team project collection is, as it says, a collection of team projects, which can be managed individually. You can backup, move, delete, etc… each collection individually. Each collection will also have its unique work item ids, check sets, etc… Team project collections also change the way team foundation stores its stuff. Before it would use a bunch of databases, now everything connected is stored in a single database. One database per collection. You can easily find the database because it’s called Tfs_<CollectionName>. You ‘ll also find the Tfs_Configuration database containing all configured project collections (and depending on your installation a database for the analysis services).:
Project collections also solve a problem some of you might have encountered; TFS 2008 has an upper limit of 255 team projects. Now with TPC you just add another TPC when you reach the limit (I don’t know the limit of projects per collection, but I would assume it would be around the same…).
A TPC can also easily be moved to another team server/farm, or to another SQL server on the same farm, as long as you keep it on the same type of SQL server (enterprise, express, …). Documentation states you cannot move it to another kind. The way to do this is to first open the Team Foundation Administration Console, and select the Team Projects Collections tree item. To the right you should see all your TPCs.
Here you can also create new TPC's, but that should be obvious.
So to move a TPC you should first stop the collection. You’ll be asked for a reason:
And then you detach the collection:
Next you go through a verification step:
And then you click Complete:
Now the TPC is no longer connected to TFS, but is still there in SQL server.
So now you detach the database in SQL server, move it to another SQL server or TFS farm. You might first need to restart a couple of services, such as the build service.
So after attaching the database in SQL server, we now need to attach the database to TFS; go back to Team Foundation Administration Console, and click the “Attach Collection” button. Now choose your SQL server instance, and you’ll see all candidate databases:
Hit Next if you want to change properties such as the name/description:
And next again to see an overview.
So complete attaching, hit Verify to make sure everything is in order:
And then hit attach.
Eh voila!
Now the TPC should be in the list:
You can also split the projects in a single TPC to multiple TPCs (but not merge them, so be careful), but that will be for a later post.
- Posted by Peter Himschoot on February 28, 2010
In this blog post I want to talk about .NET 4 new Lazy<T> class. First of all, why would you need something called Lazy?
You can use it for data access for example; when you load a row from a database parent table. Would you need to load the child rows automatically, or delay until they’re required. Some systems will delay load automatically, or load all they can (but what then when the child rows have other relations to grandchild rows, etc…). This kind of delayed loading of data is just what Lazy<T> (or Lazy(Of T) when using VB.NET) supports.
It’s a great type to use when you have an object which is very expensive to create, and you only want to create it on first use.
Let’s start with an example; let’s say you have this big-ass class:
1: class BigAndExpensive
2: {
3: string s = "";
4:
5: public string GetTheData()
6: {
7: return s;
8: }
9:
10: public BigAndExpensive()
11: {
12: Console.WriteLine("BigAndExpensive is being created...");
13: for (int i = 0; i < 10000; i++)
14: s = s + ".";
15: Console.WriteLine("BigAndExpensive is finally created...");
16: }
17: }
As you can see, creating is very expensive (it will actually consume about 10 Gb of memory, triggering a lot of garbace collects).
Let’s create an instance of this class without, then with Lazy<T> and look at the performance:
1: BigAndExpensive be;
2: Lazy<BigAndExpensive> lbe;
3:
4: using (new MeasureDuration("Not using Lazy evaluation"))
5: {
6: be = new BigAndExpensive();
7: }
8: using (new MeasureDuration("Accessing non-lazy object's method"))
9: {
10: string s = be.GetTheData();
11: }
12: using (new MeasureDuration("Using Lazy evaluation"))
13: {
14: lbe = new Lazy<BigAndExpensive>(false);
15: }
16: using (new MeasureDuration("Accessing lazy object's method"))
17: {
18: string s = lbe.Value.GetTheData();
19: }
20: using (new MeasureDuration("Again accessing lazy object's method"))
21: {
22: string s = lbe.Value.GetTheData();
23: }
In order to use the Lazy<T> object you have to get it’s value property. When the lazy loaded value hasn’t yet been created, accessing the Value will create it.
The MeasureDuration class is a little timer taking advantage of the using statement:
1: class MeasureDuration : IDisposable
2: {
3: Stopwatch sw;
4: string what;
5:
6: public MeasureDuration(string what)
7: {
8: this.what = what;
9: sw = new Stopwatch();
10: sw.Start();
11: }
12:
13: public void Dispose()
14: {
15: sw.Stop();
16: Console.WriteLine("Measured duration of -{0}- took {1} ticks ({2} ms)"
17: , what, sw.ElapsedTicks, sw.ElapsedMilliseconds);
18: }
19:
20: }
The output I get on machine looks like this:
As you can see, creating a Lazy object is very fast, but of course as you can expect, using it the first time is just as expensive due to the creating process. Using it the second time is again very fast.
Now go back to the code, and look for the Lazy<T> constructor. Change the false argument to true:
1: lbe = new Lazy<BigAndExpensive>(true);
This will make the instantiation process of the actual instance thread-safe. This means it will be a little slower, but only during construction. Is it worth the price? If you’re using multiple threads YES YES YES!
Now let’s try to see what happens when many threads access an unprotected Lazy object (never be lazy AND unprotected :))
This is the code:
1: private static void UsingLazyObjectsFromMultipleThreads()
2: {
3: Lazy<BigAndExpensive> createMeOncePlease = new Lazy<BigAndExpensive>(isThreadSafe:false);
4:
5: ManualResetEvent youMayBegin = new ManualResetEvent(false);
6: AutoResetEvent done = new AutoResetEvent(false);
7:
8: // create a lot of threads that will use our object all at once
9: for (int i = 0; i < 20; i++)
10: {
11: Thread t = new Thread(() =>
12: {
13: youMayBegin.WaitOne();
14: Console.WriteLine("Thread {0} getting data", Thread.CurrentThread.ManagedThreadId);
15: using (new MeasureDuration("Multithreading"))
16: createMeOncePlease.Value.GetTheData();
17: done.Set();
18: });
19: t.Start();
20: }
21: youMayBegin.Set();
22: // wait for all threads to complete
23: for (int i = 0; i < 20; i++)
24: done.WaitOne();
25:
26: }
I’ve now used the named argument feature of C# 4.0. In this case it make the code a lot clearer doesn’t it?
So what does the code do. It creates 20 threads which all first wait for the “youMayBegin” event. This way all threads will start running at the same time. Then they each access the “createMeOncePlease” lazy instance, so some of them will start to create the instance (because it hasn’t yet been created). Then they will all signal that they’re done so the main thread can stop too.
So let’s run the code (making sure the isThreadSafe is set to false). I get this:
This is bad. Very bad. Instead of calling the constructor of my very expensive object once, it calls it several times. why?
Think about lazy’s possible thread-unsafe implementation:
1: class Lazy<T> where T : class, new()
2: {
3: T instance = null;
4:
5: public T Value
6: {
7: get
8: {
9: if (instance == null)
10: instance = new T();
11: return instance;
12: }
13: }
14: }
When you run the if statement on multiple thread, each will evaluate to true, then each will create an object and overwrite instance’s value.
So what is the solution? Simply pass true for the isThreadSafe argument.
Running this code once more looks like this on my machine:
Good. My expensive object only get’s created once. But why are the calls soo expensive after all. That is because when we access Value, only one thread will be allowed to create the instance, but the other Value calls will need to wait for the first one to complete. If you insert another call using Value you’ll see the speed is very fast.
If you only need initialization to be thread-safe, or only access to the object in a thread-safe you you can also use the contructor taking a LazyThreadSafetyMode enumeration:
1: None = 0,
2: PublicationOnly = 1,
3: ExecutionAndPublication = 2
What if your expensive class requires special construction, like a special constructor? Then you can use another constructor of Lazy<T>, one that takes a delegate( Func<T> ) so you can create your object your way.
1: Lazy<BigAndExpensive> createMeOncePlease =
2: new Lazy<BigAndExpensive>(() => new BigAndExpensive());
- Posted by Peter Himschoot on February 23, 2010
What developer today can live without intelli-sense? Of course I mean developers who have used intelli-sense before (if you don’t know something how can you miss something?). However finding a member in Visual Studio 2008 requires you to know the first letters of the class/method/… I’m quite sure you sometimes now a class contains a certain word, but can’t remember the beginning.
Now the new and improved intelli-sense in Visual Studio 2010 allows you to see any member containing a certain substring. For example when you type “opt”, you’ll get this:
But it even gets better. Try typing “AD”. Because .NET uses Pascal casing for all members, when you type the capital letters it will show you which members contain these same capital letters (and same order):
Love it! This also works in other places, for example in the Navigate To window!
With following code,
1: class WebDeveloper
2: {
3: }
4:
5: class Program
6: {
7:
8:
9: static void Main(string[] args)
10: {
11: WebDeveloper dev1 = new WebDeveloper();
12:
13: }
14: }
opening the Navigate To window (use Ctrl-comma for example, and typing WD in the search box will show like this:
Oh, and selecting the WebDeveloper class will automatically highlight every other use of it:
Cool!
And don’t you hate it when you start typing a method name you haven’t declared yet. By default Visual Studio will list a couple of suggestions, and when you commit (by pressing space of “(“) Visual studio inserts its own suggestion (and then you need to Undo (Ctrl-Z) to make Visual Studio keep whatever you were typing.
So for example, when you have a variable s of type string, and then you type s.c intelli-sense will show the following. If you now press space, by default you’ll get s.Clone.
But now you have auto-completion suggestion mode. In this case Visual Studio will not insert its own suggestion, but will keep your typing instead.
If you do want to insert the suggested method, simply press TAB instead of space of open bracket. From now on this will be my default mode of working…
- Posted by Peter Himschoot on February 7, 2010
Download VS2010 RC here.
And soon available for everyone tomorrow!
- Posted by Peter Himschoot on February 5, 2010
As promised in my previous blog on Gated Check In, in this blog I’ll discuss using multiple builds with gated check in.
So what happens when you check in (using gated check in) and there are multiple build definitions targeting the solution? Well, Gated Check In will then allow you to choose between the different build definitions; for the moment Team Build does not allow you to filter the build definitions that are shown:
In my example I’ve created a second build definition that doesn’t run tests, so you can select this one when you need to check in code without running tests…
- Posted by Peter Himschoot on February 4, 2010
Breaking the current team build is not a good thing. This will cause many people to lose time while the build is being fixed. So how can you avoid this? One way is by only checking-in on isolated branches, which allow you first to test if everyone’s changes build together.
But, remember that Team System Source Control has that one-click branching feature, called shelving? Well, now if you check in VSTS can take your changeset and merge it on a shelve with the current version in source control. It will then launch a build (using Team Build) and if this is a successful build (depends on the build) will allow you to check-in.
Let’s have a look at this:
To try this you first have to have something in Source Control. For example this simple library project and class:
1: namespace Lib
2: {
3: public class Code
4: {
5: public int Test(int i, int j)
6: {
7: return i + j;
8: }
9: }
10: }
I’ve also added two unit tests in a test project:
1: [TestMethod()]
2: public void Test_2And3_Returns5()
3: {
4: Code target = new Code();
5: int i = 2;
6: int j = 3;
7: int expected = 5;
8:
9: int actual;
10: actual = target.Test(i, j);
11: Assert.AreEqual(expected, actual);
12: }
13:
14: [TestMethod()]
15: public void Test2And4Returns10()
16: {
17: Code target = new Code();
18: int i = 2;
19: int j = 4;
20: int expected = 6;
21: int actual;
22: actual = target.Test(i, j);
23: Assert.AreEqual(expected, actual);
24: }
Make sure all of this is currently checked in.
Now go to Team Explorer, right-click on Builds and choose “New Build Definition…” The Build Definition dialog should open. Call your build GatedCheckIn (although the name doesn’t matter, I’ll be using it later).
![image_thumb11[1]](http://blogs.u2u.be/peter/image.axd?picture=image_thumb11%5B1%5D_1.png "image_thumb11[1]")
Now go the the Trigger tab; here is where the new Gated Check-in can be selected:
Next go to the Workspace tab, and select the folder containing your solution (both the library and test projects).
Next come Build Defaults, the usual (you might need to create a shared folder so you can map to it here; make sure the Build Service account can access it):
I’ve left everything in the Process tab to its default value, but you might want to double check the Automated Tests. Team Build will run all tests in all assemblies whose name contains test.
Also note the Fail Build On Test Failure setting; you can change it to true to ensure nobody can check-in with failing tests.
If you’re using the Layer Diagram, you can also validate it during the build.
And finally Retention Policy, where you can choose whatever you like.
Close the window and save your changes.
You might want to test your build definition by queuing it. It should work:
Ok, now let’s make a change to our code that would break the build by failing one on the tests:
1: namespace Lib
2: {
3: public class Code
4: {
5: public int Test(int i, int j)
6: {
7: return i - j;
8: }
9: }
10: }
I’ve simply changed to + sign into a – sign.
Now open the Pending Changes window and click the Check In button. The Gated Check-in dialog should appear:
Note the Shelveset and Build definition. If you have more than one build definition, things change, we’ll look at this later.
Also note the Preserve my pending changes locally. This works exactly the same way as normal shelving, so if you leave it checked, your changes are left on your machine. If the build fails, everything is the same. If you uncheck it, your changes will be shelved, but then you will have to make sure you reconcile back with the server’s version after the check in succeeds.
Ok, Click the Build Changes button. A build should start. Open the Build Explorer if it doesn’t do so automatically:
The tests failed, so TFS decides that the check in failed:
Change the code back to use the + sign. Check In. This should now succeed.
Now this really become interesting if two developers check-in conflicting changes. We can emulate this using two workspaces. So I’ve setup another workspace mapped to the same project. To do this, go to Source Control Explorer and open the Workspace: drop-down list:
Select Workspaces…, this should open the Manage Workspaces dialog (you will have other names for any workspaces you might already have):
Now pick a name, and in the Working Folders select your project mapping, one for the server, one for on your disk. For example:
Then get all files locally (TFS will suggest this anyway). To switch between the workspaces you simply select it from the “Workspace:” dropdown list.
In one workspace rename the Test method in the Code class to Add. Use the Rename feature to ensure all references are renamed as well… Run all tests, they should succeed. Don’t check in yet.
Open your solution in the other workspace. Change the implementation of the Test method like this:
1: public class Code
2: {
3: public int Test(int i, int j)
4: {
5: if (j == 4) j = 8;
6: return i + j;
7: }
8: }
And change the unit tests as well:
1: [TestMethod()]
2: public void Test2And4Returns10()
3: {
4: Code target = new Code();
5: int i = 2;
6: int j = 4;
7: int expected = 10;
8: int actual;
9: actual = target.Test(i, j);
10: Assert.AreEqual(expected, actual);
11: }
Run all tests. They should succeed. Then check In. A build should start. While that is running check in your other changes (other workspace). Because your first check in is still running you shouldn’t see any conflict with your other changes. Actually, both builds should work, because the second build will merge the first build’s changes in the workspace, and they auto-Merge…
Let’s try to really break it now. In one workspace add another method to call the Add method (reconcile the workspace first, or do a recursive get-latest version):
1: public class Code
2: {
3: public int Add(int i, int j)
4: {
5: if (j == 4) j = 7;
6: return i + j;
7: }
8:
9: public void OtherMethod()
10: {
11: int x = Add(3, 2);
12: }
13: }
Then in the other workspace rename the Add method again. Check this workspace in, then the other workspace. Because the extra method doesn’t get the Add method renamed, the build will break:
Merge your code with the current check in code, and retry. This should now succeed.
- Posted by Peter Himschoot on January 29, 2010
The jump list feature in Windows 7 makes it really easy to find the documents you were working on for each application. Just go to the taskbar and right-click the application. If your application has been enabled for jump lists (and they should, it is really easy to enable this using some API’s) then you should see a list of recently opened items. One day I started noticing I didn’t have any jump lists any more. Luckily the problem is easy to fix. Open your taskbar properties and go to the Start Menu tab. Check the “Store and display recently opened items in the Start menu and the taskbar” you you should get them back. I must have disabled this by accident…
- Posted by Peter Himschoot on January 26, 2010
I’m happy to say I’ll be speaking at TechDays 2010 in Belgium and DevDays 2010 in the Netherlands.
In Belgium I’ll be doing one session on “What is new in WCF 4” and one session on “Workflow Foundation 4”.
In the Netherlands I’ll do on session on “What is new in WCF4” and one on “Developing for Windows 7 with the Windows API code pack”.
- Posted by Peter Himschoot on January 24, 2010
So what does Visual Studio 2010 bring for testers? A whole lot! Especially the new test environment, where you can create a test plan to validate the quality of the software you’re building. A test plan is a collection of test cases, which you can then run. While running the system keeps track of a whole lot of things, including code coverage and IntelliTrace information. And finally this application allows you to examine the combined results of all tests, to see how your development effort is doing.
So again: A test plan is a collection of test suites, used to test a certain iteration in your project. A test suite is a collection of test cases to test a certain part of your project, and a test case is a test for a project feature. A test case is basically an UI test running in a specific environment. To model this, Test and Lab manager also allows you to define a test configuration, which is a certain environment for your code, for example Windows 7 with IE8, or Windows XP SP2 with IE7.
Running Test and Lab Manager
First time you run this application it will ask for your Team Foundation Server (TFS) and after that, for the Project Collection and Team Project:
Ok, next step it will ask you for a test plan; since there are none you will have to create a new one:
Then click “Select plan >”.
This opens the test plan.
if you want you can change some of the properties of this test plan by clicking on the properties tab:
Here you can change the iteration for example, or the test settings.
With test settings you can change how your tests will be executed. For example in the Local Test Run settings you can change the diagnostic data adapter, which record data from your test run. For example is you want an action recording, event log entries, etc… You can also use it to emulate certain environments, for example running low on memory. You can even create your own data adapter.
This first page allows you to change the name, and choose between running a manual or automated test.
On the second page you can define the roles. You define a role for each tier to use to run tests and collect data. One the local settings you can only have one role, your own physical machine. If you want to use roles, you will also have to define environments.
Here you can define what kind of data you want to gather. For example, the Action Recording will record each action taken during the test, making it easy for another person (typically a developer) to understand what happened during running the test. The Action log is a text version of the recording. IntelliTrace will allow a developer to load the IntelliTrace log and step back in the code, to see how the error came to be.
Go back to the Contents tab.
Now we’re ready to test some of our user stories (from now on I will be using User Stories, but this could just as easily be called a requirement or anything else to denote a certain needed functionality of your software system). Test cases are grouped into test suites. Per test plan you have a default test suite, but you can also create a test suite for a specific user story, copy a test suite from another test plan, create a nested suite or create one from a query:
If you select “Add requirement"to plan” you will need to select a user story. This user story is now associated with this test suite. This will allow reporting to figure out which tests have ran for which user story.
Now we’re ready to add a test case, so click the New button. The New Test Case dialog should show:
Add the four steps (please note that we’re doing this for the sake of the demo, normally your requirement should not be to crash :) ). Save it.
Click on the Tested User Stories tab: the User Story should be there. Save and Close.
A couple of other things you can now do is to assign it to a tester, and/or change the configurations:
Let’s run the test. First open the Test tab: 
From here you can see all test cases for a test suite:
Select the test case and click on the run button. The Test Runner should open:
Check the Create action recording button and hit Start Test. Do as the test case says, and try to use a repeatable way to start the application (for example using the start menu). The first and second step should not be a problem, so click the drop down boxes to the right of each step to indicate success:
Now make the third step fail. You’ll need to enter a comment why it failed. Then click the End Test hyperlink button. You’ll see test center gather some information.
On top of the test runner window you’ll see a toolbar. Click on the Create Bug button:
You’ll see that most of the fields are automatically filled in. You might want to change the Severity for example, and maybe assign it to a certain tester, but that is all… Click Save. Check out the information included in the System Info, and All Links tab. Close it.
Remember me asking you to start the application using some repeatable way? Well, try and click on the play button. Your test should replay again. This makes it easier to re-test later.
Coming back to Test and Lab Manager. The test case failed so now the UI updates to show this:
If you have more than one test, the bar will color depending on how many succeeded, failed or are still in progress.
Later you can come back and verify if a bug still exists by using the Verify Bugs tab:
Go back to the Plan tab, then open the properties. Now you should see an overview:
Back to Visual Studio, so close the Test and Lab Manager. Go to the Team Explorer and open the My Bugs query. You should see the bug we created before. Open it:
Go to All Links, and open the IntelliTrace log (.tdlog). With it you can now replay the bug, just like in my previous post on IntelliTrace. If this doesn’t work, go back to the test settings. You might also like the Video feature, so you can replay the user’s actions!
- Posted by Peter Himschoot on January 23, 2010
Visual Studio 2010 now has a cool little feature I want to show you. When you’re debugging WPF applications, you sometimes need to see the controls and their hierarchy. Now with VS2010 this is easy. Simply use the magnifying class (the visualizer feature) and select the WPF Tree Visualizer:
This will show you all the controls with their properties like this:
In the left pane you get the tree view of controls with a rendering of the selected control, at the right side you get all properties of the control.