Specflow: Type or namespace [TestNamespace]_XunitAssemblyFixture could not be found

[xavalon263]

SpecFlow Version:

• [X] 3.1
• [ ] 3.0
• [ ] 2.4
• [ ] 2.3
• [ ] 2.2
• [ ] 2.1
• [ ] 2.0
• [ ] 1.9

Used Test Runner

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

Version number:

Project Format of the SpecFlow project

• [ ] Classic project format using packages.config
• [ ] Classic project format using <PackageReference> tags
• [X] Sdk-style project format

.feature.cs files are generated using

• [X] SpecFlow.Tools.MsBuild.Generation NuGet package
• [ ] SpecFlowSingleFileGenerator custom tool

Visual Studio Version

• [X] VS 2019
• [ ] VS 2017
• [ ] VS 2015

Enable SpecFlowSingleFileGenerator Custom Tool option in Visual Studio extension settings

• [ ] Enabled
• [X] Disabled

Are the latest Visual Studio updates installed?

• [X] Yes
• [ ] No, I use Visual Studio version <Major>.<Minor>.<Patch>

.NET Framework:

• [X] >= .NET 4.5
• [ ] before .NET 4.5
• [ ] .NET Core 2.0
• [ ] .NET Core 2.1
• [ ] .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

Issue Description

When the feature.cs file is generated the constructor gets an argument with a generated type [TestNamespace]_XUnitAssemblyFixture which cannot be found and lead to a compile error.
public MyFeature(MyFeature.FixtureData fixtureData, Test_XUnitAssemblyFixture assemblyFixture, Xunit.Abstractions.ITestOutputHelper testOutputHelper)

[SabotageAndi]

Which exact version of SpecFlow are you using?
How is the name of your test project?

[SabotageAndi]

And what is the root namespace of this project?

[xavalon263]

I use Specflow version 3.1.67.
The name of the test project is: companyname.platform.win32.test.
The root namespace is Compayname.Platform.Test.
The generated type for assemblyFixture is CompanyName_Platform_Test_XUnitAssemblyFixture, which cannot be found.

[Leanwit]

I have the same issue.
I've used the same combination but using VS 16.3.7

The name of the test project is: Mooc
The assembly name is: MoocTest.apps
The root namespace is: MoocTest.apps
The generated type for assemblyFixture is MoocTest_apps_XUnitAssemblyFixture which cannot be found.

[faso]

Same issue here, same parameters as the OP, except we're on .NET Core 3.1

[jjdd12]

Same Issue, with similar naming

[timmkrause]

Updating to

<PackageReference Include="SpecFlow.Tools.MsBuild.Generation" Version="3.1.76" />
<PackageReference Include="SpecFlow.xUnit" Version="3.1.76" />

did not solve it either.

Downgraded both to 3.0.225 to fix it.

[timmkrause]

Interesting is also that the "Output" window says

37>Build succeeded.
37>    0 Warning(s)
37>    0 Error(s)
37>
37>Time Elapsed 00:00:25.44
========== Rebuild All: 41 succeeded, 0 failed, 0 skipped ==========

(regardless of the version, same for 3.1.67) and if you filter for "Build Only" in the "Error List" window, it says 0 errors. So it might really be related to IntelliSense in some way...?!

[mootalk]

We have the same issue, the tests do run successfully however.

On .net core 3.1
SpecFlow packages are on 3.1.78
IDE is JetBrains rider 2019.3

[jjdd12]

We have the same issue, the tests do run successfully however.

On .net core 3.1
SpecFlow packages are on 3.1.78
IDE is JetBrains rider 2019.3

I am able to confirm that the test do run successfully, and that this is an IntelliSense only issue for me.

[SabotageAndi]

Ah, now I know what is happening here.

You all have probably R# installed. When you opened the feature.cs file it analyzes it and because it doesn't find the file in the obj folder with the type, you get this error.

[Leanwit]

I didn't install R# on my computer. Never.
It very strange because in my case it happens after update the project from Netcore 2.2 to Netcore 3.1

Hopefully, in my case tests now do run successfully too.

[xavalon263]

I don't have R# installed.
In my case it happens after updating the specflow nuget package from 3.0.225 to 3.1.67.

[timmkrause]

Also no R# here. Or to be more precise: It is suspended.

[epresi]

Hey guys,

