jcansdale / TestDriven.Net-Issues

Issue tracking for TestDriven.Net
https://github.com/jcansdale/TestDriven.Net-Issues/issues
24 stars 2 forks source link

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

Closed jcansdale closed 6 years ago

jcansdale commented 7 years ago

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

grokky1 commented 7 years ago

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 commented 7 years ago

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 commented 6 years ago

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: https://github.com/dotnet/sdk/issues/1405#issuecomment-336313363

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

jcansdale commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

@mikehadlow,

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

And after you add the CopyLocalLockFileAssemblies element: image

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 commented 6 years ago

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

mikehadlow commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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.