SpecFlow Version:
2.2.1
Used Test Runner
MSTest
.feature.cs files are generated using
SpecFlowSingleFileGenerator custom tool
Visual Studio Version
VS 2017
Enable SpecFlowSingleFileGenerator Custom Tool option in Visual Studio extension settings
Enabled
Test Execution Method:
Visual Studio Test Explorer & VSTS
In our solution when rebuilding after creating branch from vsts, always error comes for unnecessarily created .feature.cs files. We have lot of json files used in our project under 'TestFiles/' directory. In that in couple of sub folders the .feature.cs files are generated for each json test file. For example if I have a json file named 'test.json', the automatically generated file contains as 'test.feature.cs'. This solution used to work fine earlier. Not sure what happened now. After some changes when ever i rebuild I keep deleting the unnecessary feature.cs files and then continue the work. Even I remove those files and pushed to vsts, the vsts build fails with the same error.
It seems like somehow the specflow file generator wrongly identifies the .json test files as .feature files. I have no idea why this happens. What is the solution for this?
Deleted the auto generation property for each test file in .csproj file. But in vsts again those got regenerated. Not sure why.
You can turn it off in tools -> options -> specflow -> enable SpecFlowSingleFileGenerator
Created a simple framework with Scenario Outline tests, it can be found here. Copied allureConfig.json file into bin/debug directory. Nuget versions:
Nunit 3.9.0;
SpecFlow 2.3.0;
SpecFlow.Allure 2.2.0.11;
Net framework 4.6.2.
After tests execution, using search, I found test-results directory in the next location:
C:\Users\Valentins\AppData\Local\Temp\allure-results
And it contains just .json files, like:
52bb84abaec342e1bf8e7fbc3e46a181-container
and
9ab91b6fc6e84eafbda735c49ccfcb1c-result
Can anyone help to understand, how to make this folder to appear in the tests and how to normally open Test results to see it in Html file?
Thanks in advance,
Valentins.
The problem was because I was running tests, using Visual Studio. When I started to run, using CI server (TeamCity), then allure-results folder appeared in the Project, but for creating a report, allure-commandline-tools were needed.
I'm working on a WPF application, using VS 2017 version 15.3.3
I was curious to know what's behind the file type Azure Function:
When I added it there was nothing changed in the solution explorer, I ignored that and continued my work (which has nothing to do with Azure), but when I compiled the project I get this error:
The target "RunResolvePublishAssemblies" does not exist in the project
and this warning:
Error encountered while loading the project. Some project features,
such as full solution analysis for the failed project and projects
that depend on it, have been disabled
I switched the solution explorer to view all files, and I found the azure function class is hidden in the place I added in, I deleted it, but the same problem still exist
Please, help!
For me this problem was happening because we switched Azure functions project back from dot net core to 4.5.1. So i deleted 'bin' and 'obj' folders from each of the projects, and re-build. It started working fine for me once deleting these 2 folders. I was able to clean and build the projects. My unit tests are also passing fine.
This GitHub error log helped me with this error: https://github.com/Azure/azure-functions-vs-build-sdk/issues/92
Following this suggestion resolved my build error:
To work-around this specific issue , you may be able to give an empty target in your csproj
<Target Name="RunResolvePublishAssemblies" /> but I am not sure what else would be broken without using the SDK style projects.
Scenario: I have 14 projects (each in their own folder in TFS) with an additional folder named AllSolutions to contain all of them. Note not everyone on the team needs all 14 projects this is why I put the AllSolution.sln in its own folder.
The Allsolutions.sln was just upgraded to Nuget 2.0 and it compiles fine! So far so good.
I also have sub-solutions (that contain only those projects they need). These solutions are contained in the root folder shown below as ...Framework...
Problem
Any of the sub-solutions I load show this (whether they have one or more projects) all show missing assemblies:
I suspect that my AllSolutions.sln gobbled them up. Perhaps I need to move all these solutions to the AllSolutions folder? BTW there is nothing that shows up in the output window when I open these sub-solutions.
If I open/edit any of the Proj files this is what I see.
Notice that the Nuget work put in hint paths at the AllSolutions folder.. Do I have to put in Hint paths for all of these and why?
In NuGet 2.0 or in the packages.config world, there is a package folder per solution. The issue you are seeing is due to this. NuGet 2.0 inserts a hint path during package install in the project file pointing to this location. You would need to resolve the relative location for this to work. You can also choose to use the repository path property in NuGet.config to provide a common location for the packages folder. This should solve your problem.
Instead of upgrading to NuGet 2.0, if you are using Visual Studio 2015 and above, I would recommend that you consider moving to project.json. In the porject.json world, you can have a global packages folder and your project file is not modified during package install. For more information on this, check out the wiki entry here
I want to use debug symbols, but I am receiving the following error:
a matching symbol file was not found in this folder
What is this problem, and how to solve it?
One of the things I've ran into with was because debug was off on the project referenced where the code lives. In my case, I made a new configuration called "Developer" and by default debug was turned off.
Right click the project in question
Properties
Build
Advanced (right bottom corner)
Set Debug Info to full
Recompile
I had the same problem as #DmainEvent. Apparently the dll that I was using was not the same version as the pdb that I had just compiled, so I got the error message.
If you have this problem, try using the dll and pdb from the same compilation run.
The error I got was "a matching symbol file was not found in this folder" in the Debug => Modules window even after both the DLL and PDB were available and built together, so I was unable to debug into the target DLL referenced by my main project.
Posting this here in case it helps someone browsing with "Mixed Platform" build for target DLL. I did two things to get past this:
In the solution using the target DLL, Uncheck "Just My Code" in Tools => Options => Debugging => General => Enable Just My Code (JMC).
Check "Enable native code debugging" in target DLL solution in relevant Project Properties => Debug.
I tried all the possible solutions, finally it worked when I disabled the option Enable native code debugging under the Debugger engines of Properties > Debug.
I ran into this problem and the answer was simple.
Visual studio has two project level settings that can create .pdb files.
Linker: Configuration Properties -> Linker -> Debugging -> Generate
Program Database File = "xxxx.pdb"
Compiler: Configuration Properties -> C/C++ -> Output Files -> Program Database File Name =
"yyyy.pdb"
You want #1 for debugging. Forget about #2.
Give file #2 a different name than file #1 to solve this error.
I don't know why microsoft specifies #2 as a .pdb file. That is just confusing.
I have fixed my debug symbols, forcing them to match using this tool:
chkmatch tool
edit: the website is down now. the wayback machine helps: https://web.archive.org/web/20210205095232/https://www.debuginfo.com/tools/chkmatch.html
So, my problem was I was trying to debug my project and the debugger couldn't step-in to the in-house nugets sources. I had the source files of the nuget project. Still the visual studio didn't accept the pdb files I was trying to show it to.
Showing exact same error:
a matching symbol file was not found in this folder
So, what I did was I added this to the .proj file of the nugets project:
<DebugType>full</DebugType>
And created the dll and pdb file again using the rebuild option.
In the command line I ran:
.\ChkMatch.exe -m name_of_your.dll name_of_your.pdb
It said this:
Writing to the debug information file...
Result: Success.
Great success!
So, next, I referenced this dll instead to the proj I was trying to debug. I worked when I tried to load the symbol again.
Hope it helps.
Without more details as to what you're doing, it's difficult to go beyond "the debugger is looking for a symbol file which matches the compiled code, and couldn't find one in the folder where the compiled code lives."
Some things to think about:
Are you creating symbols as part of your compilation? (check the project properties)
Are you using a symbol server (if so, does it point to the right place)
Is this compiled code from a third party? In which case, as you apparently have the source, compile it yourself.
Consider clarifying your question if you want a better answer. Especially what do you mean by "I want use of Symbols".
For BizTalk (and other) projects, it could be because there's a version of the assembly you're trying to debug already in the GAC. When you run a unit test or hit F5 to debug, a new version is compiled locally. However, the version in the GAC is being used, and the newly created PDB doesn't match the DLL in the GAC.
One way around this is to deselect a build for everything except your unit test project using the Configuration Manager, as shown below:
Well, the solution depends on your specific problem. I tried everything that could be possibly found on Stackoverflow and other sites. One of the thread that I followed is this. That did not help too.
The problem was at once resolved when I noticed that my executable project did not contain a reference to the library that I wanted to debug. So I just added the reference to that project.
**PS: ** This problem might also arise because the assembly referenced by the executable assembly might not match that in the references. So in that case, you just remove the already existing reference and add the new one.
Hope this helps!
The same happen to me because the .pdb file of the project have not been copied to the debug\Bin folder, so the symbols could not be loaded from the .pdb file.
You must rebuild your project and manually copy the symbols (.pdb file) to the debug\Bin folder of executable project.
I was trying to load symbols for a installed nuget package published on our local dev server. I had to uninstall and add a normal reference built from the code instead. This worked for me. Just remember install the original nuget package again once finished debugging.
If it works for you, try to embed debug symbols in the dll itself, so the symbols are loaded automatically. This worked for me in netcoreapp3.1 and net5.0:
<DebugType>Embedded</DebugType>
<EmbedAllSources>True</EmbedAllSources>
Beware that you may find this in documentation:
<AllowedOutputExtensionsInPackageBuildOutputFolder>$(AllowedOutputExtensionsInPackageBuildOutputFolder);.pdb</AllowedOutputExtensionsInPackageBuildOutputFolder>
but it does not work.
I ran into this with Visual Studio 2022, tried the most of answers here. Fixed by switching back to Visual Studio 2019, seems like a bug in 2022.
My issue was a bit simpler to resolve, but still the issue the question asked. At first, I was not publishing the pdb file with the nuget package another project was using. Once I confirmed that, I removed the nuget package from my project and readded it from our network nuget source. That still didn't let Visual Studio pick identify the PDB location.
Then I noticed that if you select one of your nuget packages, ( Project --> Dependencies --> Packages --> Choose nuget package), there is a Path property. I checked that location and it pointed to %USERPROFILE%.nuget\packages. The pdb was not at this location and the Date Modified was older than the latest package I published. Once I deleted the folder for the given package version, removed it from my project, and re-added it, the latest .dll and .pdb file were added to this location.
After that, I was able to step into the code of my nuget package and had no further issues.
To get the nuget project to produce the pdb file in the first place, I added <IncludeSymbols>true</IncludeSymbols> inside of a PropertyGroup within the csproj file as other answers had directed.
Once I rebuilt that nuget project, it generated 2 *.nupkg files:
Namespace.x.x.x.x.nupkg
Namespace.x.x.x.x.symbols.nupkg
I found this was because the Properties => Debug => Start Action was set to Start external program instead of the Project. So the newly generated pdb file didn't match, because the actual exe was the wrong one.
I have had this problem recently as well.
Was able to fix it by selecting MyProject->Properties->Linker->Debugging->Generate Debug Info->"Optimize for debugging (/DEBUG)".