Introduction

The SDK style projects are the new format that first appeared for .net core, but actually can be used also for nearly any type of projects in the .net world. The old style, or what we could call legacy style, is a very complex style, and it is not uncommon to be the cause of merging issues, and also can cause all sorts of weird behavior. Both styles for a C# project has the extension csproj, even if their content is so different.

The NUnit 2.X framework have been superseded by the NUnit 3 framework several years ago. Each framework "family" needs a separate adapter, one for the V2 and one for the V3. The V3 have been maintained continuously, and have 3-4 releases per year. The V2 adapter however, has not been updated since mid 2017.

The thinking have been that developers should move to the V3 version of the framework. Over time that has happened, but there are still some that need the V2 version for various reasons. Although the V3 framework is an enhancement of V2, there are some breaking changes between them. And for some systems those prevents upgrading.

Background

Naming

The new format: SDK-Style format seems to be in favor, although Lightweight format is also used.

This post came about as a result of a an interesting question raised by my good friend Richard Hundhausen in Accentient. It turned out into some very interesting observations, and a few ways of handling this.

Background

When you’re starting up a new git repository for a Visual Studio project, you need a .gitignore file that matches. The gitignore file ensures that working files and folders that are not to go into source control are kept out. As Visual Studio and its extensions are growing, this list of files and folders are increasing. You need to have a gitignore file that at least matches the version of Visual Studio you’re using. Most developers notice files that they don’t think should be in source control, and exclude those (and then adds them to the gitignore file they have), but in many cases they don’t even know what that file is for, and it is inadvertently added in. Normally not causing any problem locally for that single developer, but then it may fail for the next developer down the line, or it may fail during CI builds. So it is much better to get the correct and full gitignore file when you start up your project. Less work later! And what could possibly go wrong?

NUnit as a project has a tradition of keeping backwards compatibility. It ensures that even if you stay on a earlier version of Visual Studio, .net FrameWork, or whatever it is, NUnit should continue to work even with upgrades of NUnit.
So also for the NUnitAdapter. It should work on any version of Visual Studio after the 2012 version. We have managed to maintain that. However, over time it has become harder and harder to verify the compatibility. Microsoft has increased their release pace, and the number of versions and variations of Visual Studio has subsequently increased tremendously over the last years. We have not found an easy way to test all the possible variations, so have had to do a set of minimum tests, then respond quickly when someone raises an issue. Fortunately, there have not been many of those. We rely to a large degree on peer reviews using pull requests, which have weeded out most of these issues.

Once upon a time it was declared that an Assert statement should have constraints given as AreEqual and AreNotEqual. Further it was declared that it should be written in the opposite way of how a developer will think, that is with the expected value first and the actual value last. Why this was made so, is still unclear.

And then we end up with tons of code like:

Assert.AreEqual(“Zulu”, zulu.Name); Assert.AreEqual(“Z - Zulu”, zulu.Description); Assert.AreEqual(FlagType.Signal, zulu.Sort); Assert.AreEqual(0.7, zulu.AspectRatio);

NUnit has a very rich and readable constraint set.  Normally you don’t need to do anything. But, there are some cases where it would be nice to be able to tweak these constraints.  You can always wrap them and extend them that way, but then you lose all the other good stuff, like chaining.  What is not so well known is that you can extend the existing constraints, they are **designed** to be extendable!   In this post I will show how you can do that easily.

The former post in this series showed how you could add aliases to the git command line, and showed how some simple aliases can simplify your command line work.

This post show how you can extend that to work more actively with the Azure DevOps (formerly known as VSTS)  server hosting your repository. (If you don’t have an account here, please consider doing that, it is free for modest individual use!)

You can do all of this from the combination of Visual Studio, and the web browser, but going through all those UI’s is like a good friend said: “and after 56 more clicks…..".   Using the command line is just so much faster - but in order to be effective the number of parameters must be cut down to something manageable.  And that is what this is about!

The most basic Git commands are built into the Visual Studio Team Explorer.   The Team Explorer will cover your basic needs, but once you get beyond that, you will need to drop down to the command line.    The commands are more explicit there, and you have more options, but you will soon tire of having to repeat the same basic commands again and again.  Enter the Git aliases – and you can easily make your most used commands so much more short and effective. 

Test Adapters come in two flavors, VSIX based and Nuget based. The VSIX based are installed as extensions to Visual Studio and therefore will apply to all solutions you load, The Nuget based adapter packages must be installed at least into one project in your solution and will only work for that solution.

All versions of Visual Studio have supported both flavors, but from Visual Studio 2017 Update 15.8 (Preview 4) the VSIX based adapters for C# and Visual Basic will be deprecated.

