Specflow: Could not copy file 'TechTalk.SpecFlow.NUnit.SpecFlowPlugin.dll' issue

[Radnen]

SpecFlow Version:

• [x] 3.0
• [ ] 2.4
• [ ] 2.3
• [ ] 2.2
• [ ] 2.1
• [ ] 2.0
• [ ] 1.9

Used Test Runner

• [ ] SpecFlow+Runner
• [ ] MSTest
• [x] NUnit
• [ ] Xunit

Version number:

Visual Studio Version

• [ ] VS 2019
• [x] VS 2017
• [ ] VS 2015

Are the latest Visual Studio updates installed?

• [ ] Yes
• [ ] No

.NET Framework:

• [ ] >= .NET 4.5
• [ ] before .NET 4.5
• [ ] .NET Core 2.0
• [ ] .NET Core 2.1
• [x] .NET Core 2.2
• [ ] .NET Core 3.0

Test Execution Method:

• [x] Visual Studio Test Explorer
• [ ] TFS/VSTS/Azure DevOps – Task – PLEASE SPECIFY THE NAME OF THE TASK
• [ ] Command line – PLEASE SPECIFY THE FULL COMMAND LINE

<SpecFlow> Section in app.config or content of specflow.json

Repro Project

Issue Description

You guys have the wrong path. During build I get this error:
Could not copy the file
"...nugetpackagesspecflow.nunit3.0.191libTechTalk.SpecFlow.NUnit.SpecFlowPlugin.dll"
because it was not found.

However, it does exist here:
"...nugetpackagesspecflow.nunit3.0.191libnetstandard2.0TechTalk.SpecFlow.NUnit.SpecFlowPlugin.dll"

I'm building as a .NET Standard 2.0 Class Library. It should know how to find this.

Steps to Reproduce

Start a .NET Standard 2.0 Class Library Project. Install v3.0.191 of SpecFlow via NuGet ("SpecFlow", "SpecFlow.NUnit", and "SpecFlow.Tools.MSBuild.Generator") and try building the project.

[SabotageAndi]

My first guess is, that these conditions don't work if you are in a .NET Standard classlib:

https://github.com/techtalk/SpecFlow/blob/master/Plugins/TechTalk.SpecFlow.NUnit.Generator.SpecFlowPlugin/build/SpecFlow.NUnit.targets#L10

[Radnen]

@SabotageAndi You are correct. I used a .NET Core Class Library and it worked for me. I'm not sure if SpecFlow is to be limited to .NET Core only, or if you guys will allow for .NET Standard too someday.

[Nagendracv]

The issue is that you are using a .net standard library in a .net core project. Isn't it? Use a .Net core library. Or Use a .Net Standard project.

[2mcdev]

The fix seems to actually be really simple. We had the same issues using specflow in a .net standard library (for the purpose of sharing steps via nuget).

When adding the line:

<_SpecFlow_xUnitRuntimePlugin Condition=" '$(TargetFrameworkIdentifier)' == '.NETStandard' ">netstandard2.0</_SpecFlow_xUnitRuntimePlugin>

to:

/Plugins/TechTalk.SpecFlow.xUnit.Generator.SpecFlowPlugin/build/SpecFlow.xUnit.targets

our build seems to work fine with .net standard.

Would it be possible to add this?

Edit: We fixed it for now in our own .net standard project by adding the following to our .net standard project file:

<PropertyGroup> <!-- See: https://github.com/techtalk/SpecFlow/issues/1516#issuecomment-488244190 --> <_SpecFlow_xUnitRuntimePlugin>netstandard2.0</_SpecFlow_xUnitRuntimePlugin> </PropertyGroup>

[JamJar00]

I've faced the same issue with MsTest. The above step of adding
```


<_SpecFlow_MsTestRuntimePlugin>netstandard2.0
````
worked for me to fix this. I'm surprised more people aren't faced with this issue considering anyone targing .NET Standard should be hitting this right?

[SabotageAndi]

@JamJar00 & @2mcdev Why are your Testprojects a .NET Standard one?

Don't make test projects a .NET Standard project.

netstandard is an API, not a platform. Due to the way builds and dependency resolution work today, xUnit.net test projects must target a platform (desktop CLR, .NET Core, etc.) and run with a platform-specific runner application.

From: https://xunit.net/docs/why-no-netstandard

[2mcdev]

We do use platform targeted projects for tests but we have defined often used generic steps in a .net standard nuget package which is then used in both core and full framework targeted projects.

This scenario requires the workaround I described, and I think this shouldn't be necessary. Is there a complication with the proposed change?

[SabotageAndi]

Shared steps in a .NET Standard project is no problem. But don't put feature- Files into it and add the SpecFlow.Tools.MSBuild.Generation nuget to this.
You only need the SpecFlow package in a shared step project.

[JamJar00]

Huh. Never ever occured to me that .NET Standard can't be used for tests! Cheers!

[zelmo]

Apart from @2mcdev's scenario, I've also seen this error when developing a SpecFlow plugin. It's a class library, so it targets .NETStandard (as directed by SpecFlow's plugin development documentation). The project references SpecFlow.MsTest because it needs to register MsTestRuntimeProvider as an IUnitTestRuntimeProvider.

Adding the PropertyGroup entry in my own project did not resolve the problem for me, so I've hacked the SpecFlow.MsTest.targets file, like @2mcdev mentioned earlier. I would vote for adding the .NETStandard target for all unit test providers.