New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SpecFlow doesn't work with .NET Core 3.1.200 SDK #1912
Comments
Having the same issue in Docker build. Was using |
The SDK version 3.1.102 seems to be gone... |
@trondgod They have it on their download page: https://dotnet.microsoft.com/download/dotnet-core/3.1 |
MSBuild 16.5 has a new assembly loading approach for tasks that may have side effects. (which has been an ask for years, but it behaves a bit differently when loading dependencies) |
@SabotageAndi I suspect @dasMulli has correctly identified the reason this is happening. But I'm not sure exactly what the problem is. Is there an easy way to get a small repro project so that I can debug the assembly loading behavior? |
@rainersigwald I am working on a repro right now. |
@rainersigwald I have it. You can find it here: https://github.com/SabotageAndi/GH1912 Simply build it with the included If building with .NET Core SDK 3.1.200 I get following output:
With .NET Core SDK 3.1.102 I get this output:
I hope this helps you. |
@SabotageAndi that is an amazing repro! Thank you! I reproduce the problem with it and will take a look. |
One quick note: with @SabotageAndi's repro, |
@rainersigwald any news on this issue? |
No news yet, sorry. Filed dotnet/msbuild#5202 to keep it top of mind for my team. |
Do you think we could do something on our side to get around the issue? More and more people are hitting this issue. |
Your repro case uses The docs for
That's exactly what's happening here: it's failing to resolve dependencies using the path of the loaded file. This worked before 3.1.200/MSBuild 16.5, because MSBuild installed an assembly load hook into the default ALC that would load dependencies from "any directory next to a loaded task assembly". If I use diff --git a/MSBuildTask/AssemblyLoadTask.cs b/MSBuildTask/AssemblyLoadTask.cs
index d0c5010..fa497ba 100644
--- a/MSBuildTask/AssemblyLoadTask.cs
+++ b/MSBuildTask/AssemblyLoadTask.cs
@@ -14,7 +14,7 @@ namespace MSBuildTask
public override bool Execute()
{
var path = Path.Combine(Environment.CurrentDirectory, "..", "Plugin", "bin", "debug", "netstandard2.0", "Plugin.dll");
- var assembly = Assembly.LoadFile(path);
+ var assembly = Assembly.LoadFrom(path);
var customAttributes = assembly.GetCustomAttributes();
var pluginAttribute = (PluginMarkerAttribute)customAttributes.SingleOrDefault(a => a is PluginMarkerAttribute); your repro case works fine. I think that's the right way to go. I first thought that you might be using |
Thanks for the input. I will try to use |
Hi @SabotageAndi , hope everything is fine on your side. |
@magicben I am still looking into it. No new news yet. |
Some status updates: The next step will be to change the Assembly loading code. |
We merged the last PR for this to fix. Build is now running to create new packages. |
@SabotageAndi Great! How long does a release stay in beta usually ? |
@CurlyFire Depends from version to version. This will be at least 3 weeks in beta. We have some additional changes planned in our next iteration (starts next Tuesday). |
We published a first 3.3-beta package to NuGet.org (https://www.nuget.org/packages/SpecFlow/3.3.15-beta) which a fix for this. Please try it out and give us feedback if it is now working for you. |
@SabotageAndi seems to be working for me. |
worked for me. I used 3.3.16-beta |
Works like a charm. |
3.3.16-beta works for me as well |
Confirmed 3.3.16-beta |
Thanks for the feedback. I am closing now this issue. |
* Add Elastisearch to team shared dictionary * initial commit * clean up implemntations and error reporting * always add frames * Initial stab at tests using prerelease package * Linux compilation fixes being bit by: SpecFlowOSS/SpecFlow#1912 * Introduce more unit tests around Elasticsearch integration * remove unused variable * Remove dependency on Elastic.Managed.Ephemeral Only used in example project, switched to one that talks to elastic/apm-integration-testing. * bump Elasticsearch.Net reference * Apply suggestions from code review Co-authored-by: Gergely Kalapos <gergo@kalapos.net> * Log DiagnosticEventKey on Trace * Try catch around calling OnNext() * update failing test, assertion could never be satisfied, Added assertions on reported exception Co-authored-by: Gergely Kalapos <gergo@kalapos.net>
Mutualization of Specflow reference. Using Specflow 3.3.22-beta (only for test project) to resolve the following issue SpecFlowOSS/SpecFlow#1912
Update DevOps Pipeline to workaround SpecFlowOSS/SpecFlow#1912
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
SpecFlow Version:
Used Test Runner
Version number:
Project Format of the SpecFlow project
packages.config
<PackageReference>
tags.feature.cs files are generated using
SpecFlow.Tools.MsBuild.Generation
NuGet packageSpecFlowSingleFileGenerator
custom toolVisual Studio Version
Enable SpecFlowSingleFileGenerator Custom Tool
option in Visual Studio extension settingsAre the latest Visual Studio updates installed?
<Major>.<Minor>.<Patch>
.NET Framework:
Test Execution Method:
dotnet test
Issue Description
When using the .NET Core 3.1.200 SDK, the MSBuild Generation fails with following error:
Steps to Reproduce
Workaround
Set Environment variable to get all MSBuild behaviour:
MSBUILDSINGLELOADCONTEXT=1
The text was updated successfully, but these errors were encountered: