Allow .NET Standard ad-hoc methods to be executed using .NET Framework

[jcansdale]

See .NET platforms support table here:
https://docs.microsoft.com/en-us/dotnet/standard/library

[grokky1]

Is this included in the latest 4.1.3526 alpha? And, does that alpha work in VS2017? I can't seem to get it to work...

[jcansdale]

I'm afraid this isn't ready yet. Unfortunately there are issues with the various test runners (NUnit / xUnit) when executing in this mode. I had it working with "Ad hoc" tests, but it is a bit of a hack (but still useful).

I'll keep you posted.

(Oops, sorry I closed and reopened the issue! 😊)

[jcansdale]

This is getting closer to working for .NET Standard 2.0 projects:

The user would need to set the CopyLocalLockFileAssemblies property to true in the project:

  <PropertyGroup>
    <TargetFramework>netstandard2.0</TargetFramework>
    <CopyLocalLockFileAssemblies>true</CopyLocalLockFileAssemblies>
  </PropertyGroup>

There would potentially be problems with binding redirects, but it looks like this might be going away:
dotnet/sdk#1405 (comment)

There are issues, but I think being able to run ad-hoc tests in many .NET Standard 2.0 projects would be useful!

[jcansdale]

I've created a tracking issue for .NET Standard support that will be linked to when users attempt to use this functionality #117. Please comment if you have any questions or tips to share.

Here's a local build of a VSIX that includes this functionality: TestDriven.VSPackage.zip

[mikehadlow]

Hi Jamie, I installed the VSIX then created a new .NET Standard library project. Added the CopyLocalLockFileAssemblies element to the project file and created a simple class:

using System;

namespace TestDrivenTest
{
    public class Class1
    {
        public static void DoIt()
        {
            Console.WriteLine("Hello TestDriven.NET");
        }
    }
}

But attempting to run the DoIt method 'Ad Hoc' just causes, "Can't find assembly for project 'TestDrivenTest'." to be displayed in the output window.

[jcansdale]

@mikehadlow,

Thanks for trying it! This is what is supposed to happen the first time you attempt to run:

And after you add the CopyLocalLockFileAssemblies element:

As a sanity check, here is the solution I created:
TestDrivenTest.zip

Did you uninstall any previous version of TestDriven.Net you had installed. This shouldn't matter, but there might be a problem I hadn't anticipated. I'm guessing you created a .NET Standard 2.0 project?

[mikehadlow]

Your solution worked as expected on my machine. Here's my solution which looks the same
TestDrivenTest_MH.zip

[mikehadlow]

Upgraded VS to 15.7.3 now creating a new netstandard2.0 library project and running ad-hoc tests works as expected. Thanks @jcansdale, great work!

[jcansdale]

The TestDrivenTest.csproj in your ZIP appears to be identical. I did notice there was also a ClassLibrary1.csproj files that wasn't part of the solution. This appears to target .NET 4.6.1 and should also work.

I'm confused about what might have been different on your previous configuration. 😕 Were you targeting ClassLibrary1.csproj or TestDrivenTest.csproj?

[mikehadlow]

Sorry, that ClassLibrary1.csproj was just a quick check to make sure that the new install was still working for .NET 4.6.1. I was targeting TestDrivenTest.csproj. I couldn't see any difference between our two projects, but bizarrely when I created a new project after upgrading to VS 15.7.3 it worked fine? Obviously something to do with the way the project is created, but then there's no discernible difference in the files? Not that I could notice with a diff?

[jcansdale]

It's possible that it was the reloading of Visual Studio that resolved it. I've noticed project files can sometimes be funny like that after an update. Hopefully it will be more consistent in never versions of Visual Studio. 🤞

Thanks again for trying this. Please report back if you bump into any issues/snags. Although not perfect, I'm hoping this feature will be useful with many projects. I'm looking forward to using it myself.