/home/vsts/.nuget/packages/specflow.tools.msbuild.generation/3.1.21-beta/build/SpecFlow.Tools.MsBuild.Generation.targets(78,5): error MSB4062: The "SpecFlow.Tools.MsBuild.Generation.GenerateFeatureFileCodeBehindTask" task could not be loaded from the assembly /home/vsts/.nuget/packages/specflow.tools.msbuild.generation/3.1.21-beta/build/../tasks/netcoreapp2.0/SpecFlow.Tools.MsBuild.Generation.dll. Assembly with same name is already loaded Confirm that the
Version number:
==============================================================================
Task : .NET Core
Description : Build, test, package, or publish a dotnet application, or run a custom dotnet command
Version : 2.156.1
Author : Microsoft Corporation
Help : https://docs.microsoft.com/azure/devops/pipelines/tasks/build/dotnet-core-cli
==============================================================================
packages.config<PackageReference> tagsSpecFlow.Tools.MsBuild.Generation NuGet packageSpecFlowSingleFileGenerator custom toolEnable SpecFlowSingleFileGenerator Custom Tool option in Visual Studio extension settings<Major>.<Minor>.<Patch> /opt/hostedtoolcache/dncs/2.2.103/x64/dotnet test /home/vsts/work/1/s/Landorphan.Ioc.ServiceLocation.XPlat.sln --logger trx --results-directory /home/vsts/work/_tempN/A
Source: https://github.com/landorphan/service-location/tree/tistocks-Instrumentation-NextSteps
Build Pipeline Result: https://dev.azure.com/landorphan/Service-Location/_build/results?buildId=759
run dotnet test with project specified off of the prescribed branch on Azure DevOps hosted Ubuntu 16.04 build agent.
Windows and OSX builds work fine.
Is anyone looking into this? It's been sitting dormant for almost a month.
We worked on building SpecFlow itself on Linux and MacOS.
Work is not yet complete, but the Linux build is working.
PR is here: https://github.com/techtalk/SpecFlow/pull/1709
We are using the MSBuild task itself in our build of SpecFlow.
We see this error a lot lately on our Windows build machines.
I think it got worse when we switched Test Targetframework from FullFramework to dotnet Core.
Is the root cause known or is there a workaround?
@zplan We never saw this error on Windows yet. This was only happening on Linux.
@SabotageAndi: We have this on our TFS2017 build agents and I think I saw it on the "Azure Pipelines" for Specflow when I did my last PR, there also the Windows build was failing because of this issue.
@zplan there are some builds failing at the moment for us, but this is because of build order problem. There a file is missing. This error about that an assembly is loaded twice.
Ok.
But here are two examples from us from two different builds, running on Windows build agents:
2020-02-05T01:50:45.3661496Z C:\Users\abc\.nuget\packages\specflow.mstest\3.1.67\build\SpecFlow.MsTest.targets(34,5): error MSB4062: The "SpecFlow.Tools.MsBuild.Generation.ReplaceTokenInFileTask" task could not be loaded from the assembly C:\Users\abc\.nuget\packages\specflow.tools.msbuild.generation\3.1.67\build\..\tasks\netcoreapp2.0\SpecFlow.Tools.MsBuild.Generation.dll. Assembly with same name is already loaded Confirm that the <UsingTask> declaration is correct, that the assembly and all its dependencies are available, and that the task contains a public class that implements Microsoft.Build.Framework.ITask. [Z:\w\184\s\Tests\IntegrationTests.csproj]
2020-02-05T02:21:07.9412350Z C:\Users\abc\.nuget\packages\specflow.mstest\3.1.82\build\SpecFlow.MsTest.targets(36,5): error MSB4062: The "SpecFlow.Tools.MsBuild.Generation.ReplaceTokenInFileTask" task could not be loaded from the assembly C:\Users\abc\.nuget\packages\specflow.tools.msbuild.generation\3.1.82\build\..\tasks\netcoreapp2.0\SpecFlow.Tools.MsBuild.Generation.dll. Assembly with same name is already loaded Confirm that the <UsingTask> declaration is correct, that the assembly and all its dependencies are available, and that the task contains a public class that implements Microsoft.Build.Framework.ITask. [Z:\w\98\s\Tests\AcceptanceTests.csproj]
@zplan do you have 2 projects in that solution that have the SpecFlow.Tools.MsBuild.Generation NuGet package added?
@SabotageAndi : Yes, that is the case, I have multiple test projects in one solution. each of them contains:
<PackageReference Include="SpecFlow" Version="3.1.82" />
<PackageReference Include="SpecFlow.MsTest" Version="3.1.82" />
<PackageReference Include="SpecFlow.Tools.MsBuild.Generation" Version="3.1.82" />
Ok, I think I found the issue.
We are importing the MSBuild tasks in your case multiple times: https://github.com/SpecFlowOSS/SpecFlow/blob/master/SpecFlow.Tools.MsBuild.Generation/build/SpecFlow.Tools.MsBuild.Generation.props#L75
Can this be fixed on SpecFlow side or is there a possible workaround?
I think setting a PropertyGroup in the tasks file and checking this on the import with a condition is all that is needed.
Happy to review PRs to fix this. It's probably faster.
We (SpecFlow Team) can take a look at it earliest in 2-3 weeks and put it in the next sprint.
We (SpecFlow Team) can take a look at it earliest in 2-3 weeks and put it in the next sprint.
Timeline is fine for me
We (SpecFlow Team) can take a look at it earliest in 2-3 weeks and put it in the next sprint.
Is this issue still on the roadmap/backlog?
I face this issue a lot on the build agents.
@zplan I couldn't reproduce the issue, but I now made the changes that would fix it. If the release pipeline runs through smoothly, I will release this change to nuget.org and you can try it yourself.
@zplan Version with the changes are now on nuget.org. Please try them and report them.
@SabotageAndi : Thanks for the info.
Unfortunately the problem is not solved. I got this issue from our TFS build server after the update:
2020-03-18T01:31:12.8063871Z C:\Users\xyz\.nuget\packages\specflow.mstest\3.1.89\build\SpecFlow.MsTest.targets(36,5): error MSB4062: The "SpecFlow.Tools.MsBuild.Generation.ReplaceTokenInFileTask" task could not be loaded from the assembly C:\Users\xyz\.nuget\packages\specflow.tools.msbuild.generation\3.1.89\build\..\tasks\netcoreapp2.0\SpecFlow.Tools.MsBuild.Generation.dll. Assembly with same name is already loaded Confirm that the <UsingTask> declaration is correct, that the assembly and all its dependencies are available, and that the task contains a public class that implements Microsoft.Build.Framework.ITask. [Z:\w\35\s\Tests\MyTests.csproj]
WTH????!?!?
Which .NET Core SDK version are you using? I am asking because of #1912.
WTH????!?!?
Which .NET Core SDK version are you using? I am asking because of #1912.
3.0.100
1912.
Figured that also out yesterday :)
The same error is occurring on Windows when using the 3.1.203 SDK version. The error doesn't occur in 3.1.100.
Looks like the 3.1.200+ versions changed the behavior or MSBuild:
MSBuild now loads tasks with AssemblyLoadContext isolation, allowing tasks that have conflicting dependencies to be loaded in the same process microsoft/msbuild#4916.
.NET Core SDK 3.1.200 can build C++ Common Language Infrastructure (CLI) libraries.
https://github.com/dotnet/core/blob/master/release-notes/3.1/3.1.2/3.1.200-sdk.md#notable-changes-in-31200-sdk
@andrebires yes, the MSBuild behavior changed. That's what is written in https://github.com/SpecFlowOSS/SpecFlow/issues/1912
Ops, I'm sorry, I didn't saw the related issue.
Today started to get same error on 2.1.403 NetCore. On TeamCity CI server. Last SpecFlow version. Build happens on Windows machine.
P.S. Fixed by updating SpecFlow and related packages to last beta version. Thanks.
After the update to version 3.3.30 I see the following error randomly which seems related to this issue:
.nuget\packages\specflow.mstest\3.3.30\build\SpecFlow.MsTest.targets(36,5):
error MSB4062: The "SpecFlow.Tools.MsBuild.Generation.ReplaceTokenInFileTask" task could not be loaded from the assembly .nuget\packages\specflow.tools.msbuild.generation\3.3.30\build..tasks\netcoreapp2.1SpecFlow.Tools.MsBuild.Generation.dll
Assembly with same name is already loaded Confirm that the
Seeing this issue also on VS 2019 for an C# NUnit SpecFlow + Runner project. I made the mistake of forgetting to install the SpecFlow.Tools.MsBuild.Generation until my first compile. After installing it I consistently get the below error. Any work around to fix this? I might try to uninstall all NuGet packages and then add back
Severity Code Description Project File Line Suppression State
Error MSB4018 The "GenerateFeatureFileCodeBehindTask" task failed unexpectedly.
System.Exception: Unit test Provider already set.
at TechTalk.SpecFlow.UnitTestProvider.UnitTestProviderConfiguration.UseUnitTestProvider(String unitTestProviderName)
at TechTalk.SpecFlow.NUnit.Generator.SpecFlowPlugin.GeneratorPlugin.Initialize(GeneratorPluginEvents generatorPluginEvents, GeneratorPluginParameters generatorPluginParameters, UnitTestProviderConfiguration unitTestProviderConfiguration) in D:\a\1\s\Plugins\TechTalk.SpecFlow.NUnit.Generator.SpecFlowPlugin\GeneratorPlugin.cs:line 14
at TechTalk.SpecFlow.Generator.GeneratorContainerBuilder.LoadPlugins(ObjectContainer container, GeneratorPluginEvents generatorPluginEvents, UnitTestProviderConfiguration unitTestProviderConfiguration, IEnumerable1 generatorPlugins)
at TechTalk.SpecFlow.Generator.GeneratorContainerBuilder.CreateContainer(SpecFlowConfigurationHolder configurationHolder, ProjectSettings projectSettings, IEnumerable1 generatorPluginInfos, IObjectContainer parentObjectContainer)
at SpecFlow.Tools.MsBuild.Generation.WrappedGeneratorContainerBuilder.BuildGeneratorContainer(SpecFlowConfigurationHolder specFlowConfigurationHolder, ProjectSettings projectSettings, IReadOnlyCollection`1 generatorPluginInfos, IObjectContainer rootObjectContainer)
at SpecFlow.Tools.MsBuild.Generation.GenerateFeatureFileCodeBehindTaskExecutor.Execute()
at SpecFlow.Tools.MsBuild.Generation.GenerateFeatureFileCodeBehindTask.Execute()
at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()
at Microsoft.Build.BackEnd.TaskBuilder.
I also see @zplan's error, when I upgrade SpecFlow packages past 3.1.52-beta.
I see it when I build with dotnet build, but not when I build inside VS 2019.
The relevant packages are: SpecFlow, SpecFlow.NUnit, SpecFlow.Tools.MsBuild.Generation
So that seems to imply that this bug was introduced between 3.1.52 and 3.1.62.