The highlighting of feature files gets lost and an exception is thrown after using the git compare view.
To reproduce the issue:
You need a feature file, that is checked-in in a TFS git repository.
As result the feature file in the normal view is not longer highlighted. A reopen is sufficient to get the see the highlighting again.
Visual Studio 2015 14.0.25425.01 Update 3
Specflow 2017.1.6
Part of the ActivityLog.xml
````
[Microsoft.VisualStudio.SharePoint.Designers.Package.DesignerPackage, Microsoft.VisualStudio.SharePoint.Designers.Package, Version=14.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a]
````
The activityLog continues with many exception entries of the same type.
This is a known problem since years. We will probably not fix it, because we started work on a newer editor (where this bug hopefully does not appear).
Can you give us an estimate as to when this new version will be available?
This bug causes me considerable inconvenience on a daily basis. In 2 hours work so far today I have had to restart VS 5 times already!
I am pretty flabbergasted at the attitude towards this bug - how can an issue that causes multiple crashes on a daily basis be known about for years but no fix pushed?
Also, this issue appears to be exasperated by usage of the mouse wheel. I have seen it happen whereby it crashes VS once, so I close and reopen VS, but if I use mouse wheel before things settle down, it crashes VS again.
Hey evilC,
SpecFlow is open source, and relies on users contributing to the source code for development. If a bug is causing you headaches, then that should be all the motivation you need to grab the repo and start fixing it.
OK, we are going to try to get one of our devs to look at it next week - can you maybe supply us with whatever information you have gathered about the root causes of this bug?
Sources of the VS Integration are here: https://github.com/techtalk/SpecFlow.VisualStudio
Prerequisites and debugging should be documented in the readme.md.
No idea what the root cause is of this error. Never found the time to look at it. Sorry.
@gasparnagy anything you could remember?
@evilC If you have problems to start working on the VS Integration, ping me on our Gitter channel.
Taking a brief look at the error and the code, it looks like GetFileScope is being called while the GherkinLanguageService instance is disposed.
So in order to fix, I am unclear which avenue we should be pursuing...
Should we be trying to stop it being Disposed?
Should we be trying to make it gracefully back out if GetFileScope is called while it is disposed?
ie, what would happen if we changed
if (isDisposed)
throw new ObjectDisposedException("GherkinLanguageService");
to
if (isDisposed)
return null;
?
Seeing as, a couple of lines later, I see
if (!waitForResult && lastGherkinFileScope == null)
return null;
I am assuming that returning null is not the end of the world here.
@evilC it would probably just work. do you want to make a PR and check out the integration package generated by the build?
Hi All, I am getting this issue constantly and this seems to have got worse since the latest extension update(2019.0.31.31805) although I cannot prove as you cannot seem to regress the visual studio extension. Did anyone get a solution to this? I get the crash every time I view a git diff then look at a BDD file, no matter what version of specflow I use... Any help appreciated, as its a frustrating issue. thx
Any updates on this perhaps @SabotageAndi ?
No updates
Mine appears to have sorted itself.. the visual studio specflow extension doesnt seems to have been updated tho, that is still on version 2019.0.31.31805 so visual studio 2017 might have been updated that is on version 15.9.12(not sure what is was before). Specflow nuget packages are on version 3.0.213. could try and get your versions to match and see if your issues go..
With VS2019 (including the latest updates) and the newest version of the extension, this issue still exists. I can also see why, looking at the extension code. I'm working on a fix now.
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.
Most helpful comment
With VS2019 (including the latest updates) and the newest version of the extension, this issue still exists. I can also see why, looking at the extension code. I'm working on a fix now.