Excluding Integration and other tests when running Unit Tests locally in Visual Studio

Often, a solution may have both Unit Tests and Integration Tests. Unit Tests should be highly specific, and should be testing one class object. Integration Test could be vastly more complex and could use Selenium, or require a real database server, etc. Even if a solution doesn’t have Integration Tests, it may have slow Unit Tests. For example, I have a test that takes about 2 minutes to run because it is testing that when creating 10 million random strings, the character distribution is pretty equal.

I don’t want to either slow Unit Tests or Integration Tests to run every single time I build on my local dev box. I do have an automated build system and builds kick off on check-in. At that time, these slow tests will run every time. But locally, it is just an unnecessary delay.

Usually I am writing in a specific project and that project has specific tests and I can easily choose to only run tests in my current project. But what if I am updating a library that many projects use. I want to know quickly if anything is broke, so I need to run most of the tests in the entire solution.

Visual Studio allows for tests to be tagged with a TestCategoryAttribute.

You can mark different tests with different names: [TestCategory(“Slow”)], [TestCategory(“Integration”)], [TestCategory(“Performance”)], [TestCategory(“Selenium”)]


public void TestDistributionInTenMillionCharacters()
    // some code here

All other tests are left without a test category. Now, if you want to run all tests that aren’t slow, you can do this in Visual Studio Test Explorer by grouping tests using the “Traits” selection option.

Once you have marked all tests with an appropriate TestCategoryAttribute, you can sort by Trait. Now it is simple to click-to-highlight the No Traits group and click Run | Selected Tests.

Cleaning a customer folder in Visual Studio project

I have a Plugins directory in a Visual Studio project. I would like to delete all files from it when I clean.

Here is how I did this:

  1. Edit the .csproj file.
  2. Add the following to the very bottom of the .csproj file, just above the terminating </Project> tag.
      <Target Name="afterClean">
            <FilesToDelete Include="Plugins\**\*"/>
        <Delete Files="@(FilesToDelete)" />
  3. Save the .csproj file.

That should do it.

Update 12/14/2016:
You should be aware that when doing a custom clean, that in Visual Studio choosing Clean and then Build in two steps is not the same as doing Rebuild.

Clean <-- Cleans all projects Build <-- Builds all projects Rebuild <-- For each project, clean the project, then rebuild the project. So Rebuild is a huge problem and here is why: Since my code is pretty decoupled, my plugins don't reference the project hosting the plugins. So there is not dependency to guarantee the plugin-hosting project cleans and builds first. So when running reubild, a plugin might clean and build and then copy its files to the plugin directory. This could happen before the plugin-hosting project cleans and builds. So you can imagine that once the plugin-hosting project cleans and builds, the newly copied plugin files are cleaned. To fix this, I had to manually add a dependency or just not use Rebuild.

NuGet for Source Using Add As Link (Part 1)

Update: Projects using NuGet for Source with Add as Link. If you have a project using this please comment and let me know.

  1. https://github.com/rhyous/SimpleArgs
  2. https://github.com/rhyous/EasyXml
  3. https://github.com/rhyous/EasyCsv
  4. https://github.com/rhyous/SimplePluginLoader
  5. https://github.com/rhyous/StringLibrary

So I have a project on GitHub called SimpleArgs. This project makes command line arguments easy in a C# project. However, one of the requirements is to have an option to use the SimpleArgs dll or to have a single file executable. Yes, everything in one single exe, so referencing a dll is not an option.

So I created two separate NuGet packages from this project:

  1. SimpleArgs – This NuGet package uses a dll
  2. SimpleArgs.Sources – This NuGet package adds source

I use SimpleArgs.Sources the most. I quickly realized that NuGet for source does not scale. I have a Solution with four different projects where each project is a single file executable. The result was many copies of the SimpleArgs code.

    /Packages    &amp;lt;-- Copy of SimpleArgs source
    /SingleExe1  &amp;lt;-- Copy of SimpleArgs source
    /SingleExe2  &amp;lt;-- Copy of SimpleArgs source
    /SingleExe3  &amp;lt;-- Copy of SimpleArgs source
    /SingleExe4  &amp;lt;-- Copy of SimpleArgs source

That is 5 copies of the SimpleArgs source. Now at first, this doesn’t seem to be a big problem, in fact, it seems little more than an annoyance. One of the first changes I made, was to exclude the duplicate copies of source from Git. This helped but not enough. There are still problems that occur with multiple copies of source. For example, I ran into a bug with SimpleArgs. I fixed it, and then some time later I ran into the same bug with another project in the same solution. Oh, yeah. I only fixed the bug in one copy of the SimpleArgs source.

I decided the best solution was to reference the source using Add as link. Add as link is the ability to include a file into your Visual Studio project but without making a copy of the file in your project.

See: How to Add As Link in Visual Studio

I quickly changed the projects so the source was included not as copies but using the Add As Link capability. I manually did this. Then I finally pushed my changes to SimpleArgs Git repository and released a new version of the SimpleArgs.Sources NuGet package. That basically wiped out my manual work to Add As Link.

I needed the NuGet packages include the source using Add As Link for me.

How to create NuGet package using Add As Source

Well, to my dismay, NuGet didn’t have this feature built in. At first I was exciting about the possibility that this feature would be added as part of NuGet 3.3 and the contentFiles feature, but unfortunately, this feature is for Universal Windows projects, and not for Console Application, Windows Forms, or WPF projects.

However, NuGet does run a PowerShell script on install and another on uninstall, called install.psi and uninstall.ps1. It took some work, I even gave up once, but eventually I found the right library and the documentation for it to help me solve this.

Step 1 – Create a NuGet Packager Project in Visual Studio

  1. Open Visual Studio and go to File | New Project.
    Note: Steps 2 thru 7 installs the NuGet Packager project from online. If you have already done this, then you probably can create your project without these steps. 🙂
  2. At the bottom of the list on the right, click Online to expand it.
    Note: For some reason, Visual Studio hung for about ten to twenty seconds when I clicked this.
  3. In the search bar on the top right, enter NuGet.
  4. Select NuGet Packager.
  5. Give your project a Name.
    Note: Mine is named SimpleArgs.Sources.
  6. Give your solution a Name.
  7. Click Ok.
    See steps 2 – 7 in this image:
    NuGet Package Visual Studio Project Template
    When you click OK, the template will install. It will prompt you a few times but once installed, your project will be created.Note: From now on, you can find the NuGet Packager project in Installed | Templates | Visual C# | NuGet.

Step 2 – Fill out the Package.nuspec file metadata

The package.nusepc is an Xml file. It is created as follows:

&amp;lt;?xml version=&amp;quot;1.0&amp;quot;?&amp;gt;
&amp;lt;package &amp;gt;
    &amp;lt;description&amp;gt;A long description of the package. This shows up in the right pane of the Add Package Dialog as well as in the Package Manager Console when listing packages using the Get-Package command.&amp;lt;/description&amp;gt;
    &amp;lt;summary&amp;gt;A short description of the package. If specified, this shows up in the middle pane of the Add Package Dialog. If not specified, a truncated version of the description is used instead.&amp;lt;/summary&amp;gt;
    &amp;lt;copyright&amp;gt;Copyright  2016&amp;lt;/copyright&amp;gt;
        &amp;lt;group targetFramework=&amp;quot;net40&amp;quot;&amp;gt;
          &amp;lt;dependency id=&amp;quot;log4net&amp;quot; version=&amp;quot;1.2.10&amp;quot; /&amp;gt;
    &amp;lt;file src=&amp;quot;lib\&amp;quot; target=&amp;quot;lib&amp;quot; /&amp;gt;
    &amp;lt;file src=&amp;quot;tools\&amp;quot; target=&amp;quot;tools&amp;quot; /&amp;gt;
    &amp;lt;file src=&amp;quot;content\&amp;quot; target=&amp;quot;content&amp;quot; /&amp;gt;
