I am attempting to run unit tests from Eclipse on C++ code. My Eclipse is Mars.2 Release (4.5.2). I originally downloaded the Java Developer's version, but I've installed C/C++ plugins. I wrote a simple class and then a boost unit test for that class. I can compile the code both in Eclipse and on the command line to get an executable. If I run the executable on the command line, I get this output
Running 1 test case...
*** No errors detected
So far so good.
Now if I try to run inside Eclipse, I get an error. At first it appeared that my test was not running at all. In the "C/C++ Unit" tab, I got a red bar on the right side of the screen, no information where I should be seeing individual test results, and a message "XML parse error: Premature end of file" in small text right below the row of tabs. By stopping in the debugger, I was able to see that I'm victim of a known bug. Basically there's some incompatibility between Eclipse and boost testrunner, where one is specifying XML and the other xml (different case) for the format. I tried this work-around mentioned in the discussion about the bug at that link:
As a workaround you can add following arguments in the unittests' run configuration:
--output_format=XML --log_level=all --report_level=no --
Eclipse's test runner appends it's arguments to these. Arguments after -- are passed on to your test script and ignored by Boost.Test.
With that in place, I still have problems, but the problem is different depending on whether I run with debugging or not. Without debugging, the result is the same as noted above. With debugging, I get information about my test - noting that it ran and passed - on the left side of the "C/C++ Unit" tab but I still get the red bar indicating a failure. The small text in this case says: "XML parse error: Content is not allowed in tailing section."
The bug noted above appears to be about 2 yrs old, although the discussion has activity as recently as last month. I guess there's some other work around? It seems likely that the community has been running tests in the intervening two years!
I tried updating Eclipse via Help -> Check for Updates. That did not improve my situation. I suspect that other information may be valuable to help, but I'm not sure what to provide. I'll watch comments and update if / where I can.
Reluctantly, I upgraded to the Neon.2 release of Eclipse. The underlying bug is still present, as described in my question, but the work-around noted works in that release. Copying that down from the question for completeness:
As a workaround you can add following arguments in the unittests' run configuration:
--output_format=XML --log_level=all --report_level=no --
Eclipse's test runner appends it's arguments to these. Arguments after -- are passed on to your test script and ignored by Boost.Test.
Would have been nice if this worked in Mars as well since upgrading is a bit of a hassle - especially with support for multiple development languages - but at least I can move on. Probably would have had to upgrade at some point in any case.
Related
On a project I am working on, I am maintaining some Feature Tests written in SpecFlow. Our team started using Visual Studio 2017 about a year ago, and we finally got around to doing some upkeep on our tests!
Our tests for the project I'm working on were originally written in SpecFlow 2.3.2, and were last updated in Visual Studio 2015.
The SpecFlowSingleFileGenerator is known to not work on VS 2017, so I spent the better part of yesterday changing our suite to use the MSBuildSingleFileGenerator instead as detailed in this article in SpecFlow's official documentation
Problem:
Locally, I can build my solution, including the Feature Test project just fine.
However, I keep getting the following error when I try to build the project on our build server:
[exec] C:\CheckoutDirectory\My Awesome Project\packages\SpecFlow.Tools.MsBuild.Generation.2.3.2\build\SpecFlow.Tools.MsBuild.Generation.targets(45,5):
error MSB4036: The "GenerateAll" task was not found.
Check the following:
1.) The name of the task in the project file is the same as the name of the task class.
2.) The task class is "public" and implements the Microsoft.Build.Framework.ITask interface.
3.) The task is correctly declared with <UsingTask> in the project file, or in the *.tasks files located in the "C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin" directory. [C:\CheckoutDirectory\My Awesome Project\AwesomeProject.FeatureTest\AwesomeProject.FeatureTest.csproj]
I should point out that our team has no experience with writing MS Build tasks, as hitherto we haven't needed to; we use NAnt build scripts on TeamCity to manage our build work. It's clear that error message would be helpful...if we knew literally anything about it.
Now, normally the correct answer would be: Google it. I did that, and this specific error has no pertinent results.
Additionally, this is blocking my team, since we need our build to work. I don't have the time to do the research and education necessary to properly understand how MS Build technology works. That wil have to come later.
Question:
Bearing in mind that SpecFlow has broken our process, and our team's lack of knowledge about the MS Build system: I need to know how to get around the "GenerateAll" task was not found error. What do I do to get around it?
Secondary Question:
I'm also open to lateral thinking. Is there some way to hack either VS 2017 or SpecFlow to make the SpecFlowSingleFileGenerator "compatible" with each other? The objective here is NOT to avoid making changes, but to control the changes. I need a path towards transitioning from the old file generator to the MS build generation system.
Additional Information:
So, I did some digging, and I found a place where "GenerateAll" is being called in the SpecFlow.Tools.MsBuild.Generation.targets file:
<Target Name="UpdateFeatureFilesInProject"
DependsOnTargets="BeforeUpdateFeatureFilesInProject"
Inputs="#(SpecFlowFeatureFiles)" Outputs="#(SpecFlowFeatureFiles->'%(RelativeDir)\%(Filename).feature.cs')">
<GenerateAll
ShowTrace="$(ShowTrace)"
BuildServerMode="$(BuildServerMode)"
OverwriteReadOnlyFiles="$(OverwriteReadOnlyFiles)"
ProjectPath="$(MSBuildProjectFullPath)"
ForceGeneration="$(ForceGeneration)"
VerboseOutput="$(VerboseOutput)"
DebugTask="$(SpecFlow_DebugMSBuildTask)"
>
<Output TaskParameter="GeneratedFiles" ItemName="SpecFlowGeneratedFiles" />
</GenerateAll>
</Target>
Because I've confirmed that this is being copied out to the build server, the situation is yet more mysterious. It appears that the NuGet package is being pulled down faithfully. Therefore, I can't figure out why my local copy is behaving differently than the copy on the build server.
I am not sure where you found this statement:
The SpecFlowSingleFileGenerator is known to not work on VS 2017
The SpecFlowSingleFileGenerator is working in VS2015, VS2017 and VS2019. We see it as a legacy feature, but it's still there. Since some weeks it is disabled by default, but you can enable it in the options.
It works for SpecFlow >= 2.3.2 and 2.4. For SpecFlow 3 you have to use the MSBuild integration. There are some problems with older versions of SpecFlow, but with them it can also work. It depends on your setup.
About your MSBuild error:
The MSBuild Task for SpecFlow < 3.0 is in the specflow.exe. Is it on your build server?
It is part of the SpecFlow NuGet packages. Normally you get this kind of error if MSBuild can't find the assembly where the task is.
For "debugging" problems with MSBuild, I can highly recommend to use the MSBuild Structured Log Viewer (http://msbuildlog.com/). With it, it makes it easy so see what is happening in your build.
We have an example for MSBuild Code- Behind- Generation with SpecFlow 2.3.2 here: https://github.com/techtalk/SpecFlow-Examples/tree/master/MSBuild/OldCSProj_SpecFlow232
You could compare your project with this example.
Full disclosure: I am one of the maintainers of SpecFlow.
Randomly (and infrequently), Visual Studio (2017) will abruptly refuse to run my C++ project. This will suddenly start happening in the middle of a session.
Visual Studio will still build the project and generate the executable, however, the following cryptic error message appears every time I want to run my program. No changes were made to the configuration or project and it strangely happens after an innocent build.
(It goes without saying but I tried extensively checking for solutions to this problem and no solution worked or was applicable)
Whether I add a new configuration setting or play with the existing settings (Release/Debug, x86/x64), nothing fixes it except performing a full repair (and that takes a very long time). Creating a new project didn't help either, but running it in VS 2015 is successful.
This happens approximately once a week, so I would greatly appreciate knowing how this error can be fixed (or at least avoided).
After some more experience with it, it appears just to be an issue with Visual Studio when builds are too large and executed too often (it happened to multiple computers). More specifically, it could come about as a result of using many templates and applying a large number of explicit template specializations. By building with only the template specializations I need for testing, the issue doesn't come up.
This is usually caused by VS mixing release and debug binaries for me. I have a script which cleans all the output directories, including the garbage VS puts into the projects .vs and Windows Temp folder. This always fixes the issue for me.
After upgrading my .net web project to use Framework 4.6.1 so that I can take advantage of c#6, I have experienced a problem building projects..
I say I have a 'problem' building, it's more like I don't have a problem building. It IS building successfully when in fact it should be failing! Take a look at the screenshot provided; web.config on the left, obvious syntax errors on the right, and a successful build below.
It builds successfully when I do a build / rebuild or run it in debugging; but does actually fail if I try to perform a publish.
Just to further, I have verified that the file that I am editing resides in the correct directory within App_Code, that I am building the correct project and have reset VS multiple times. I've tried to go through all school boy errors; but I think that as it successfully runs but throws a compilation error at that stage it is something down to the Roslyn compiler?
Also note, this is a freshly created project; All I have done is written some basic classes, upgraded the framework, and added a blank aspx page.
Recreating the solution file fixed this error.
Another cause could be down to the fact that I created the project as a WebApplication instead of a Website, but am unsure why this would cause successful builds with syntax errors.
Regenerating the solution with the project setup as a Website instead of a WebAppplication fixed the issue (although I had to change front-end control attributes 'CodeBehind' to 'CodeFile'; a difference between the two types of project).
I've seen a bunch of other questions that are similar to this one regarding VS, but none in regards to the command line.
Using VS Command line (i.e. BuildConsole "SOLUTIONNAME" /BUILD /cfg="CONFIG_SETTINGS" /prf="PROJECTNAME"), I get the highly reproducable (although not 100%) error shown in the question: "The process cannot access the file because it is being used by another process". However, I only get this error the first 1-5 times I run BuildConsole. It seems to be a timing-related thing. If I run BuildConsole once, then wait a while, then run again, it will work. If I run it 5 times consecutively, it will fail all 5 times or sometimes work on the 5th, depending on how fast the previous runs failed. Also, I can get it to work 100% of the time by opening the solution in VS IDE and then closing the IDE and re-running.
This build command is part of a tool that will report failure if the command fails (which it does, most of the time, although it shouldn't fail). So my question is this: how can I get the BuildConsole command to work the 1st time, 100% of the time? Obviously I don't expect it to work if the solution/project is actually being used by another process, but it should be able to take control from whatever is hanging onto the files.
I had the same problem on windows 7, have moved Visual Studio folder from Documents folder to the root of C:\, changed the location in Tools/Options/Help/Import and Export settings to point to the new location, same with Projects and Solutions all pointing to the new location.
No problems with building at all, unless there is an error with the code.
The problem was not running in administrator mode. When I set my C# program that is running BuildConsole to force admin rights, BuildConsole works every time.
There is already a thread here that partially answers my question .
On Eclipse 3.7.2 I followed the approach provided there and I could successfully accomplish the steps creating and setting up a new error parser and adding it to my current project. After executing my Boost.Test (boost rel. 1.48.0) Unit Test, on the Eclipse console I get the same output as the output I get when no parsing is done (e.g. when executing the Unit Test outside Eclipse (e.g. on a Linux terminal)). I searched for a new Eclipse console where the parsed Unit Test output could be displayed (similar to the consoles by e.g. gcov, gprof or cppcheck in Eclipse) but found nothing alike.
Where should the parsed unit test output be displayed? In case the parsed output shall be displayed in the Eclipse Console view, are there any suggestions what might have gone wrong with the parsing in my case?
Thanks in advance.
P.S.: Thanks to casperOne and kleopatra for teaching me manners.
If you're using Eclipse there is also a really nice plugin called TestRunner for running CDT unit tests much like Java or Python unit tests. It handles the unit-testing parsing for you. You'll get a separate console window for your unit tests and it arranges them with level filters. Clicking on an error/warning takes you to the unit-test line number in your editor. You also can set the verbosity level as well as a few other settings from inside Eclipse.
You can directly install the plugin by using the following link in Eclipse updates https://raw.github.com/xgsa/cdt-tests-runner/tests_runner_demo/testsrunner/org.eclipse.cdt.testsrunner-updatesite/site.xml
In order to eclipse parse errors, the error must be print in the console view at compile time. If you are emitting errors in runtime, you must add your program to be called by the Makefile.
That's how I do in embedded systems.