I am unable to run my Specflow tests, in Visual Studio 2022.
I have all steps defined and bound and yet it still says "No Matching Step Definition Found". Yet when I right click on the line and try to "Define Steps", it says "All Steps have been defined already" ?!! So no purple lines etc.
I am using
VS 2022
Specflow 3.9.74
Specflow.MSTest 3.9.74
Specflow.Tools.MsBuild.Generation 3.9.74
I can't understand why??
Any help gratefully received and appreciated. I've been trying to figure this out for over a day now as it affects the other tests.
Added screenshot here
Sometimes Visual Studio and SpecFlow just act weird. If a clean and rebuild doesn't fix the issue, close all Visual Studio windows, then delete the .vs folder that resides at the root of your solution.
I've noticed similar problems to this for years, and it usually indicates some mismatch between the C# step definitions, feature files, and the cached mapping between the two in Visual Studio.
Failing that, if using Git, try a "super clean" of your working tree after committing all pending changes:
git clean -fdx
And of course if that doesn't work, uninstalling and reinstalling the SpecFlow plugin might help too.
Related
Since Visual Studio 2017 version 15.8 we have on some computers in my team the following really weird build error.
Additionally Visual Studio recognizes it
but the IDE itself doesn't crash.
To check if it only happens to our own solutions I created a new simple, plain command line tool project which shows the same build behavior. So it isn't exclusive to our solutions.
I tried to get help from Microsoft but it seems they don't know what to do about it. The thread doesn't show all the material I provided to them. They got a lot of logs and a sample project from me. A crash dump wasn't possible to provide, because Visual Studio itself doesn't crash.
Repair and full uninstall, new install of Visual Studio didn't help either.
Edit: It is not only occurring on my development machine but on our build servers (there are two of them), too. Interestingly our VMs on the development machines does not seem to have this issue.
To me it seems, the problem has something to do with loading assembly from GAC, so I would suggest to try reinstalling Microsoft.CodeAnalysis assembly and see if it helps.
To Do that:
Install Microsoft.CodeAnalysis package to your project with it's required dependencies, make sure to note down all assemblies being downloaded.
Run Visual Studio Developer Command prompt as an Admin
Uninstall existing assemblies from GAC by using command gacutil /u [name of assembly] (do this for all assemblies from step 1)
Install newly downloaded dll using command gacutil /u [Path to Dll] for all dlls (do this for all assemblies from step 1)
Remove package from your project
I hope this helps!
Unfortunately in this case you have only three two options:
You could try to describe all the steps to reproduce this crash so much detailed as you could with a lot of screenshot images from this steps. Use for this DOC file format, PDF or some like that. This file you have to send to Visual Studio support.
You could try to create the crash dump. Each time Visual Studio crashes, it will create a dump file devenv.exe.[number].dmp file in the configured location. Each dump file produced by this method will be up to 4 GB. in size. Make sure to set DumpFolder to a location with adequate drive space or adjust the DumpCount appropriately. I know, you wrote already on MS forum that this error doesn't create one dump. But would you like to imagine that you have 10 crashes on a day and on each crash one dump file in size 4 GB. will be written? The dump creating is disabled normaly and you have to enable it. How to enable it you could find using search string in Google: "How to enable dump files in Windows" or for Windows 10 you could see this video. Alternatively or additionally you could use the programm tool "ADPlus" for creating memory dump files and log files with debug output from one or more processes. This tool is very detailed describen on this MS Support page.
You could try to debug by yourself. But in the case if you want do it you have to see "Tools listing Included in Debugging Tools for Windows".
Normaly by Visual Studio support do not work the Visual Studio developers. You have to be nice to them and they do what they can do. You could not expect from them that they all know. They do their job using some given instructions.
In your case the support worker has gived you the link Reporting Visual Studio crashes and performance issues in which you have to read the following part:
Directly reproducible crashes
Directly reproducible crashes are cases which have all of the
following characteristics:
Can be observed by following a known set of steps
Can be observed on multiple computers (if available)
If the steps involve opening a project or document, can be reproduced in sample code or a project which can be linked to or
provided as part of the feedback
For these issues, follow the steps in "How to Report a Problem"
and be sure to include:
The steps to reproduce the problem
A standalone repro project as described above. If this is not possible, then please include:
The language of the open projects (C#, C++, etc.)
The kind of project (Console Application, ASP.NET, etc.)
Any extensions that are installed.
Most valuable feedback: For this case, the most valuable feedback is the set of steps to reproduce the issue along with sample source
code.
Unknown crashes
If you're not sure what's causing your crashes or they seem random,
then you can capture dumps locally each time Visual Studio crashes and
attach those to separate feedback items. To save dumps locally when
Visual Studio crashes, set the following registry entries:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\devenv.exe]
"DumpFolder"="C:\\Crashdumps"
"DumpCount"=dword:00000005
"DumpType"=dword:00000002
⚠️ Each dump file produced by this method will be up to 4 GB. in size. Make sure to set DumpFolder to a location with adequate
drive space or adjust the DumpCount appropriately.
Each time Visual Studio crashes, it will create a dump file
devenv.exe.[number].dmp file in the configured location.
Then, use Visual Studio's "Report a Problem..." feature. It will
allow you to attach the appropriate dump.
Locate the dump file for the crash you are reporting (look for a file with the correct Creation time)
If possible, zip the file (*.zip) to reduce its size before submitting feedback
Follow the steps in "How to Report a Problem", and attach the heap dump to a new feedback item.
⚠️ Do not attach heap dumps to existing feedback items. Please create a new feedback item for each heap dump you would like to
submit. If you were requested to provide a heap dump in order to
resolve a previous feedback item, simply reply to the request with a
link to the new feedback item where the heap dump is attached.
Most valuable feedback: For this case, the most valuable feedback is the heap dump captured at the time of the crash.
Please read it very carefully and in best case two or even tree times successively.
I hope it will help you and I wish you good luck!
As suggested with Dipen in another answer problem seems to be in Microsoft.CodeAnalysis try reinstalling nuget package for that & re-register in GAC if missing.
If Issue still exists, you can try disabling code analysis on your project like:
In Project in VS 2017, open References & right click on Analyzers and click on Open Active Rule Set like:
Uncheck all rules so that no code analysis is done on your project like:
3 .Save All files and now try rebuilding & run the project to see if issue is resolved.
The issue was an older JustMock version installed. Could only solve it with the help of the Roslyn team.
I recently switched all of my unit tests over from xunit to mstest, and on my local dev machine everything works great, but when I try to run my tests using a CI build in VSTS, it doesn't recognize any tests in my test dll, stating:
"Warning: No test is available in
c:\vsts_work\4\s\test\UnitTests\bin\Release\net452\UnitTests.dll".
I believe I have all of the important project.json bits in place:
"testRunner": "mstest",
"dependencies": {
"dotnet-test-mstest": "1.0.1-preview",
"MSTest.TestFramework": "1.0.1-preview"
}
Of note, I am using an on-premise build agent, but I've proven I can log into that build agent using the service account under which the agent runs, and I can open visual studio and run the tests that way.
Also, while one could contrive it by looking at the above path, it is worth explicitly noting that I'm using the full framework.
Hoping someone out there has already conquered this one.
I figured out how to use the "Visual Studio Test" action, thanks to this stackoverflow post
The only thing that answer lacks is how to make it work in VSTS (the answer provides the command line). To get it to work in VSTS, I put the following string in the "Test Assembly" parameter
**\test\**\project.json
And then put the rest of the command line arguments under "Advanced Execution Options" in the "Other console options" box.
/UseVsixExtensions:true /logger:trx
Hope this helps the next guy who is trying to stick with the visual studio tooling.
To run a .NET Core test during the build, you can add a "Command Line" task to run "dotnet test" command and set the "Working Folder" to the path where the "project.json" file placed:
I had a similar problem, getting the "Warning: No test is available" issue when I was looking right at the tests in Visual Studio.
It turns out the tests were trying to run in x86 when the application is 64 bit.
I recommend going to the Test menu at the top of Visual Studio, and open
Test>Test Settings>Default Processor Architecture>
and make sure the tests are on the right architecture, if you have a similar problem and the other answers aren't helping.
My app keeps getting this error (I'm using VS 2013, VB.NET, and Windows 8.1, by the way):
Could not run the "GenerateResource" task because MSBuild could not create or connect to a task host with runtime "CLR2" and architecture "x86". Please ensure that (1) the requested runtime and/or architecture are available on the machine, and (2) that the required executable "C:\Program Files (x86)\MSBuild\12.0\bin\MSBuildTaskHost.exe" exists and can be run.
The app is for .NET 3.5 (3.5 and lower versions get me this error).
I try to run the app again. Sometimes, it works; sometimes, the error comes back.
I already tried looking up for answers at Google and the answer they gave me turned out to be: "Your build's username is too long" (they said that 20 characters or more cause the error), but it's not true. My user name is 5 characters only. Anyway, I don't think my build's username's length has anything to do with it; it makes no sense.
Does anyone know what is wrong with 3.5 and lower versions? Thank you.
This fixed the issue on my machine:
To resolve it, go to your csproj file and add the following line under the default property group:
<PropertyGroup>
...
<DisableOutOfProcTaskHost>true</DisableOutOfProcTaskHost>
</PropertyGroup>
Found here.
Clean and rebuild solution worked for me.
Adding this in each project is a cumbersome task. So you can set it in the environment variables.
Click Start>> Right-click Computer >> Properties >> Advanced system settings >> Click Environment Variables button to open the dialog, then under the System variables section, click New… button, type the Variable name = DISABLEOUTOFPROCTASKHOST, and type the Variable value = 1, then click Ok.
More here
I'm using VS 2013, VB.NET, and Windows 10, 64 bits, by the way
Just change in XML properites , Services : .NET Framework 4.6 instead .Net Framework 2.0 (Default)
and working fine for me.
I try adding the follow but didn't works
<PropertyGroup>
...
<DisableOutOfProcTaskHost>true</DisableOutOfProcTaskHost>
</PropertyGroup>
this solve this issue for me, adding the same as enviroment Variable
DisableOutOfProcTaskHost=true
I encountered this error when trying to build a sample solution that was included in some software that was installed under C:\Program Files\. Visual Studio prompted me to restart with elevated privileges (as it does when opening a solution in a "secure" location), however the build failed with the OP's error message.
Copying the solution to a "normal" folder (e.g. C:\Temp) solved it for me.
I tried opening an old VS2010 vb project inside VS2013 recently and just ran into this problem. I got around it this way:
I went to the vb project's properties page
I clicked the "Debug" tab
In the "Enable Debugers" section, I saw that the "(x) Enable the Visual Studio hosting process" checkbox was already checked.
I tried un-checking the "( ) Enable the Visual Studio hosting process" option
I saved these changes (Ctrl+S)
I then checked the "(x) Enable the Visual Studio hosting process" checkbox once more
I saved these changes (Ctrl+S)
My next re-build of the project was then successful.
Luckily, I was able to observe how the .vbproj file changed in my version control, and saw that it added the following line into it (which was not there before, despite the checkbox already being set initially):
<UseVSHostingProcess>true</UseVSHostingProcess>
None of the answers in this worked for me. I had to run Visual Studio as admin. Hope this helps someone in the future!
If you don't know how to run a program as admin on Windows, click this link.
My app keeps getting this error (I'm using VS 2013, VB.NET, and Windows 8.1, by the way):
Could not run the "GenerateResource" task because MSBuild could not create or connect to a task host with runtime "CLR2" and architecture "x86". Please ensure that (1) the requested runtime and/or architecture are available on the machine, and (2) that the required executable "C:\Program Files (x86)\MSBuild\12.0\bin\MSBuildTaskHost.exe" exists and can be run.
The app is for .NET 3.5 (3.5 and lower versions get me this error).
I try to run the app again. Sometimes, it works; sometimes, the error comes back.
I already tried looking up for answers at Google and the answer they gave me turned out to be: "Your build's username is too long" (they said that 20 characters or more cause the error), but it's not true. My user name is 5 characters only. Anyway, I don't think my build's username's length has anything to do with it; it makes no sense.
Does anyone know what is wrong with 3.5 and lower versions? Thank you.
This fixed the issue on my machine:
To resolve it, go to your csproj file and add the following line under the default property group:
<PropertyGroup>
...
<DisableOutOfProcTaskHost>true</DisableOutOfProcTaskHost>
</PropertyGroup>
Found here.
Clean and rebuild solution worked for me.
Adding this in each project is a cumbersome task. So you can set it in the environment variables.
Click Start>> Right-click Computer >> Properties >> Advanced system settings >> Click Environment Variables button to open the dialog, then under the System variables section, click New… button, type the Variable name = DISABLEOUTOFPROCTASKHOST, and type the Variable value = 1, then click Ok.
More here
I'm using VS 2013, VB.NET, and Windows 10, 64 bits, by the way
Just change in XML properites , Services : .NET Framework 4.6 instead .Net Framework 2.0 (Default)
and working fine for me.
I try adding the follow but didn't works
<PropertyGroup>
...
<DisableOutOfProcTaskHost>true</DisableOutOfProcTaskHost>
</PropertyGroup>
this solve this issue for me, adding the same as enviroment Variable
DisableOutOfProcTaskHost=true
I encountered this error when trying to build a sample solution that was included in some software that was installed under C:\Program Files\. Visual Studio prompted me to restart with elevated privileges (as it does when opening a solution in a "secure" location), however the build failed with the OP's error message.
Copying the solution to a "normal" folder (e.g. C:\Temp) solved it for me.
I tried opening an old VS2010 vb project inside VS2013 recently and just ran into this problem. I got around it this way:
I went to the vb project's properties page
I clicked the "Debug" tab
In the "Enable Debugers" section, I saw that the "(x) Enable the Visual Studio hosting process" checkbox was already checked.
I tried un-checking the "( ) Enable the Visual Studio hosting process" option
I saved these changes (Ctrl+S)
I then checked the "(x) Enable the Visual Studio hosting process" checkbox once more
I saved these changes (Ctrl+S)
My next re-build of the project was then successful.
Luckily, I was able to observe how the .vbproj file changed in my version control, and saw that it added the following line into it (which was not there before, despite the checkbox already being set initially):
<UseVSHostingProcess>true</UseVSHostingProcess>
None of the answers in this worked for me. I had to run Visual Studio as admin. Hope this helps someone in the future!
If you don't know how to run a program as admin on Windows, click this link.
When running a project in Test or Debug configuration in VB.NET using Visual Studio 2012, sometimes it gives the following error as the reason for "Build Failed"
Error 1 Could not copy the file "obj\Debug\MyProgram.exe" because it was not found. MyProgram
There are no issues with the code as it was just compiled seconds before this (sometimes I start the program again just to see how everything gets laid out visually and then go back to the code to make Location adjustments)
What I found is this. If I wait , when I go to test compile again -- it just magically starts working again -- Only to fail again later.
Sometimes, I can get 10-15 good compiles before it wigs out.
About my system configuration:
I do not have any other version of Visual Studio or standalone .NET language installed
The paths are set correctly (else it would never compile in the first place.. not just occassionaly fail)
The program can be a simple program with absolutely no code added (aka... New > WinForms Project > Compile)
The project, language (and all requirements), and project output path are on a local drive that is connected directly to the PC internally (using C:\code* for projects and the standard install location for Visual Studio 2012)
I checked the smart data and scanned my hard drive for any errors ... none ever encountered. The temperature of my system (CPU), and the drive is around 25-30 degrees C.
I am really baffled as to why this happens and at random. I have also tried completely clearing out the bin/ folder, and even Moving the project or repointing where the compiled output path is.
Deleting the .suo file helps sometimes, but not all the time.
I believe this is something that may be able to be tweaked in the UI somehow, however I do not know anything about manually linking and compiling programs.
Lastly -- it does not matter whether I run VS in "Administrator" mode (elevated privileges) or as a user.
Some methods that may help you
Have you tried to reinstall Visual Studio. If that does not work you may need to install some of Windows Updates, the compiler may be missing some essential libraries/references to compile your application.
Check your .Net Target Framework, setting your application to a new framework that you don't have installed can stop the application from compiling yet even stop it from being debugged, having a compiler that is to low, this may come with errors for the compiler but not for the IDE/Visual Studio to notice.
Try cleaning your project solution's output folder by right clicking your solution then try to rebuild your project/solution.
Check your compilation references in your project's properties, check if a reference added is not on your computer
Reinstall/Update .Net Framework, same here some requirements may be missing from your installation
Try installing a newer version of Visual Studio, try Vs2013 - this contains various improvements and fixes, Visual Studio 2015 is fast approaching, a recommendation install VS2015 when the full version gets released it will contain a lot of useful features for future .net programming.
Create an new Administrator account and Run VS with Administrator rights and try compiling then, this fixes some of problems in vs and other microsoft products, it might work here.
Install all of the .Net Frameworks from the lowest to current 4.5, this may help when some of the used references/libraries are not on your local hard drive.
if none of these methods work, i would not know of the problem one last thing you could try is installing Windows to another hard drive and try using that installation of windows and see what happens... Hope this helps.
Best regards!
I faced this kind of problem because of my virus guard
blocked my application(but it is not have any harmful code :) )
exclude your project folder from virus guard
or
simply disable it(not recommended)