Package.nuspec Changes

I can’t go over every possible nuspec setting. That is in the Nuspec Reference. However, I’ll give you the basics of what I changed.

  1. id – Set this to your package name. If you named your project correctly, this is already named correctly. I’ll leave the above unchanged.
  2. version – This is your version. If this is your first release, 1.0.0 is perfect. I am changing mine to 1.1.0 as my last version was 1.0.9.
  3. title – Often the same as the id, but not always. I’ll leave mine as is.
  4. authors – This is me. I want something other than the Visual Studio username. I changed this to Jared Barneck (Rhyous)
  5. owners – This is me or my business. I’ll change this to Rhyous Publishing LLC
  6. description – Long description. This is defined in the Xml. Change it to describe your NuGet package.
  7. releaseNotes – I just put a link to the release notes in my GitHub repo: https://github.com/rhyous/SimpleArgs/blob/master/ReleaseNotes.txt
  8. summary – Short description. This is also defined in the xml. This is usually shorter than the description.
  9. language – This is the 5 digit language IETF language tag. I left mine at en-US.
  10. projectUrl – I changed this to my GitHub location: https://github.com/rhyous/SimpleArgs
  11. iconUrl – I changed this to the icon file in my GitHub source. Unlike the release notes and the license file, I used the raw GitHub link for the image: https://raw.githubusercontent.com/rhyous/SimpleArgs/master/Docs/Images/SimpleArgs.Logo.png
  12. requireLicenseAcceptance – I left this as false. Only set this to true if your license requires an agreement.
  13. licenseUrl – I set this to the license file in my GitHub repository:
  14. copyright – I set this to Copyright Rhyous Publishing LLC
  15. dependencies – This project has no dependencies, so I deleted this entire section.
  16. references – I deleted this tag. Source NuGet packages probably won’t have any references.
  17. tags – Since my project is for command line arguments, I set my tags to: args, arguments
  18. files – This was preconfigured, however, I replaced the libs\ with src\ because I didn’t have any libs but I have source.

You can see my final nuspec file in the GitHub repo: SimpleArgs.Sources Package.nuspec

Step 3 – Add Shared Source Files

Default Items in Solution Explorer for a NuGet Packager ProjectIn Visual Studio, in Solution Explorer, you should see that there are already four folders provided for you. See the image to your right. ———–>

  • content – This is what is going to be copied to your project. Since we don’t want all our source copied, we aren’t going to put our source here.
    Note: I would delete this folder, but it turns out, I have one source file that isn’t shared. ArgsHandler.cs will be customized in each project, which makes sense because each project will have different args and handle args differently. ArgsHandler.cs will go here.
  • libs – I have no libs. I can delete this folder and the associated xml for it in the nuspec.
  • src – Stuff I put here isn’t copied to my projects. I am going to put all my shared source in this folder.
  • tools – this has the PowerShell scripts: init.ps1, install.ps1, and uninstall.ps1

Now that we understand our folder structure, let’s get to work.

  1. In Visual Studio’s Solution Explorer, create a folder called App_Packages under the src directory.
    Note: I was going to use App_Sources but NuGet recommends that we follow what other community members follow and others have already started putting source files under App_Packages, so I am following that community convention. Also, this is important for the PowerShell scripts, as this convention plays a part in them. If you don’t follow this convention, you will have to edit the and uninstall.psi PowerShell scripts, which I’ll be providing later.
  2. In Visual Studio’s Solution Explorer, create a Folder with the project name and version. In my case, the folder name is this: SimpleArgs.Sources.1.1.0.
    Note: Again, this was by community convention. Others were doing this. You don’t have to follow this exactly, again, If you don’t follow this convention, you will have to edit the install.ps1 and uninstall.psi PowerShell scripts, which I’ll be providing later.
  3. In Windows Explorer, not in Visual Studio, put your source under the project name and version directory.
    Note: In Visual Studio’s Solution Explorer, I only have these two directories: App_Packages/SimpleArgs.Sources.1.1.0.
    Note: In Windows Explorer, My directory structure ended up as follows:


    Note: There is a good reason that I don’t include these in the NuGet Packager Visual Studio project, which I will explain later.