I had a discussion with @SabotageAndi.
The generated assemblyFixture file (e.g.: [TestNamespace]_XunitAssemblyFixture) can be found in the obj folder (obj\Debug\targetframework\xUnit.AssemblyHooks.cs).
We realized that this is IntelliSense related "issue" (IntelliSense of VisualStudio itself, not R#).
As you all noticed, the build was successful, but the error was still there. This is because the generated code behind file (*.feature.cs) is opened in your editor. If you close them, and build again, the error will disappear.
We would like to know, if there is a reason to have the generated code behind file opened?
Maybe there is a use-case which we are not aware of.

BTW there is an ongoing PR which will move the generated files to the obj folder, so this problem will disappear when it'll be merged.

[SabotageAndi]

@timmkrause @xavalon263 @Leanwit @jjdd12 @faso
Any feedback to @epresi comment?
If not, we will close this issue on friday.

[mootalk]

The solution does build, but I still get the errors in Rider. I can work with it for now. But it is not sustainable. It's harder to see the actual errors and warnings. How soon do you think the PR will complete?

[SabotageAndi]

@mootalk So you get this errors in Rider without even opening the *.feature.cs files?

[mootalk]

Yes, it does compile however and the tests succeed. But if I look at the list of errors and warnings in the solution they do show up

[xavalon263]

Same here with rider

[caetanopaulo]

Same here.

IDE: Rider 201903
Specflow: 3.1.74
.net core: 3.1

[stroboscopicus]

Same here with VS 16.4.4
The error can be reproduced with this example (SpecFlow 3.1.62): https://github.com/SpecFlowOSS/SpecFlow-Examples/tree/master/SpecFlow.json/BowlingKata-SpecFlowJson-xUnit
Downgrading to 3.0.225 solves the problem.

[SabotageAndi]

@epresi had a look at this and we discussed the options.
You get this error displayed in the error list when you open the feature.cs or you have solution wide analyze in Rider/R# enabled.
The reason is that VisualStudio/R#/Rider ignores for this error message the files that are in the obj folder.
It's only a phantom error as at build, the files from the obj folder are included.

We think when we merge PR #1691, which moves all of the feature.cs files in the obj folder, this "phantom" errors should be gone.

It can take some time to get #1691 into master. There are still some merging conflict and problems with the PR.

[stroboscopicus]

solved by disabling full solution analysis https://docs.microsoft.com/en-us/visualstudio/code-quality/how-to-enable-and-disable-full-solution-analysis-for-managed-code?view=vs-2019

[timmkrause]

Using

<TargetFramework>netcoreapp3.1</TargetFramework>
<PackageReference Include="SpecFlow.Tools.MsBuild.Generation" Version="3.1.82" />
<PackageReference Include="SpecFlow.xUnit" Version="3.1.82" />

and VS 2019 16.4.4 without R#.

Cleaned everything (bin/obj), opened the solution (opened files restore disabled, so no file opened on startup) and after a few seconds the errors bubble up. So it is also related to full solution analysis.

But to be honest, disabling full solution analysis is just a temporary workaround for me.
I hope the upcoming PR fixes it, is there an ETA already?

Still stuck on 3.0.225. Additionally this blocks our .NET Core 3.1 migration because of System.AggregateExceptions when running tests with the combination of .NET Core 3.1 and SpecFlow 3.0.225 package versions. So these need to be aligned correctly.

[mootalk]

What is the status on this?
It seems to be taking quite long and I'm wondering if it is a better idea to generate the XunitAssemblyFixture into the project itself?
That gives a bit of ease on resolving #1691

[gutierlf]

Just adding my voice to let you know that I'm experiencing this issue too. I see that you're working on it, and I just wanted to let you know there are others with the same issue. I would prefer not to turn off full solution analysis. Good luck with the fix 👍

[Devvox93]

Hi, I'm commenting here for 2 reasons:

1. The cause described by @epresi was indeed my case and the quoted solution below fixed it for me. (I had the feature.cs file open because it wasn't generated correctly and was inspecting the Properties.)

As you all noticed, the build was successful, but the error was still there. This is because the generated code behind file (*.feature.cs) is opened in your editor. If you close them, and build again, the error will disappear.

1. The PR #1691 mentioned above has been closed by the author, since the destination branch has been updated a lot since the PR create date. It has been "replaced" with #1983

[vadim-96]

The problem is still actual :(

[mootalk]

A workaround for Rider is to exclude *.feature.cs files from analysis. How to do this can be found here: https://www.jetbrains.com/help/rider/Code_Analysis__Configuring_Warnings.html

This is workable for us since these files are autogenerated anyway. Hope this helps other people

[EnocAnanda]

A workaround for Rider is to exclude *.feature.cs files from analysis. How to do this can be found here: https://www.jetbrains.com/help/rider/Code_Analysis__Configuring_Warnings.html

This is workable for us since these files are autogenerated anyway. Hope this helps other people

This was very helpful. This is the best workaround. I used the same file exclusion pattern within the ReSharper (R#) extension in Visual Studio 2019 (v16.7.x). Go to Extensions -> ReSharper -> Options -> (popup dialog window) -> Code Inspection -> Ignored Code -> Elements to skip. Click "Add", type in "*.feature.cs" -> click OK -> click Save.

[arkiaconsulting]

I got rid of the errors by adding the following to the specflow test csproj:

<ItemGroup>
    <Compile Remove="*.feature.cs" />
  </ItemGroup>

<ItemGroup>
    <None Include="*.feature.cs" />
</ItemGroup>

[SabotageAndi]

@arkiaconsulting with that you remove the code-behind files from your assembly and so you have no scenarios anymore to execute.

[arkiaconsulting]

@SabotageAndi after having cleaned, deleted *.feature.cs files, unloaded then reloaded the project, rebuilt, I still have all my scenarii and all my tests pass...

[czarls]

Hi guys, it's been a while since this bug was raised and there is still no any fox for this, is there?

[SabotageAndi]

@czarls SpecFlow is an Open Source Project that depends on the contributions of its community. We are only a small team and can't do everything.

I am happy to help to get people started working on SpecFlow anytime and review pull requests.
And starting tomorrow, the whole team is available for two weeks to get people started contributing to SpecFlow. Read more about our first OSS Iteration at https://specflow.org/blog/lets-start-the-new-year-working-together-on-specflow/

[godrose]

@SabotageAndi
I provide here a workaround that I use to overcome this for Resharper part:
You should add *.feature.cs to the list of excluded files: Visual Studio->Extensions->Resharper->Options->Code Inspection->Generated Code->Elements To Skip->File Masks.
Then save it using team-shared settings to make sure problem is solved across the whole team
The resulting line inside the .dotsettings file should look similar to:

<s:Boolean x:Key="/Default/CodeInspection/ExcludedFiles/FileMasksToSkip/=_002A_002Efeature_002Ecs/@EntryIndexedValue">True</s:Boolean>

[godrose]

@SabotageAndi This solves the problem for Resharper but the Visual Studio still highlights this as an error...
Moreover I tried to use .editorconfig approach and this doesn't help either

[SabotageAndi]

@godrose Does it only display it as error, or are you getting a real compile time error? Is it listed in the output window? What happens if you build on command line?

[godrose]

@SabotageAndi output window only. The build is fine.
I'm ok with the message but the rest of team is not 🙃

[SabotageAndi]

Are they opening the feature.cs files? I never saw this, when I didn't opened them.

[MatthewLymer]

I have this exact same problem, the project compiles fine, but the IDE is complaining that myapp_XUnitAssemblyFixture doesn't exist.

A workaround may be to have SpecFlow generate that class as a partial, then we can have a declaration in our solution to satisfy the IDE checks.

[godrose]

Are they opening the feature.cs files? I never saw this, when I didn't opened them.

Yes they do ))

[godrose]

@MatthewLymer What do you mean exactly?

[SabotageAndi]

Are they opening the feature.cs files? I never saw this, when I didn't opened them.

Yes they do ))