I have had a need to have more easy access to information on how to do certain stuff, and have some easy access to simple code blocks, or templates, I can copy/paste.  A blog post is for me somewhat more extensive, and that format was not really suited for smaller notes.  So I decided to write them down as “recipes”, which is a small post, larger than a post-it, but smaller than a full blown blog post.

It is time to reestablish my list of recommended VSIX extensions to Visual Studio, for 2017 and higher.   The list of tools you install now with VSIX is less than before, since so many more tools are available as nuget packages, but there are still some that are very helpful.  The list below show some of the ones I have found most useful.   I have also added a few non-VSIX tools, but which also installs into Visual Studio.

When your TFS/VSTS CI build is also used for a pull request, you often want to enable more checks before you let this go into the master (or any target) branch, and fail the build if these raise warnings.

It can be extra tests you want to run, code quality checks,  process checks, and  you might want to block the pull request if you have warnings from these.

Setting a single test task to fail could be done, but that only works well if you have a single step, with multiple tasks you will have build stops for one and every step, so it also reduces the error reporting granularity.  And, it is nice to be able to see what is an absolutely blocker, red, and what is quality issues, yellow.

User dumps are powerful diagnostics you can enable when an application crashes, and in particular when you see no obvious reason for it to crash.

In my case I have been struggling with Visual Studio crashes, and have been reporting these back to Microsoft.  The devs there love user dumps, because they show the exact state of the application when it crashed.   A user dump can be opened in a debugger, to reveal call stacks and lot of other useful information.

The Visual Studio Test Explorer can be a bit picky about showing tests.  There are multiple reasons for why they don’t always show up when you expect them to do, and most of the cases are PEBKAC type of issues.  That doesn’t mean it is easy, there are just becoming too many variations, and Visual Studio does not tell you what is really wrong.

The different variations of targets and adapters doesn’t make this easier.  To help in diagnosing this, I have created the diagnostic flow chart shown below.   Further below you will find the comments for each block and how to rectify the issues, if you don’t already know.  The flowchart is mostly general, although I use NUnit as the default adapter in the examples.

Visual Studio 2017 lack a proper internal terminal.  The Command Line extension has been a good substitute, but it opens up in a separate window.  If you work with multiple Visual Studio at the same time, you loose track of which command window belongs to which Visual Studio instance.

Visual Studio Code has it's own Terminal window built-in, so why not Visual Studio itself?  Well, now it is here, a pre-pre tool called Whack Whack (named so because of how you open it).  

It runs default with Powershell, and if you have installed Posh-git with your powershell, it also lights up inside WhackWhack, which is super cool!  If you don’t know posh-git, it adds some cool extras to the command prompt for git, like shown above – you see the current branch and the git status straight off the command prompt and tab completes for commands and branches.

You can download the Whack Whack terminal from the Visual Studio marketplace, and the project is open sourced at Github.

The Visual Studio Test Explorer user interface have been nearly the same since 2012, with only a few minor updates.  One thing that have annoyed a few people are how the test names are displayed.   The Test Explorer have got a bit of critique on this, but it is not that hardcoded.  It can be tweaked!   With NUnit3 and the NUnit3TestAdapter version 3.8 you can configure this naming yourself, which makes for some interesting possibilities.

Introduction

You have all seen it, you have all done it: Written code using the static methods from the System.IO namespace for handling directories and files.   Or, you are maintaining legacy code where that usage is common in certain places.  And now the code is huge,  you have no unit tests, because unit testing classes that directly access the file system is just pain,  and the cost of a rewrite is too big.

When you do test runs with the Test Explorer in Visual Studio, you can select to use either a x86 or a x64 test runner.  Now, if you select to create an AnyCPU target for that component, it will not matter which one you choose, but if you select a target x86 or x64, the selected test runner has to match the selected target.  Otherwise no tests will be visible in the Test Explorer. 

Download:  IFix 1.7

When I start creating a new solution I normally want this in its own git repository, and I catch myself adding the same stuff over and over again.   And, I often get the folder structures wrong,  I seem to never get the hang of when and where Visual Studio creates a folder for the solution, why the solution ends up at the same place as the first csproj file, and I often end up moving things around to get it the way I want it.

This post is written for those going from TFS Version Control to Git, and is an introduction to a smart improvement in Visual Studio 2015 - Commit Amend. Command Line enthusiasts already know how this is done, but it may still be useful to see how this is resolved in Visual Studio.

In TFS VC  the checkin command is used to add files to version control. The command saves the file to the central TFS VC system. When using Git you operate on your own local git repository first - by committing changes to the local and then you push these changes to the external remote repository.

There has been an issue with growing databases due to test data and test attachments not being deleted.  I have an earlier blogpost ( also here)  on how to fix this, using a tool called Test Attachment Cleaner, and also containing a set of scripts you can run on your server to check on how your database sizes.