Step 4 – Add Source Files

As mentioned earlier, the ArgsHandler.cs file isn’t shared. Each project does need its own copy of this file. So we need to add it so that it supports Source Code Transformations.

  1. In Visual Studio’s Solution Explorer, copy any source files into the Content directory. You may put them in sub directories if you wish. I created an Arguments folder.
  2. Add .pp to the end of any source files.
  3. Change the namespace to $rootnamespace$ in any source files. You may also add a sub namespace to the end of $rootnamespace$ as I did.
using SimpleArgs;
using System;
using System.Collections.Generic;

namespace $rootnamespace$.Arguments
    // Add this line of code to Main() in Program.cs
    //   ArgsManager.Instance.Start(new ArgsHandler(), args);

    /// &amp;lt;summary&amp;gt;
    /// A class that implements IArgumentsHandler where command line
    /// arguments are defined.
    /// &amp;lt;/summary&amp;gt;
    public sealed class ArgsHandler : ArgsHandlerBase
         // content snipped see full file here: https://github.com/rhyous/SimpleArgs/blob/master/NuGet/SimpleArgs.NuGet/content/Arguments/ArgsHandler.cs.pp

Step 5 – Add As Link in NuGet using PowerShell scripts

There are three PowerShell scripts.

  • init.ps1
  • install.ps1
  • uninstall.ps1

We are only going to modify install.ps1 and uninstall.ps1.