Why? There is no need for that. All changes will be overwritten with the next build.

[godrose]

Of course they don’t need to.
I’ll tell you what happens and why this is confusing.
Let’s say a developer builds the solution and something fails.
They immediately look at the output window and see there compilation errors
and the aforementioned error.
So when they will have fixed the real compilation errors there will still
be this false error. And this is confusing them.

On Wed, 17 Feb 2021 at 15:56 Andreas Willich [e-mail]
wrote:

Are they opening the feature.cs files? I never saw this, when I didn't
opened them.

Yes they do ))

Why? There is no need for that. All changes will be overwritten with the
next build.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/SpecFlowOSS/SpecFlow/issues/1825#issuecomment-780572746,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AB3OII6QWXAWINMJ3X4HSMLS7PDJPANCNFSM4J4HVH7Q
.

>

Best Regards,
Gennady Verdel

[SabotageAndi]

Understood, and then they are in a loop.
I think the only thing to fix this is to get https://github.com/SpecFlowOSS/SpecFlow/pull/1983 finally to work

[MatthewLymer]

@MatthewLymer What do you mean exactly?

If I have the following code in my integration test assembly:

public partial class MyApp_XUnitAssemblyFixture
{     
}

Then this satisfies the design-time errors, however, when I finally build the solution I get:

xUnit.AssemblyHooks.cs(8, 14): [CS0260] Missing partial modifier on declaration of type 'MyApp_XUnitAssemblyFixture'; another partial declaration of this type exists

Which if the generated class had partial on it, I would get no design-time errors OR any compile time errors, thus working around the problem.

