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.

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.

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

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.

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.

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

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.