I'm just now learning about SpecFlow. I'm trying to work through the BookShop example here and my attempt to Run All Tests reveals a build error:
Error MSB4018 The "GenerateFeatureFileCodeBehindTask" task failed unexpectedly.
TechTalk.SpecFlow.SpecFlowException: Missing [assembly:GeneratorPlugin] attribute in
C:\Users\john.robottom\.nuget\packages\specrun.specflow.3-40\3.4.5\build\\net471\SpecRun.Generator.SpecFlowPlugin.dll
I've googled around, but I'm unclear if I need to downgrade something (if so, what and how to downgrade), un-install and re-install (what), etc.
I don't see how to reply to Greg's questions via a comment (it says I can't comment until I have 50 points). So, here is my attempt to answer to Greg's questions (if you need other info, Greg, just let me know):
SpecFlow.Plus.LivingDocPlugin: 3.4.2
SpecRun.Runner: 3.3.41
I'm using Visual Studio 2019 Enterprise
I'm running tests from Test Explorer in Viual Studio.
Basically, I followed the example and took the latest stable (as of a few days ago) NuGet package for any packages referenced in the example.
The example is at: https://docs.specflow.org/projects/specflow/en/latest/Getting-Started/Getting-Started-With-An-Example.html
Related
I have tried to connect to TFS on my VSCode 1.17.2 by installing Visual studio team services.
Please help me to solve the problem
I test the latest VS Code Version 1.22.2 and everything works as expected.
There is a thread talking about the issue here : https://github.com/Microsoft/vsts-vscode/issues/245
It seems an environment issue based on BrianFarnhill's conclusion:
So based on that I've come to the conclusion that the issue I have
here is nothing related to you guys or your extension, but something
to do with this environment for my customer and it impacting on all
extensions.
So, you can try to troubleshoot the issue based on the discussion in that thread.
If that still not work, you can download the latest VS Code Version 1.22.2, then configure it following the guide here, then check if it works for you.
You can also reference my answer in another thread to do that.
I have installed the Zeos 7 Beta on my own machine but it fails on my client's laptop. We're both running Delphi xe2, his is Entreprise, mine is Pro. His machine is running 64-bit windows 7, mine is running Window 7 32-bit.
When I do Compile all on ZeosDbo or ProjectGoup16 it seems to get through ZCore.dpk but then shows 2 fatal errors:
ZCore.dpk(1) E2225 Never-build package 'ZCore' must be recompiled
ZParseSQL.dpk(33) E2202 Required package 'ZCore' not found
This is production code we are working on, so I hope we can find a solution and get back to working on this
Zeos forum thread: http://zeos.firmos.at/viewtopic.php?t=3633
That is one error, the 1st one. The second is merely post-effect.
Perhaps you can do better than downloading beta ZIPs: until they have mature release you just can download each day "nightly" changes by version-control tools, like Git or SVN or whatever Zeos team is using.
Such errors are usually quickly fixed (they are simple) but long released(they are so moot that no one would bother making release for them).
Just open http://zeos.firmos.at/portal.php and read where to get most instant updates and how to report problems.
Actually - there it is, http://svn.code.sf.net/p/zeoslib/code-0/trunk/
Install TortoiseSVN and be on the edge until 7.0.1 or 7.0.2 final release
The page also says: Please report bugs for this version to our brand new bugtracker on sourceforge https://sourceforge.net/p/zeoslib/tickets/
Please do. Open Source is about participating. At least participate by registering bugs.
About the essence of problem read official documentation and "See Also" section.
Someone should decide about package binary update strategy. And the decision should be kept for all packages (okay, you can mix it in some conditions, but that is not to be suggested). So basically you have three choices:
Make your own decision and put all Zeos packages into the strategy of your choice. That puts the responsibility upon yourself to maintain this fork for a while until you come back to vanilla ZeosDB.
Report the bug to ZeosDB team and ask their suggestion, then change those settings for all the packages as suggested by them.
Report the bug to ZeosDB team and wait until they'd fix it in their SVN and then do SVN Update.
Personally i'd go with 1 option, but i am ready to be FLOSS libraries co-developer.
Option 3 would be the most slow yet the most easy for you.
Option 2... well... i can not see why you should choose that, except for trying to avoid version controls at any cost, which is bad idea per se.
I also suggest you to read http://www.catb.org/esr/faqs/smart-questions.html
That would help you effectively communicate at ZeosDB forums - and you'd have to if you want to be "on the edge" (and if you do not - then wait for public release like 7.0.2).
I have been having this issue with OpenCV 2.4.2 that it doesn't really get installed properly with Microsoft VS 2010 Express; It is always missing a dll file or two doesn't matter what I follow by Googling. Also, Visual Studio 2010 Express is only valid for a few days, so it is acceptable that VS will not behave well with OpenCV at that point. However, when I changed my IDE to CodeBlocks, it is even stranger because now I have missing dll files and also "Missing Entry Point" error because of a duplicate .dll file. I found this guide and followed what it told me to do:
http://conanhung.wordpress.com/2012/05/23/opencv-2-2c-codeblocks-and-mingw-got-it-working-on-windows/
But it still doesn't work!! What I am after is a complete and definitive solution to integrating OpenCV (preferrably 2.4.2 version) on a Windows 7 64-bit machine. I have been turning Stackoverflow inside out but no solution is working for me. The problems are
WHEN USING VISUAL STUDIO:
Missing dll file (e.g. libopencv_core242d.dll, etc.)
WHEN USING CODE BLOCKS:
First it complains that libstdc++-6.dll is missing. When I download it to my C:\MinGW\libexec\gcc\mingw32\4.7.0 folder, it stops complaining about this. But now it complains that there is any entry point problem and some other .dll file is missing!!!
If someone has managed to make it work by hook or crook, I will be more than happy to know what it is, IN DEPTH. I don't believe that such an important library can be so stupidly distributed so that developers have to struggle night and day to make this work.
FYI, I have tried even the OPenCV website and frankly their instructions are a bit useless. Also, all the necessary information e.g. adding PATH, adding includes and libraries, etc. Please someone point me to the right direction as it has been two days and I cannot get anywhere. It is literally stopping my job now :(
As an answer, but probably a very simple one, I did the following and got rid of the problem:
1) Uninstalled code::blocks completely from the PC and downloaded the IDE-only version (i.e. withouth MinGW compiler), then installed it.
2) Downloaded the latest stable version of MinGW, installed, and added C:\MinGW\bin to PATH
3) Followed rest of the instructions from [link] http://conanhung.wordpress.com/2012/05/23/opencv-2-2c-codeblocks-and-mingw-got-it-working-on-windows/
4) Just to be sure, copied the opencv .dll files from the build folder (i.e. the one that you have created "make" and "install" files using CMake) to the debug (i.e. the executables') folder.
This will fix the problems. In case, it doesn't it might be that you need to add some environment variables.
We just set up TFS 11 for the first time. Running a gated check in, it succeeds but returns this message:
'srctool.exe' returned an unexpected exit code: '-1'. An error
occurred when opening a file "CustomDllName.dll": Assembly
"CustomDllName.dll" is not a valid .NET assembly and will be skipped
for analysis.
Well, it's right: that file is a legacy Visual Basic 6 DLL that we don't have much control over. It's included in the project for COM access to some of the methods.
Is there a way to instruct srctool.exe/TFS to skip that file when doing the inspection? Or another way to attack this?
Here is the solution that ultimately worked for me
A member of the TFS 11 team at Microsoft mentioned to me that the problem is due to a change in behavior that the Windows 8 team made to the srctool.exe tool.
By copying this file from the Windows 7 SDK (WinDBG) toolkit and overriding the one included in TFS 11 Beta, I was able to successfully run a build without any errors.
Is this a srctool.exe error from the shipped IndexSources activity? srctool.exe in this activity does one thing, which is to list the source files information in the pdb. I am not a srctool expert so I don't know why it fails in this case. I do know that srctool.exe has some behavioral changes in version 11, most of those are fixes from the previous version.
There is a workaround which requires udpating the build template. It is not very nice but it works. Srctool.exe is run (inside IndexSources activity) for each pdb file in the SymbolFiles collection. Now that you know which pdb fails, you can update the build template to add a RemoveFromCollection activity before the IndexSources activity that remove the troubled pdb from the SymbolFiles collection. This is by far the most straightforward workaround I can think of.
Alternatively, you can edit FindMatchingFiles activity's search pattern to exclude the pdb files you don't want to have sources indexed.
Based on the error message you got, it doesn't seem to be related to the known issue Ed mentioned. We fixed this issue for the next release, so if it's related, it should be fixed :-)
Let me know if you have any issue with VS11 Beta around the build templates.
Thanks.
I may have this completely wrong, but my understanding is that the --standalone compiler option tells the compiler to include the F# core and other dependencies in the exe, so that you can run it on another machine without installing any 'runtime'.
However, I can't get this to work in the CTP - it doesn't even seem to change the size of the output file (docs I've read say about 1M extra).
"Google may know, but if it does, it ain't telling, or I'm not looking in the right place"
UPDATE:
It seems to work with latest CTP update 1.9.6.2
UPDATE2:
I have since experienced another error:
FSC(0,0): error FS0191: could not resolve assembly Microsoft.Build.Utilities.
If you get errors like this when trying to compile --standalone, you need to explicitly include them as references in your project.
Answer from MS:
There is a CTP update 1.9.6.2 that fixed some --standalone bugs.
I'm reinstalling now...
UPDATE:
Works for me - so the my accepted answer is download CTP update 1.9.6.2.
F# manual: Statically linking the F# library using "--standalone"
Did you try to run peverify.exe utility?
This has been a pet hatred of mine for a long time (it has been broken in every CTP release ever including the latest 1.9.6.16 May 2009 release). The "solution" is essentially to write your own build system that is not broken.
This is a real problem for me because I have accumulated hundreds of great F# programs that I would like to put on our site but it takes hours to build each one into a standalone executable.