In TFS 2015 update 1 this was fixed by building a data retention policy in to the TFS.  This works both for on-premises and for VSTS instances.

Visual Studio is normally a very stable environment, but some times it might crash on you.  This might happen if you either install some new extension, or even if you update Visual Studio.  The latter can be rather annoying of course.

A “common” error message is the loading error, it says it can’t load some component correctly, like in the image below.

NUGET

The current version 1.2 of the NuGet adapters for NUnit works with the VS 2015 Preview (and earlier CTPs). 

You can find them here:  http://www.nuget.org/packages/NUnitTestAdapter/  and with framework: http://www.nuget.org/packages/NUnitTestAdapter.WithFramework/

Add one of these to your solution and it works without having the VSIX installed, both for VS2015 and for TFS build, including VSO build.  Note that you only need to add one of these to one of your projects in the solution. 

Go to Part 1 – List of Product Updates for information on Visual Studio and TFS 2013 updates

Looking for the VS 2012 product updates and extensions ?  Go to Visual Studio 2012 Product and updates (Part 1)  and Visual Studio 2012 extensions (Part 2)

Looking for the VS 2010 extensions ? Go to Visual Studio 2010 - List of Product Updates (Part 1) + Extensions (Part 2).

I just got into some strange errors after I had done a NuGet update-packages of some package.  The build of the solution after the update failed with a strange error on some numeric comparison which could not be done:

This one followed by an error list like this:

Looking for List of VS 2013 Extensions (Part 2)

Updated Oct 17th 2014: Visual Studio and TFS 2013 Update 4 RC

Looking for the VS 2012 product info and extensions?  Go to Visual Studio 2012 Product and updates (Part 1)  and Visual Studio 2012 extensions (Part 2)

Looking for the VS 2010 extensions ? Go to Visual Studio 2010 - List of Product Updates (Part 1) + Extensions (Part 2).

Looking for links to the Test Adapters.

The .gitignore file contains rules for what files and folders to exclude from git source control.  When you use NuGet you don’t want the binaries retrieved by NuGet to be included into your git repository.  The binaries (and other files) from a NuGet package is downloaded into a folder named packages by default.   You need to add some rules to the gitignore file to exclude this folder from the repository.

Download tool

Updated 3.July 2014:  Corrected pattern for NuGet, details in this blogpost. (IFix is in progress to be updated too, version 1.1 will have these fixes)

Is there anything wrong with the built-in Visual Studio gitignore ????

Yes, there is ! 

First, some background:

When you set up a git repo, it should be small and not contain anything not really needed.  One thing you should not have in your git repo is binary files.

Download tool

In version 2.7 of NuGet automatic nuget restore was introduced, meaning you no longer need to distort your msbuild project files with nuget target information.   Visual Studio and TFS 2013 build have this enabled by default. 

However, if your project was created before this was introduced, and/or if you have used the “Enable NuGet Package Restore” afterwards, you now have a series of unwanted things in your projects, and a series of project files that have been modified – and – you no longer neither want nor need this !  You might also get into some unwanted issues due to these modifications.  This is a MSBuild modification that was needed only before NuGet 2.7 !

This issue is resolved in the latest ReSharper release, version 8.2.0.2160, download here. 

The issue appears when using the Test Explorer to run tests in any of the frameworks mentioned in the title.  The tests are shown in the Test Explorer, but are not executed.  It may look like this:

Note:  The tests shown dimmed are NUnit and XUnit tests, which have the issue. The other tests are MSTests, which are not affected. The tests are discovered by the adapter, but not executed.

Go to Part 1 – List of Product Updates for information on Visual Studio and TFS 2013 updates

Looking for the VS 2012 product updates and extensions ?  Go to Visual Studio 2012 Product and updates (Part 1)  and Visual Studio 2012 extensions (Part 2)

Looking for the VS 2010 extensions ? Go to Visual Studio 2010 - List of Product Updates (Part 1) + Extensions (Part 2).

Looking for links to the test adapters, go to this blog post.

This post is continued here!

Looking for List of VS 2013 Extensions (Part 2)

Updated April 12th 2014:  Visual Studio 2013 Update 2 RC &  TFS Server 2013 Update 2

Looking for the VS 2012 product info and extensions?  Go to Visual Studio 2012 Product and updates (Part 1)  and Visual Studio 2012 extensions (Part 2)

Looking for the VS 2010 extensions ? Go to Visual Studio 2010 - List of Product Updates (Part 1) + Extensions (Part 2).

Download:  VS2012 Runsettingstemplate   VS2013 Runsettingstemplate