Note: The following are written to be very generic and have been tested in various Visual Studio projects, which means some common bugs are already fixed, such as not failing on creation of App_Packages just because it is already there.

  1. Update install.ps1.

    Note: For the latest versions of install1.ps1 and uninstall.ps1, go to the tools directory on my GitHub repo.

    # Runs every time a package is uninstalled
    param($installPath, $toolsPath, $package, $project)
    # $installPath is the path to the folder where the package is installed.
    # $toolsPath is the path to the tools directory in the folder where the package is installed.
    # $package is a reference to the package object.
    # $project is a reference to the project the package was installed to.
    # Variables
    $src = &amp;quot;src&amp;quot;
    $packageName = [System.IO.Path]::GetFileName($installPath)
    write-host &amp;quot;project: &amp;quot; $project.FullName
    write-host &amp;quot;installPath: &amp;quot; $installPath
    write-host &amp;quot;toolsPath: &amp;quot; $toolsPath
    write-host &amp;quot;package: &amp;quot; $package
    write-host &amp;quot;project: &amp;quot; $project
    $srcPath = [System.IO.Path]::Combine($installPath, $src)
    write-host &amp;quot;srcPath: &amp;quot; $srcPath
    $solutionDir = [System.IO.Path]::GetDirectoryName($dte.Solution.FullName)
    $projectDir = [System.IO.Path]::GetDirectoryName($project.FullName)
    write-host &amp;quot;solutionDir: &amp;quot; $solutionDir
    write-host &amp;quot;projectDir: &amp;quot; $projectDir
    $areSameDir = $solutionDir -eq $projectDir
    write-host &amp;quot;areSameDir: &amp;quot; $areSameDir
    function AddLinkedFiles($path, $addLocation, $canLink) 
        write-host &amp;quot;path: &amp;quot; $path
        write-host &amp;quot;addLocation: &amp;quot; $addLocation.FullName
        write-host &amp;quot;canLink: &amp;quot; $canLink
        foreach ($item in Get-ChildItem $path)
            write-host &amp;quot;item: &amp;quot; $item $item.FullName
            if (Test-Path $item.FullName -PathType Container) 
                if ( $canLink) {
                    $addFolder = $project.ProjectItems|Where-Object {$_.FullName -eq $item.FullName}
                    if (!$addFolder) {
                        $addFolder = $addLocation.ProjectItems.AddFolder($item)
                    write-host &amp;quot;addFolder: &amp;quot; $addFolder.FullName
                    AddLinkedFiles $item.FullName $addFolder $canLink
                } else
                    AddLinkedFiles $item.FullName $addLocation $canLink
                write-host &amp;quot;Adding &amp;quot; $item.FullName &amp;quot; to &amp;quot; $addLocation.FullName
    write-host &amp;quot;Calling AddLinkedFiles&amp;quot;
    AddLinkedFiles $srcPath $project (!$areSameDir)
  2. Update uninstall.ps1.
    # Runs every time a package is uninstalled
    param($installPath, $toolsPath, $package, $project)
    # $installPath is the path to the folder where the package is installed.
    # $toolsPath is the path to the tools directory in the folder where the package is installed.
    # $package is a reference to the package object.
    # $project is a reference to the project the package was installed to.
    # Variables
    $packages = &amp;quot;Packages&amp;quot;
    $app_packages = &amp;quot;App_Packages&amp;quot;
    $src = &amp;quot;src&amp;quot;
    $packageName = [System.IO.Path]::GetFileName($installPath)
    write-host &amp;quot;project: &amp;quot; $project.FullName
    write-host &amp;quot;installPath: &amp;quot; $installPath
    write-host &amp;quot;toolsPath: &amp;quot; $toolsPath
    write-host &amp;quot;package: &amp;quot; $package
    write-host &amp;quot;project: &amp;quot; $project
    $srcPath = [System.IO.Path]::Combine($installPath, $src)
    write-host &amp;quot;srcPath: &amp;quot; $srcPath
    $solutionDir = [System.IO.Path]::GetDirectoryName($dte.Solution.FullName)
    $projectDir = [System.IO.Path]::GetDirectoryName($project.FullName)
    write-host &amp;quot;solutionDir: &amp;quot; $solutionDir
    write-host &amp;quot;projectDir: &amp;quot; $projectDir
    $areSameDir = $solutionDir -eq $projectDir
    write-host &amp;quot;areSameDir: &amp;quot; $areSameDir
    if ($areSameDir) {
        $packagesItem = $project.ProjectItems|Where-Object {$_.Name -eq $packages}    
        write-host &amp;quot;packageFolder: &amp;quot; $packagesItem.Name
        $item = $packagesItem.ProjectItems|Where-Object {$_.Name -eq [System.IO.Path]::GetFileName($installPath)}
        write-host &amp;quot;item: &amp;quot; $item.Name
        if ($packagesItem.ProjectItems.Count -eq 0) {
    } else {
        $app_packagesItem = $project.ProjectItems|Where-Object {$_.Name -eq $app_packages}
        write-host &amp;quot;app_packagesItem: &amp;quot; $app_packagesItem.Name
        $app_packagesFolder = [System.IO.Path]::Combine($srcPath,$app_packages)
        foreach ($subDir in (Get-ChildItem $app_packagesFolder)) {
            $item = $app_packagesItem.ProjectItems|Where-Object {$_.Name -eq $subDir.Name}
            write-host &amp;quot;item: &amp;quot; $item.Name
            if ($item) {
        if ($app_packagesItem.ProjectItems.Count -eq 0 -and (Get-ChildItem ([System.IO.Path]::Combine($projectDir, $app_packages))).Count -eq 0) {

    Step 6 – Build the solution and NuGet package

    The NuGet Packager project template is pretty awesome. When you use it, it builds the NuGet package for you on build. Also, if you build in release mode, it will try to upload the NuGet package to the public NuGet Package Gallary.

    1. In Visual Studio, make sure the Solution Configuration is set to Debug.
    2. Choose to Build | Build Solution.
    3. In your project directory, you should have a NuGet package built. Mine is called SimpleArgs.Sources.1.1.1.nupkg.

    Stay Tuned

    Stay tuned for NuGet for Source Using Add As Link (Part 2 – Testing & Deploying)

    If you subscribe, you will never miss a post.

How to Add As Link in Visual Studio

There may be times when you need to share source between projects but you can’t reference a dll. This would happen if you are writing multiple single file executables and you wanted to share source between them. By definition, a single file executable doesn’t reference a dll or it would not be a single file.

You can still share source using Visual Studio’s Add As Link feature.

To use Add As Link in Visual Studio, follow these steps.

  1. Right-click on your project in Solution Explorer and choose Add | Existing Item.
    Visual Studio Add Existing Item
  2. Next navigate to your shared file and click to highlight the file.
  3. Next click the drop down arrow next to Add and choose Add As Link.
    Visual Studio Add As link
  4. Verify that the file was added as a link. You can tell because it has a different icon to distinguish it from other source files.Icon for Add As Link Source
  5. Verify that the Build Action is set to Compile. It should be as this is the default Build Action for a .cs file.
    Visual Studio Build Action Compile

You can now share source without using a dll.

Microsoft to Acquire Xamarin

XamarinMicrosoft is to acquire Xamarin. Read the article here. Xamarin is far and away the best tool for writing cross-platform mobile apps, but their business model greatly slowed the company’s customer acquisition.

A new mobile developer could easily install Eclipse for free and develop a mobile app without zero cost. The minimum Xamarin fee cost $25 a month but it did not work with Visual Studio. The minimum Xamarin version that worked with Visual Studio cost $1000 a month.

Better business models existed. I long recommended that Xamarin be completely free to for developers to download and use, but the compiled code should have been time-bombed for one day. Of course, with IL editors such time-bombing could be removed, but doing so would not be easy. This model would have allowed them to gather all the indie developers who had an idea and quickly get their application to work on iOS, Android, and Windows. Then at release time, charging a fee to publish the app would have been more palatable. In the long run it would have resulted in more customers and users. It would have skyrocketed the number of xamarin developers. I believe Xamarin would have ended up making far more money by charging less to way more users. But Xamarin disagreed.

Microsoft sees the need to make Xamarin the go to language from cross-platform apps. The flaky and hacked together html5 stack is the only other option for true cross-platform development. Microsoft and Visual Studio has a marge larger user base than Xamarin. If Microsoft’s intention to maintain Xamarin’s model, they would be making a huge mistake.

Microsoft should immediately add Xamarin to the Visual Studio Enterprise subscribers. Enterprise is the top-level and should get everything. There will be some loss of revenue as some Xamarin customers are also Enterprise subscribers, but that loss in negligible and would probably be made up by higher renewal rates and less downgrades. However, if Miocrosoft were to add all of Xamarin also to their Visual Studio Professional subscribers, Xamarin might lose a huge portion of revenue, as most Xamarin customers are also Visual Studio Subscribers. If they want to keep this revenue, then they could easily add a mobile subscription level for mobile only developers and then a professional plus mobile subscription level entices current professional developers to upgrade.

However, what if Microsoft doesn’t care about Xamarin’s revenue at all. What if what they care about is getting mobile developers to primarily use Visual Studio. What if they give Xamarin in its entirety away free in Community Edition so everyone at any Visual Studio level would have it. And what if they open source it?

How many more users would flock to Visual Studio Community Edition? This could be the catalyst to dethrone JavaScript. To bring thousands of users to the Microsoft development ecosystem that also includes Azure. What types of increases in their cloud users could this bring? Perhaps the Xamarin acquistion is not intended to continue to make its own revenue. Perhaps the acquisition is nothing more than a feature add to their existing technology stack.

Were I Microsoft’s CEO, Satya Nadella, I would go the Community Edition route. But I’m not him and I do not know what he is going to do. We are left to wait and see.