SpecFlow.VisualStudio
SpecFlow.VisualStudio copied to clipboard
SpecFlowOSS
when creating a step in another assembly "go to definition" is not working
Scenario: Given our app.config contains the following
And when we use the project ExternalAssembly in the same solution Then coloring and goto definition does not work
• At runtime everything is working • However steps are colored as if they have no binding (purple) • “Go to definition“ does not work
save, close and restart visual studio. Does this fix the issue?
On Thu, Jun 11, 2015 at 1:46 PM, mperetz [email protected] wrote:
Scenario: Given our app.config contains the following
[image: image] https://cloud.githubusercontent.com/assets/12845364/8107271/28674b18-1016-11e5-9751-74e41ec6c1ff.png
And when we use the project externalSteps in the same solution Then coloring and goto definition does not work
• At runtime everything is working • However steps are colored as if they have no binding (purple) • “Go to definition“ does not work
[image: specflow1] https://cloud.githubusercontent.com/assets/12845364/8107156/31cc3f52-1015-11e5-9be7-f44c51b00124.png
[image: specflow2] https://cloud.githubusercontent.com/assets/12845364/8107163/4c366642-1015-11e5-8eb6-cb65e21185f8.png
— Reply to this email directly or view it on GitHub https://github.com/techtalk/SpecFlow/issues/450.
We have tried to restart visual studio, even re-install specflow plug-in. It did not help. We are using Visual Studio 2013.
have you tried clearing the cache files http://stackoverflow.com/a/21536348/97614?
On Thu, Jun 11, 2015 at 2:41 PM, mperetz [email protected] wrote:
We have tried to restart visual studio, even re-install specflow plug-in. It did not help. We are using Visual Studio 2013.
— Reply to this email directly or view it on GitHub https://github.com/techtalk/SpecFlow/issues/450#issuecomment-111139208.
looks like the problem was having the step file in a folder, once we moved the file to the root of the assembly - it started to work...
is this a known issue? should step files be always on the root? (sounds like a bug)
Any chance you could put a project which reproduces this issue up on github? Someone might be able to take a look at it then