The VS2012/13 unit test feature can generate code coverage results.  It can do so for (nearly) any type of adapter you choose to use, MSTest, CPPTest (managed/native), XUnit and NUnit (but not Chutzpah (note 1)).

Assume you have a project with a set of unit tests included.  For this demonstration I have used multiple different test frameworks just to show that this applies to any of these frameworks.

You choose to analyze for code coverage:

Using NuGet in Visual Studio together with ReSharper may sometimes lead you into an annoying error where ReSharper indicates your code has an error, but the solution builds just fine.
This may happen if you have a set of NuGet packages, and you either just restore them, or delete them on disk and then restore again.  Your code ends up looking like this, note the red missing functions, which comes from the Moq library - which is downloaded from NuGet:

The last year I have written three blog posts for the Microsoft MSDN ALM blog on unit testing. The posts focused on the new test explorer with its abilities to run tests in multiple frameworks, and utilizing traits to filter what to run, both in Visual Studio and on TFS Build.  I covered the adapters for NUnit, XUnit and Chutzpah.

How to manage unit tests in Visual Studio 2012 Update 1 : Part 1–Using Traits in the Unit Test Explorer

Go to Part 2 – List of extensions and tools for Visual Studio and TFS 2012

Looking for the VS 2010 extensions ? Go to Visual Studio 2010 - List of Product Updates (Part 1) + Extensions (Part 2).

Looking for links to the test adapters, go to this blog post.

UPDATE  Nov 26th 2013:   Visual Studio 2012 Update 4

This information was formerly contained within my blog post on  List of extensions (Part 2), but it seems better to keep this separate now, since the cadence has increased tremendously for VS 2012, and the list grows very fast.

Go to Part 1 – List of Product Updates for information on Visual Studio and TFS 2012 updates

Looking for the VS 2010 extensions ? Go to Visual Studio 2010 - List of Product Updates (Part 1) + Extensions (Part 2).

Looking for links to the test adapters, go to this blog post.

UPDATE Aug 18th 2013: Updates: Visual Studio Tools for Git, TypeScript, ReSharper, TFS Power Tools, Code Contracts, Build Manager, Web Essentials,  Code Contracts, tangible T4 editor , Just Decompile, DotPeek   ADDED:  Inmeta AssociateRecentWorkItems , Unit Test Generator

During the summer and fall this year, me and my colleague Jakob Ehn has worked together on a book project that has now finally hit the stores!
The title of the book is Team Foundation Server 2012 Starter and is published by Packt Publishing.

Get it from http://www.packtpub.com/team-foundation-server-2012-starter/book or from Amazon http://www.amazon.com/dp/1849688389 

The book is part of a concept that Packt have with starter-books, intended for people new to Team Foundation Server 2012 and who want a quick guideline to get it up and working. 
It covers the fundamentals, from installing and configuring it, and how to use it with source control, work items and builds. It is done as a step-by-step guide, but also includes best practices advice in the different areas. It covers the use of both the on-premises and the TFS Services version. It also has a list of links and references in the end to the most
relevant Visual Studio 2012 ALM sites.

If you have projects created under Visual Studio 2010 (SP1), and mixed C++ and C# projects in the solution, and you are using other configurations than Debug/Release x86 you may hit a very strange situation when you run the Static Code Analysis, either alone, or as part of the build.

You may get into a situation which seems like things go in circles.  One error points to a place where it simply points back to the first one.  This is in fact, two kind of errors causing this behavior.

Background

You are opening a solution made in Visual Studio 2010 with VS 2012.  When you run Code Analysis you get a series of CA0053 errors, saying it is unable to load the rule sets from the Visual Studio 2010 directory!

In the Error window you get an error message saying “Code Analysis detected errors.”

Find the video HERE.

Updated June 28th 2012:  Marcel has blogged about this too.

Adam Cogan did a great Web TV interview with Marcel de Vries and myself on the topics of architecture and code quality.  It was real fun participating in this session.  Although we know each other from the MVP ALM community,  Marcel, Adam and I haven’t worked together before. It was very interesting to see how we agreed on so many terms, and how alike we where thinking.  The basics of ensuring you have a good architecture and how you could document it is one thing.  Also, the same agreement on the importance of having a high quality code base, and how we used the Visual Studio 2012 tools, and some others (NDepend for example)  to measure and ensure that the code quality was where it should be.  As the tools, methods and thinking popped up during the interview it was a lot of “Hey !  I do that too!”. 

Updated: June 7th 2012:  Cause for the issues found! Unsupported scenario having TFS 11 Beta side-by-side.  Uninstall TFS 11 Beta before or even after install of VS 2012 RC.

