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.

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?

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!

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.

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.

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. 

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.

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.

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).

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.

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.

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.