This was originally a Github Issue in the Dart-Code repository.
1. Context
I've been working on a package that has hundreds of tests, so an easy way of visualizing code coverage would be incredibly handy.
I would like to run my tests with, say, a .vscode configuration with an lcov.info output which would automatically be recognized by VS Code and highlighted on the respective editors with either red or green.
2. What I've Already Tried
I've tried many different solutions in the past few days — months actually — but none of them worked as the ideal one described above:
flutter test --coverage --coverage-path=lcov.info does work to generate the necessary file, but it's clunky to have to visualize it through a 3rd party program such as genhtml, all the more if you're on Windows.
And it does need Flutter in the end, which should not be necessary if you're working on pure Dart...
IntelliJ would supposedly work ideally, but I just can't seem to enable the Run with Coverage button on mine, even after installing the test_coverage package.
Though one person on Gitter told me he has it working on his IntelliJ.
Both the coverage and the test_coverage packages offer something close to what I described above, but their solutions are way clunkier — and on Windows they are tough to set up...
codecov.io is an alternative with a 3rd party, but it's annoying to have to handle this externally when the editor offers a much more flexible and faster experience.
And there is also the problem of ambiguous coverage, which is not clear with respect to codecov.io. For example, if one folder tests stuff that indirectly calls another folder, does that count as coverage for the indirectly called folder as well? That's almost always undesirable.
3. Other Resources
There's this old question on StackOverflow that was helpful initially.
You can take the genhtml.perl script here.
If you have Git for Windows installed on your machine, you already have Perl installed, it should be here: <git-install-dir>\usr\bin\perl.exe
Replace backslash characters (\\) with slash characters (/) in all file path lines (prefixed with SF:) in the lcov.info file.
Run genhtml.perl script. For example — assumed current working directory is root directory of your project —:
<git-install-dir>\usr\bin\perl.exe \
C:\Scripts\genhtml.perl \
-o .\coverage\html .\coverage\lcov.info
Note. It may be useful also to add the --prefix option.
As a result of these actions, you should get generated HTML report in the .\coverage\html/ directory. Open .\coverage\html\index.html file in your browser to see the report.
I hope this helps — at least, it worked for me.
Related
This is a long post, sorry.
I have been trying to start a project, using Rust, but ran into a problem: it just does not work correctly on Linux in VSCode/Atom.
Wasted 3 days, searching online, trying different tutorials/videos - nothing worked + most of the material is from 2017. I have tried Matrix chat, but no one knew what to do. Git too has no solution as people keep suggesting very random things, like "change this variable in toml file to something else, and back again"
Git: https://github.com/rust-lang/rls-vscode/issues/513
I installed (and re-installed rust many times in the last 3 days), and it works just fine from the terminal, but not in the Editor.
Two Issues:
Editors don't see any crates, so you can't run your code from the editor.
Autocomplete does not work (only works on std, not on extra crates you add).
What I did (out of many other things):
install Rust (on Manjaro and Debian computers): curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
Tried stable, beta, nightly (for racer)
Just did a clean install again:
stable installed - rustc 1.40.0 (73528e339 2019-12-16)
Rust is installed now. Great!
Installed Rust (rls) rust-lang.rust extension in VSCode (and rust in Atom)
Created a new project: cargo new test_proj and added new rand = "0.6" to [dependencies] and used cargo build. It did build rand
Added "rust-client.enableMultiProjectSetup": true to the settings file to avoid a warning: A Cargo.toml file must be at the root of the workspace in order to support all features. Alternatively set rust-client.enableMultiProjectSetup=true in settings. by Rust (rls)
I also install 'code runner' extension that I use with Python, C++, and Java, to run the code from within the editor.
So now I have just the main func and it runs just fine from the editor:
Now I add rand and it seems to work, and does SOME auto-completion...
But now it stops working:
OK, I will finish the code and try running it, And now we can't run it anymore as the crate is missing:
OK, let's try Ctrl + Shift + B and try cargo build:
For some odd reason, it is looking in /media/Work/Work/rust_code and not in /media/Work/Work/rust_code/test_proj/
One last thing: let's try running in the terminal:
So it does work just fine.
Sorry for the long post, but I have wasted 3 days now and it still can't get it up and running. Did anyone manage to set this up at all?
It has to be Atom or VSCode as I have all of the other languages/projects setup there + VSCode is listed on the official Rust website, so I presume it should work.
Basically, out of two editors (VSCode and Atom), that have Debugging capabilities, unlike Intellij Rust, both don't work for me and I just can't code in Rust as tools are literally broken/not mature enough for productive work. Please let me know if I am wrong and it is just a case of one little flag, that everyone forgets to mention, is missing in some config.
Short Version
Assuming I understand the issue correctly. Then the various build issues boil down to different ways you're trying to build the project, and attempting to do so in different directories.
TL;DR: The directory you have open in VSCode is the rust_code directory. Close it and instead open rust_code/test_proj. Now the Rust: cargo build (or Rust: cargo run) should work.
Long Version
Editors don't see any crates, so you can't run your code from the editor.
The Rust: cargo build task isn't working, because the directory you have open isn't a "Rust project" (Cargo package), it's a directory containing another directory, which is a Rust project.
Looking at your screenshot shows this, look at how the top line says rust_code/test_proj:
When you execute the task, Cargo is complaining that rust_code/Cargo.toml doesn't exist, which is true since it's located in rust_code/test_proj/Cargo.toml
If you look at the output of this screenshot, you can see that is the case:
Here you're executing cargo run manually. But the important difference is that you're inside the rust_code/test_proj directory.
Lastly simply executing rustc main.rs is failing since you aren't passing the arguments needed. So rustc doesn't know anything about your dependencies.
Try executing cargo build -v then you can see all the arguments that Cargo is passing to rustc.
Autocomplete does not work (only works on std, not on extra crates you add).
Try and open a directory that contains a Cargo.toml, then code completion should work for dependencies. If I don't, then I get the following notification, and code completion only works for the standard library as you said. That being said, RLS is weird sometimes.
If I had to guess, then I think RLS compiles the code, and at some stage extracts the needed information. Thus if the code doesn't compile, then code completion could be affected. But this is 100% an educated guess.
Alternatively, I have heard praise about using IntelliJ + the Rust plugin, but I haven't used it myself yet.
I have figured out one part: problems with running your code from within the VSCode. I had to modify default code-runner command for rust:
Original command:
"rust": "cd $dir && rustc $fileName && $dir$fileNameWithoutExt",
Changed to:
"rust": "if [ $(basename $dir) = 'examples' ]; then cargo run --example $fileNameWithoutExt; else cargo run; fi",
And now it works, and I can run my code quickly.
Part 2: Autocomplete still is very very bad, unfortunately. I am using RLS. there is this thing racer. Is it a better choice?
Alternatively, I have heard praise about using IntelliJ + the Rust
plugin, but I haven't used it myself yet.
As I mentioned in my previous post, IntelliJ, free edition does not have a debugger from what I can see. I need it.
I am wondering how people get a good autocomplete from Rust?
I'm getting the following error when attempting to install a nuget package into a standard .NET framework 4.7 project:
The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters.
I'm using Visual Studio 2017 15.3.3 Enterprise (latest and greatest).
Given that this is my package, I have full control over the source code. The interesting part is that I have used this package in the past with no changes in the name, but for this go round, I rebuilt it to add a feature and am now getting this error.
Even more interesting is that I have packages from the same library, with the same namespace conventions, with longer names, that work just fine and have installed into this same project with no problems at all.
I have already tried shrinking the package name, shrinking the class names within the package itself, cleaning out the build directory, cleaning out the package home from the nuget server (it's a local server with the latest nuget.server installed which otherwise works just fine), and even clearing out the bin directory of the project in question, clearing out ALL the bin directories of ALL the ancestors to the "offending" package, clearing out the package cache, rebooting the computer and rebuilding the entire nuget package chain from scratch, all to no avail. I was told by one of the MS MVP's that "they fixed that". Apparently not.
Any help would be appreciated here, I'm at my wit's end and have run out of ideas to try.
Thanks.
OK, big Thank You #danmosemsft who suggested digging around with the SysInternals process monitor. After fiddling with it for a bit, I finally figured out how to narrow the result set to just file activity. What I noticed, and the nuget engineers should TAKE NOTE of this: The problem was NOT a too-long project name, rather, nuget was attempting to update a package that was no longer there. Why it went away is a mystery yet to be solved. I normally stay out of the packages directory and do not fuss with the packages.config file. I think that this might have to do with my impatience waiting for VS to start, load all the goodies and then allow me to perform a "Manage NuGet packages" - update all. I remember seeing an update to either NUnit or FluentAssertions that wanted to perform some additional file activity aside from just installing the next version, a script I believe. Can't speak to it with assurance, I wasn't paying that much attention as third party updates usually "just work". I didn't see the "finished" line from NuGet so I think that was the root of my problem. Rather than wait until VS has settled down, I pushed it a bit (hey, the buttons responded so there shouldn't be any problems...).
As a result, the packages directory was absolutely chock full of old stuff that did NOT belong there. So, I manually cleaned up all the cruft, manually cleaned up the packages.config file, restarted VS, waited for it to settle down, performed my NuGet updates and viola! no problem - HAVING NOT CHANGED ANY OF THE ANCESTRAL PACKAGE NAMES BY EVEN A SINGLE CHARACTER.
So, what do I conclude from this? It is my belief, and the guys that actually build nuget and nuget.server should take a closer look at the errors being thrown, such that I think that the error is not so much a path too long error, rather it's a "hey, I didn't find the file I expected so the file name is full of junk (and probably too long now) so I'll throw an error that says it's too long and quit". It's seemingly a failure to handle a missing package/package directory that is causing this particular problem
I solved my problem by ensuring that all the package directories were clean of all junk and rebuilding from a clean source. My problem is now solved.
Thanks to all of you that responded.
Update: While the above contributed to the solution, it was NOT the answer. Here is the sequence of events that led to this problem and it's ultimate resolution.
The solution was created in the C:\User\Sam\Documents\Visual Studio 2017\Projects directory with the specified name of AWE.Lib.ADO.MsSqlSvr.ServerEntityHandler. This worked just fine, no errors. However due to a change in naming scheme from on high, the root directory for this project was changed from "C:\User\Sam\Documents\Visual Studio 2017\Projects" to "C:\User\Sam\Documents\Visual Studio 2017\Projects\DotNet_4.7\AWE 8.x". No problem, I thought - given that a co-worker who also happens to be a MS MVP had told me that all naming length restrictions had been removed in VS 2017. So...I moved the project from it's current home to the directory specified. Compiles just fine, brings in UPDATED BUT ALREADY INSTALLED nuget packages just fine, etc.
Or so I thought. When I needed to add a NEW (one that had not been a part of the solution before) nuget package to the mix, I received the above error. Turns out that the new name of the receiving solution is a few characters longer than VS will accept - the naming length restrictions are STILL IN PLACE.
How did I finally solve the problem: After struggling with this, I threw my hands up and decided to start all over again - a true File | New. So, I started with a new solution named as follows:
"C:\Users\Sam\Documents\Visual Studio 2017\Projects\DotNet_4.7\AWE 8.x\AWE.Lib.ADO.MsSqlSvr.HndlrServerEntity"
THIS GENERATES AN ERROR - name too long. I wondered at Nuget's error in that it specifies that the name should be less than 248 characters in length or 260 maximum.
What I am allowed to use iaw the new solution dialog is this: "C:\Users\Sam\Documents\Visual Studio 2017\Projects\DotNet_4.7\AWE 8.x\AWE.Lib.ADO.MsSqlSvr.HndlrServerEnt", for a total of 106 characters in length. If the directory is shortened, I can add to the length of the name. If I shorten the length of the actual solution name, again, VS'll accept it. So long as the total length of directory plus solution name is less than or equal to 106 characters, there isn't a problem.
The nasty bit comes from creating the solution in one location and having it work in all respects just fine, moving said solution to a different directory, still having it function in all respects (I did NOT need to add any new nuget packages yet), then trying to add a new nuget package to the mix after the move. THAT is what triggered the above nuget error.
So...the ultimate "fix", use a shorter name as it seems that 106 characters is the limit despite what the error messages are saying (and what the MS MVP was told/told me).
There is another reason for this error message by the compiler.
While building , make sure the source code is placed at a folder location which is less than 260 characters long.
For example, a path like C:\Users\User\source\Services\Exp\Sample-web-application-indot-net-displaying-RestAPI\Sample-web-application-indot-net-displaying-RestAPI\SportsStore is around 150 characters long but there are sub folders in the solution which in turn have source code files and so on.
Sometimes the overall length of the path of some files breaches the 260 character length.
I think the future versions of Visual Studio would have a bigger length allowance. Until then, we can make sure that our file names are not too long.
I was running into the same issue after I moved a project to another folder. In my case I closed VS renamed the .vs folder in root to 1.vs (effectively removing it) and re-opend my project.
In my case, I was first trying to install a package using Manage Nuget Packages for Solutions and was getting this error. Then I tried installing same package using Package Manager Console and it worked fine. I again uninstalled that package and tried installing using Manage Nuget Packages for Solutions and this time it worked fine as well.
Well in my experience all i had to do is move the entire project to my c: drive, delete unnecessary folders to ensure the path would be shorter. Done deal.
This error comes to me when I tried to copy the project folder to OneDrive and the problem is that OneDrive is not uploading long name files.
I've fixed this issue by just copying the project folder then paste it in the new laptop using USB.
I wish this could help
Move the folder of the project to a folder within a few levels from the root dir. For example the Desktop and voila.
Try to close Solution from File->Close Solution and opening it again.
For my case uninstalling, installing, or even updating NuGet packages, nothing was working but reopening(sometimes you can also close and open Visual Studio again) the Solution did the magic.
I'm looking at using Tesseract to do some work with PDF files, and so I want to use the library rather than an external executable.
I started by downloading the full Tesseract source and looking at building that. Sadly the standard sources don't have any means to build on a non-Linux platform, in my case Windows. There are methods for doing so, and I looked at those.
Firstly the VS2008 build doesn't. I'm aware that it need Leptonica, but I figured I'd tackle that afterwards and just tried to build the existing code. Fails with "fatal error C1083: Cannot open include file: 'allheaders.h': No such file or directory". Nothing to do with Leptonica at this stage, it simply doesn't work.
Even if I were able to get past that, I'd have to build Leptonica, and that requires using GNU tools and therefore an installation of Cygwin, so I gave up. I Have a MingW instatllation, (I've never managed to get Cygwin to work in a usable fashion) but I'm not keen enough to mess with such a complicated and fragile build.
So I decided I'd just use the pre-built binaries which some kind soul creates. Downloaded that from code.google.com. Now I need to look into using the code, so the next obvious step is the Tesseract API example, which states it requires "tesseract-ocr-3.02.02-win32-lib-include-dirs.zip", no problem, because I already have that now.
No real clue as to where the API example wants the files to be placed, but a little messing about gets them in appropriate locations. Press build and "fatal error C1083: Cannot open include file: 'allheaders.h': No such file or directory", just like trying to build Tesseract from source.....
And indeed there is no such file.
So, where is this file ?
I also struggled some time ago to make it works under windows and then I found this git repository : https://github.com/charlesw/tesseract-vs2012
It includes all needed extern library (because Tesseract need Leptonica, but Leptonica also need extern library to handle the different image format) and is also working great with vs 2013.
OK so now I see that allheaders.h is part of Leptonica. Still leaves me wondering why the Tesseract pre-built library requires that I have Leptonica available, I would have expected that to be built-in, I guess it isn't.
I've been trying to build some huge projects in BCB5 for some time now. I want to use the command line tools because it would cut build time by more than 50% (it already takes 4 hours in the IDE). Often, projects will build just fine in the IDE but fail miserably in the command line. I did some digging and discovered this nice little comment in a header file:
__published: // IDE-managed Components
Is this saying that the components that follow can only be built with the IDE open? Please tell me there is a way around this. BCB5 is starting to make me depressed.
Extra info:
Make.exe gives a pile of errors claiming ambiguity between the header file and an imported file. I''m pretty sure the header file is supposed to be referencing the imported file though, rather than comparing with it.
In the header file:
#include <ComCtrls.hpp>
ComCtrls.hpp has the variable TTreeNode.
Error from make:
[exec] Error E2015 .\TMain.h 876: Ambiguity between 'TTreeNode' and 'Comctrls::TTreeNode'
__published: // IDE-managed Components Is this saying that the
components that follow can only be
built with the IDE open? Please tell
me there is a way around this. BCB5 is
starting to make me depressed.
No, this does not mean that you can only build the source in the IDE. It just means that this section is automatically populated by the IDE (the form designer)
While there are good third party solutions (as mentioned by the others) C++Builder 2007 and above made huge improvements in the build system. IDE build times are very similar to command line builds and the MSBuild integration now makes it possible to be sure that the same parameters are passed to the command line tools as are used by the IDE.
Have you tried installing the C++ Compiler Enhancements plugin, by Andreas Hausladen, which improves the compilation speed. I would also recommend installing the DelphiSpeedUp plugin.
I think you need to export the project as makefile, to compile from the command line, because C++Builder 5 project files are XML. Have a look at this article, from the C++Builder Developer's Journal.
If none of the above fails try the official C++Builder Forum.
I've more or less given up on the BCB5 command line tools. It appears that they are fundamentally broken.
I did, however, manage to find a nice open source tool, ProjectMaker, that uses the command line tools effectively. You can find it here: http://projectmaker.jomitech.com.
ProjectMaker fixes up a few of the problems with BPR2MAK, but it's not perfect. Most project build perfectly with ProjectMaker, some still require the IDE. It's not a perfect solution, but it does alright.
I have been used to working with VS2005 and 2008 - using msbuild, etc, but I have inherited a set of projects that have to remain in vc6.0 for now. I don't like opening each project in the developer studio and building. I prefer to build form command line (I am automating the builds). Is this possible?
I have tried the nmake utility, but I still need to open up the projects and save/export the make file. This is tedious if the project changes - each time I have to save the make file. nmake seems to work, but it had a problem when I changed the location of the project in my directory tree (I checked out of svn into a new clean dir to try the build). It seemed to have hard coded paths in it, but I will have to check on that - it might have been a different problem.
Any alternatives out there?
Eventually I will migrate these to 2008, but for now that is not an option.
I'm recording the most important part of your link here - Microsoft has a bad habit of moving stuff around and leaving dead links. Not only is this the most important bit, but it gives enough information to do a search if/when they move it.
Building a Project from the Command Line
You can build a Visual C++ project from the command line without first exporting a makefile (MAKEFILE, or filename.mak) and using the NMAKE utility.
The basic command syntax is
msdev FileName [/MAKE "ProjectName – ConfigName | ALL"] [/REBUILD /CLEAN /NORECURSE /OUT LogFile /USEENV]
where FileName is the name of your project (.dsp) or workspace (.dsw) file.
I think I found m answer here:
http://msdn.microsoft.com/en-us/library/aa699274.aspx
thanks all
of course you can automate. I haven't used vc in years, but I think the compiler is called c8.exe or wow, I can't remember silly little tidbits like that anymore, but look in your vc\bin directory at all the exes and it will be obvious by name.
you can write a batch file worst case. But I also remember the UI having a "create makefile" function. So you do that once, and then just run make from the command line and voila. or maybe it's nmake. Again, been a long long time.
Microsoft provides a command line driver for building Visual Studio projects. In VC6 it's called "msdev" (do msdev /? for a list of options).
At some point (probably VS.NET/VS 2002) they started calling the command line build driver "devenv" for some reason. It has a somewhat different syntax, but for driving builds the options are the same or similar.
We use automated builds at my work place. Essentially just a batch file i fire off from the command line. Let me make sure i am allowed to post some sample code before i go ahead and post it. But yes, it IS possible to automate the build.
Sample Code:
:::::::: CompileSolution :::::::::::::::::::::::::
call X:\BuildTools\bin\BuildVbProj.bat
%COMPONENTNAME% %SOLUTIONDIR%
%PROJFILE% %BUILDOUTPUTFILE%
%PREBUILDFILE% if %ERRORLEVEL% NEQ 0
goto BuildErrors
goto Cleanup
EDIT: The BuildVbProj.bat file ultimately calls VB6.exe in the Program Files\MS Visual Studio\VB98\ folder. Try calling it with "VB6.exe /?" or "VB6.exe -?" and it will show you a list of options. You can basically automate your process using those options.
There should be a similar exe for VC in the VC98 folder as well.
Another option which is less labor intensive is
Pulldown Menu (BUILD)
Select (BATCHBUILD)
Push Button (REBUILDALL)