The Visual Studio RC has shown some install issues in some cases, particularly for those who upgrades from VS 11 Beta.  These issues are caused by also having TFS 11 Beta server installed on the same machine.  This is not a supported scenario.  What is good is that if you forget to uninstall TFS Beta 11 first, and get these issues, all that is required is to uninstall TFS 11 Beta, and VS 2012 RC will start working correctly!

Download from VS Gallery

In my work I meet many developers, tester and project managers, all using Visual Studio. When I ask them if they have updated it to the latest version, there are many who simply don’t know. Should you always update? YES, you should. The Visual Studio development teams are continuously making improvements to the product. The question also often comes when we notice that something doesn’t quite work the way it should, and we then realize it is caused by not having the latest update. The next issue then comes – how do we find out IF the latest version is installed. That should be trivial, but it isn’t.

This post is continued HERE.

Go to Part 1 – List of Product Updates for information on Visual Studio and TFS 2012 updates

Looking for the VS 2010 extensions? Go to Visual Studio 2010 - List of Product Updates (Part 1) + Extensions (Part 2).

Looking for links to the test adapters, go to this blog post.

UPDATE Aug 18th 2013: Updates: Visual Studio Tools for Git, TypeScript, ReSharper, TFS Power Tools, Code Contracts, Build Manager, Web Essentials, tangible T4 editor, Just Decompile, DotPeek ADDED: Inmeta AssociateRecentWorkItems, Unit Test Generator

Memory for managed code is handled by the garbage collector, but if you use any kind of unmanaged code, like native resources of any kind, open files, streams and window handles, your application may leak memory if these are not properly handled.  To handle such resources the classes that own these in your application should implement the IDisposable interface, and preferably implement it according to the pattern described for that interface.

Our free extension to Visual Studio , the folder based Build Explorer Version 1.1 has now been released, and uploaded to the Visual Studio Gallery and Codeplex. We have collected up a few changes and some bugs, as follows:

Changes:

• Queue Default Builds can now be optionally fully enabled, fully disabled or enabled just for leaf nodes (=disabled for folders).  If you got a large number of builds it was pretty scary to be able to launch all of them with just one click.  However, it is nice to avoid having the dialog box up when you want to just run off a single build.  That’s the reasoning between the 3rd choice here.
• Auto fill-in of the builds at start up and refresh  This was a request that came up a lot, and which was also irritating to us.  When the Team Project is opened, the Build explorer will start by itself and fill up it’s tree. So you don’t need to click the node anymore.
  • There was also quite a bit of flashing when the tree filled up, this has been reduced to just a single top level fill before it collapses the node.
  • The speed of the buildup of the tree has also been increased.
• The “All Build Definitions” node is now shown on top of the list
• Login box appeared in certain cross domain situations. This was a fix for the TF30063 authentication problem we had in the beginning.  Hopefully the new code has that fixed properly so that both the login box and the TF30063 are gone forever.  Our testing so far seems to indicate it works.  If anyone gets a real problem here there are two workarounds: 1) Turn off the auto refresh to reduce the issue. If this doesn’t fix it, then 2) please reinstall the former version (go to the codeplex download site if you don’t have it anymore)  Write a comment to this blog post with a description of what happens, and I will send a temporary fix asap.

Bug fixes:

UPDATED March 24th 2016:   Test Data Retention is now added to TFS 2015 Update 1,  see this post for more information.

UPDATED Apr 15th 2013: Corrected to VS2012 Update 2

UPDATED Mar 23rd 2012: Added information about VS 11

UPDATED Mar 21st 2012:  Added info and link to VS/TFS 11 tool for getting the Test Attachment Cleaner, now included with the TFS Power Tools

UPDATED Jul 3rd 2013:  Added Art of Unit Testing Version 2

UPDATED Apr 11th 2013:  Added Instant TFS 2012 and Project Server 2012 Integration How-to

UPDATED Jan 12th 2013:  Added Prof TFS Server 2012, TFS 2012 Starter, Pro ALM with VS 2012 and VS 2012 Cookbook

UPDATED Dec 8th 2011:   Added Kanban book by David Anderson

“Send me a list of books to read” – that is what I am often asked.  No more, as this list is an answer to those request! 

Update: These have been superseded and included in later Cumulative Updates. See http://wblo.gs/cu8v for checking what you got and updates, or download the tool. Also see info about the updates and extensions here.

During the summer Microsoft has released two important hotfixes for the Testing tools. These two hotfixes solves 7 serious problems:

Note 1:  KB2544407

The 1.0.1 version of the Build Folder Extension is now out and can be downloaded from the Visual Studio Code Gallery  at http://visualstudiogallery.msdn.microsoft.com/35daa606-4917-43c4-98ab-38632d9dbd45 