@SabotageAndi
For a lot of IDEs like JetBrains Rider or Visual Studio when using Resharper, you don't even need to open the file before you'll be notified errors in the solution

[godrose]

@SabotageAndi
Right. I already remove the generated code out of the source control. It’s
never committed and no conflict is introduced there.

On Wed, 17 Feb 2021 at 16:22 Matthew Lymer [e-mail] wrote:

@MatthewLymer https://github.com/MatthewLymer What do you mean exactly?

If I have the following code in my integration test assembly:

public partial class MyApp_XUnitAssemblyFixture
{
}

Then this satisfies the design-time errors, however, when I finally build
the solution I get:

xUnit.AssemblyHooks.cs(8, 14): [CS0260] Missing partial modifier on declaration of type 'MyApp_XUnitAssemblyFixture'; another partial declaration of this type exists

Which if the generated class had partial on it, I would get no
design-time errors OR any compile time errors, thus working around the
problem.

@SabotageAndi https://github.com/SabotageAndi
For a lot of IDEs like JetBrains Rider or Visual Studio when using
Resharper, you don't even need to open the file before you'll be notified
errors in the solution

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/SpecFlowOSS/SpecFlow/issues/1825#issuecomment-780589105,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AB3OII47QKXHF3H3QG646SDS7PGKHANCNFSM4J4HVH7Q
.

>

Best Regards,
Gennady Verdel

[MatthewLymer]

If anyone's looking for a good workaround, I think I have one. It works on my company's project that leverages netcoreapp3.1, and I suspect it will work for others too.

there's 2 parts, the first part is to create a partial class for the class that the IDE is saying is not found:

// ENSURE THIS IS NOT IN A NAMESPACE!!!
// ReSharper disable All
public partial class MyCompany_XUnitAssemblyFixture
{
}

It's important that it is __NOT__ in a namespace. Also, obviously update the class name to match your project name's hierarchy, so for my company it ended up being AcmeToonsCorp_IntegrationTests_XUnitAssemblyFixture.

The second part is to update your csproj to include a target that will add the partial keyword to the generated file:

```

InputFilename="$(IntermediateOutputPath)xUnit.AssemblyHooks.cs"
OutputFilename="$(IntermediateOutputPath)xUnit.AssemblyHooks.cs"
MatchExpression="public\sclass"
ReplacementText="public partial class" />


File.WriteAllText(
OutputFilename,
Regex.Replace(File.ReadAllText(InputFilename), MatchExpression, ReplacementText));
]]>



```

I put this immediately after the <PropertyGroup>...</PropertyGroup> node, but the order doesn't seem to be important.

Voila, no IDE errors, and no compile errors, SpecFlow bliss.

Credits for https://stackoverflow.com/a/22571621/507793 for the code snippet to update a text file during msbuild, the snippet I provided has been altered to work with netcore3.1.

FYI I'm running this on Windows 10 with .NET Core SDK 3.1.404

[SabotageAndi]

@MatthewLymer we could make the class partial by default. So if somebody is submitting a PR for it, you would not need the whole second step.

[timmkrause]

Changing the main code base to allow a workaround. Doesn‘t feel right to me. How about fixing the root cause and eliminating a workaround to get the out of the box experience right for new users?

[SabotageAndi]

@timmkrause The problem is, that it is a lot of work to get the out-of-the-box experience right. If it would be, I would have already fixed it.
The workaround is a quick fix to remove the phantom error message at least for some of you.

The problem here is, that Visual Studio and Resharper aren't looking at all files they should. The compiler is doing it. So we need to work around a wrong behavior of IDEs. And the only workaround we know is a lot of work where we need to be sure that a lot of other stuff (e.g. navigation) is still working.
All this is not really fun to do.

And please don't forget. SpecFlow is an open-source project. It depends on the contributions of its users. We are only a small team with limited time.

So if you want to see this bug go away, jump at https://github.com/SpecFlowOSS/SpecFlow/pull/1983 and finish it. And don't wait for Tragedian to do the work for you.
I am happy to jump in a call with someone to explain in detail what is the problem, what needs to be done and what still has to work.

[MatthewLymer]

I started making an MR to add the partial and the forward declaration for the MyCompany_XUnitAssemblyFixture class. It's a little more complicated than I was expecting w/ the code generation supporting both C# and VB.net.

My current thinking is 2 parts:

1. Update the xUnit.AssemblyHooks.template.vb and xUnit.AssemblyHooks.template.cs files to make the class partial.
2. Update the XUnit2 feature code generation to emit a forward declaration for the MyCompany_XUnitAssemblyFixture class.

[github-actions[bot]]

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.