Source code, discussions and issue tracking can be found at the codeplex site at http://tfsbuildfolders.codeplex.com/ 

Context menu

The context menu has been extended with the following commands, shown below:

Queue New Build… :  This pops up the traditional queue build dialog

We have just released a free extension for Visual Studio which adds a Builds Explorer with folders to the Team Explorer. 

The extension can be downloaded from Visual Studio Gallery or just search for Inmeta in Tools/Extension Manager.

The documentation and issue tracking  can be found at the codeplex site for the project http://tfsbuildfolders.codeplex.com/ and source code is available there.

Sometimes the tool is blamed for errors which are not the fault of the tool – this is one such story.  It was however, not so easy to get to the bottom of it, so I hope sharing this story can help some others.

One of our test developers started to get this message inside the test steps part of a test case in the MTM.

This post is about VS 2010, go here for the VS/TFS 11 extensions.

UPDATED Apr 9th 2012: VersionInfo, NuGet, Code Contracts 

UPDATED Oct 7th 2012:  New Visual Studio GDR

UPDATED Aug 31th 2012: New versions updated of ReSharper, NDepend, Web Essentials, Community Build Manager,  Code Contracts (March 2012), NuGet, ILSpy, DotPeek, Just Decompile, tangible T4 editor, LinqPad. Added the VersionInfo tool, so you know you have the latest update of VS 2010

When checking in code with workitems, one should connect them with workitems.  In some cases you need to check in multiple times before the item is resolved.  If you are too quick there, the checkin action causes the workitem to go to the Resolved state as this is the default state, if you don’t manually change it to Associate.  This default state can now – in VS 2010 – be turned around, so that Associate becomes the default action.

UPDATED: Feb 16th 2012:  Workaround #1 and #2 only works when run-time checking is not enabled. Added workaround #2B which seems to work.  Thanks to David S, Michael S and ZbynekZ for pointing this out, and sorry for not responding faster to this. Also added comments and overviews over what happens for different settings.

There have been several reports on problems with the Static Code Analysis (SCA) not adhering to the statements of the Code Contract tools. See these links: connect, forum1, forum2.

Introduction

Recently I have been involved in some projects to improve the software quality of their code base.  These code bases have been rather large, and in some cases consisting of both managed code, C# and C++, and Native code in C++. The reasons for improving the code base comes from a realization of the relationship between non-optimal coding practices and runtime incidents.  Runtime incidents can be anything from exceptions, out of memory conditions to functionality simply not working at all – some times with no apparent reason or messages appearing.

This summer Inmeta ASA, a leading Norwegian IT company, bought Osiris Data.  It means we’re now more than 150 consultants, up from 30 as we were.  It means a lot for us, as we now can take on larger projects, more projects and with even more colleagues we will have better competency on more areas.  It is also very exciting to be in a larger company, be “exposed” to more projects and more opportunities.

One of the great things with the Team Foundation server 2010 is the integration between the different parts. In this blog post, I’ll go through the connection between a Test Plan and the Build System.

A Test Plan should be connected to the builds being done in order to reap the most benefits from the system.  The test plan can be connected to the builds through the Properties page on the test plan you are working with, or you can connect it when you start a test run, by choosing “Run with options”.  The builds should also be properly set up, as shown below.

We (Mikael Nitell and me) got a whole track on the Norwegian MSDN Live tour this year.  We did these as a pair, and covered 4 cities over 4 days, 6 sessions per day, taking 8 hours to come through it.  The Islandic volcano made the travels a bit rough, but we managed 6 flights out of 8. The first one had to go by van instead, 7-8 hour drive each way together with other MSDN Live presenters – a memorable tour!

One of the 6 sessions I and Mikael Nitell is running on MSDN Live 2010 here in Norway is about Code Quality, and part of that session goes through the use of Code Contracts and Pex.  Both fantastic tools ! They can be used together, but are also completely independent from each other, and each can be used single.

Code Contracts  has to downloaded separately from VS 2010 (works also on VS 2008).   Start looking at http://msdn.microsoft.com/en-us/devlabs/dd491992.aspx . This download is a free download.   Code Contracts originates form the ideas of Bertrand Meyer – Design by Contract, take a look here.

Forms authentication is not what “they” normally recommend from a  security point of view, but in some cases it solves access problems. Particularly for companies which doesnt allow the Windows authentication protocol to pass, and those companies do exist.  To enable it in TFS 2010 is a bit more than a oneliner.  The recipe below shows you how to enable it. 

One has to change the web.config file for the Web Access. There are instructions within the file, but those instructions are incorrect and don’t work as intended.  This is probably leftovers from the 2008 version.

We have just upgraded our TFS production system to the RC from Beta 2.  Upgrading and Migration were done in 1.5 hour.  More than 75 team projects upgraded.  Our 30 internal developers and some more external will wake up to a new world tomorrow morning :-).

Martin Hinshelwood managed to beat us with some hours http://blog.hinshelwood.com/archive/2010/02/10/upgrading-from-tfs-2010-beta-2-to-tfs-2010-rc.aspx but we must still be one of the very first companies to move over! 

We have a two-tier solution, on raw iron, no hyper-v here, so we :

This issue has popped up for some after having upgraded from Team System Beta 2 to RC.  You have remembered to uninstall everything (as Jakob points out here: http://geekswithblogs.net/jakob/archive/2010/02/09/reember-to-uninstall-all-beta-2-stuff-before-upgrading-to.aspx but you still get the following error box:

saying Could not load type 'Microsoft.TeamFoundation.Client.TeamFoundationServerBase' from assembly 'Microsoft.TeamFoundation.Client, Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'.

At the same time, you see Power Tools functions are still there in Visual Studio, but no Power Tool appears in the Add/Remove programs.  This is some freak happening when uninstalling the beta Power Tools.

We’re running a new 2.5 hour seminar on the new Visual Studio 2010 and Team Foundation Server 2010 in Bergen Jan 27th.  See the agenda and invitation at the NNUG site. http://nnug.no/Avdelinger/Bergen/Moter/NNUG-Bergen---Januar-20092/

The seminar runs through a typical development cycle, and using demos demonstrates how Team System 2010 can be utilized to cover the whole lifecycle. The focus is on the new features in 2010, and we will try to cover as much ground as possible.  The seminar is nearly power-point free and very developer friendly !

A new version of the Branching guidance has been released (III), containing very good stuff on how to do branching. It includes labs, sketches and how-to’s.

See http://tfsbranchingguideiii.codeplex.com/

One of my favorites is the diagram poster shown below which I’ve used to explain the different branching strategies, and I find this very useful and easy to explain.  You’ll find it in one of the tabs of the Visio file included in the download package.

The Team System Rangers (http://msdn.microsoft.com/en-us/teamsystem/ee358786.aspx) just released a set of real cool Quick Reference Guidance sheets for the Visual Studio 2010 Team System at Codeplex http://vs2010quickref.codeplex.com/.  These guides collects up so much useful information in just a few slides.  I’ve always loved the branching guidance overview slides, explains so much in so little space.  Here is the same covering many more aspects.  A few….well, few is perhaps not the right word…there are quite a bunch of them, within these areas:

On codeplex the VSTS Rangers have published the Branching Guidance II (yes, a while ago, but still very true).  The basic idea there is the separation between 3 major branches,  the Main (or trunk), the Development and the Release branch.  One can elaborate on these and use multiple Development branches, and also a tree of release branches, but the basic principle can be summed up with these three.

Visual Studio 2010 (beta 2) can be connected to an existing TFS 2008 Server.  Much of the new great stuff is then not available, quite naturally.  But I was quite positively surprised that some stuff I had not expected to work in fact did.  Which of course means it’s client stuff more than server stuff. Anyway, here comes:

History across branches:  You can now see the history of a versioned item even it started it’s life in another branch, and even if you are connected to a TFS 2008 server.

In June we ran a free 2,5 hour seminar at Microsoft on the Team System 2010.  It went rather well, so it's being set up again, on September 15th.  It's being done as a practical demo case, we've "invented" a problem, and uses the 2010 to solve the problem. In the process of doing that, we're going through the Architect parts, the work items, the build system, coding, branching, code reviews with the static code analysis, testing with the new Test Edition ("Camano") and more.   We've done it nearly power point free :-).

In Visual Studio the settings for static analysis is done on the project property page, a tab called Code Analysis. You can set which code analysis rules you want to be active.  The default in Visual Studio 2008 is to use all.   If you run with this default setting you will generate a lot of "noise", since there are a large set of rules.  You need to create a set containing the rules you and your team find are suitable for your organization and project.  This set you have to apply to every C# project in your solution.  In Visual Studio 2008 there is no easy way to do this.  At Osiris we made an Addin to Visual Studio to ease this.  We defined the set in a separate file, and used the Addin to apply that to all projects in a solution.

We have run 10 seminars with myself, Mikael Nitell and Jakob Ehn on TFS 2008 during the last two years. These seminars were made from the point of our company's experience with the TFS system.  We debated different aspects of it, and showed people how we had chosen to solve the different issues that arose.  These seminars took in the range of 4 hours, and we've had around 700 people all in all participating in these seminars, with very favorable feedback. 

There has always been a controversy between modeling and coding.  All from the point where models are to be turned into code automatically, through the state where models are written and then forgotten after coding has started, to the point where one generates models from the code.

To me, code and model is representations of the same thing - the problem to be solved, or the solution to the problem.  And when the solution matches the problem, which sometimes happens, all is well.

All these three terms are used to describe the behavior of an application.  They come from different process methodologies, and have different meanings, characteristics and are intended to be used differently.

Larry Guger also discuss these aspects and several others in his blog entries http://continuouslyintegrating.blogspot.com/2009/07/use-cases-and-visual-studio-2010-part-1.html and http://continuouslyintegrating.blogspot.com/2009/07/beginning-use-cases-identifying-actors.html.  

The Use Case is the term used in UML and in the different Unified Process based methodologies.  See http://en.wikipedia.org/wiki/Use_case for a good overall description.  A use case is often looked upon as a more formal way of describing behavior, and which has to be accompanied by a detailed description following certain rules.  However, a Use case can in fact be as light weight or as formal as one wants it to be.  I find that this depends more on the process methodology one uses more than characteristics of the use case itself.

When I started blogging I made a decision to concentrate on technical stuff.  I would not write about personal things, not about what happened in my everyday life, not about my social life, not about personal trivia, but just keep it technical - write about software and software technology.  And keeping my personal life and my technical life separated seemed like a good idea, and shouldn't pose any problem what so ever. 

I was informed April 1st that I had received the MVP Award for Team System. It first appeared on the blogsite of Rune Grothaug, and later the same day a mail dropped into my Inbox from Microsoft.  I knew about the nomination, but when it materialized I still got very happy and excited about it.  It’s great to join such a group of talented people,  but it also makes me feel the pressure to do even more for and within the community.  I have always enjoyed sharing knowledge with other people, but this has normally happened in small groups. I’ve not been the typical writer or blogger, although I enjoy writing and communicating. Either I’m out of time, or I don’t feel the stuff is well enough prepared, or I’m just holding a bit back. The shy guy, you know….  

Jakob got out a cool checkin policy after a question on the microsoft forums about this. The policy ensures that you have run a code coverage, and that the coverage percentage is above a certain set limit.  See Jakob's blog for a description http://geekswithblogs.net/jakob/archive/2009/02/23/writing-a-code-coverage-checkin-policy.aspx

The code is available on codeplex, see here http://www.codeplex.com/TFSCCCheckinPolicy.

A build set is a set of builds running on the same solution or set of solutions, catering for different aspects of the Continuous Integration process.  Why a set of builds ?  Because one size doesn't fit all.  Something you want to run quickly and others you want to cover a lot of stuff.  This can be divided into a set of aspects.

The aspects can be divided into three major parts:

At the moment there are five different popular process templates, three from Microsoft official, one on Codeplex (by some Microsoft guys afaik), and one from Conchango.  The fields defined in the workitemtypes found in these templates belongs to a set of namespaces.  The System namespace is a predefined Microsoft namespace, with special behavior.  The other ones are in reality free text.  However, since some effort has been placed on defining these namespaces, and some of these fields are used in several reports, in mappings to Microsoft Project etc., it is wise to adhere to these definitions. It will at least reduce the work you have to do if you're modifying them, or defining your own types.  It is also wise to keep the fields named as equally as possible between types, and even processes, because it also simplifies querying across types. See http://teamfoundation.blogspot.com/2008/05/work-item-customization-tidbits-part-1.html for a great tutorial on how-to-do-it.

I like Code Metrics.  They give a certain "objective" evaluation of a piece of code.  You can use it for yourself just to make it pinpoint potential trouble areas, or just some code where you were a bit sloppy - happens from time to time......  And when you're going to do a peer review, it's much better to point to some numbers instead of  the "This code sucks....."-thing.   So when it finally arrived inside Visual Studio I was delighted. 

I did an article on Subsystem branching (http://geekswithblogs.net/terje/archive/2008/11/02/handling-subsystem-branching.aspx) as a result of a post on the Microsoft forums regarding this.

Further, at the PDC 2008 conference now, Grant Holliday made me aware of the TFS Dependency Replicator, which also is a way to solve the problem. It corresponds to the solution I named Solution 3B, however, it's not using the branch/merge facilities, so the TFS itself is not "aware" of the file copied. Anyway, a great tool !

I'm just soooo slow.  I must be the last geek to get a blog up and running. Anyway, being last is better than never.

Where to find me:

I'm often found at the Microsoft forums, Forums.Microsoft.com/MSDN mostly under Visual Studio Team System, but occasionally also under any of the more programming forums, like Winform, WPF, ASP.Net., C# or SQL.  My nickname there is OsirisTerje.

I got an audio technology site also, see http://home.online.no/~tsandstr/AudioStartsHere.htm, which contains information from my former life.