Whole Tomato Software Forums
Whole Tomato Software Forums
Main Site | Profile | Register | Active Topics | Members | Search | FAQ
 All Forums
 Visual Assist
 Technical Support
 VA Parsing with boost nuget package

You must be registered to post a reply.
Click here to register.

Screensize:
UserName:
Password:
Format: BoldItalicizeUnderlineStrikethrough Align leftCenterAlign right Insert horizontal ruleUpload and insert imageInsert hyperlinkInsert email addressInsert codeInsert quoted textInsert listInsert Emoji
   
Message:

Forum code is on.
Html is off.

 
Check to subscribe to this topic.
   

T O P I C    R E V I E W
darkpotpot Posted - Aug 29 2018 : 05:47:02 AM
Hello,

it's been 5 years we started using Visual Assist and up to now it was very good. We recently switched to Visual Studio 2017 and we also started using nuget package for external libraries. We are using C++.

The problem we have is, most of the time Visual Assist restarts parsing headers in the packages folder. Since we use boost library, it's a lot of header to parse and sometimes we don't have Visual Assist autocompletion/autosuggestion/GoToDefinition... features available for more than 1 minute.

It wouldn't be a problem if it was only after opening a solution, but it happens randomly while using Visual Studio. Suddenly VA reparse headers in the packages folder. Nothing is modified in the folder during this time. I also checked the option "Parse all files when opening a project", but it still keeps reparsing after.

When I go to "VA Options" / "C/C++ Directories", I can see all the nuget folders in "Project Defined" / "System Include files".

Are there any parameters I can modify in order to have a better behavior?
15   L A T E S T    R E P L I E S    (Newest First)
feline Posted - Feb 06 2020 : 10:02:46 AM
Can you please try closing all instances of the IDE and then changing the registry key:

HKEY_CURRENT_USER\Software\Whole Tomato\Visual Assist X\VANet16\ParseNuGetRepositoryFiles2

from 01 to 00 to disable parsing of the NuGet dirs.

That will stop VA from doing a file search in the NuGet dirs and parsing the files it finds, but it won't stop VA from resolving include directives and parsing files from the NuGet dirs that are included in your project, so the end result is dependent upon how 'connected' the nuget files are to your own source files.

You need to make the change while the IDE is closed, since VA writes out its current settings on exit.

This is the registry path for the VS2019 setting, if you are using a different version of Visual Studio you will need to replace "VANet16" with the correct version for your IDE.
ikku100 Posted - Feb 05 2020 : 2:31:37 PM
Hi Feline,

The problem as described by darkpotpot is exactly what I'm facing. I'm using NuGet for many different projects and as a result have over 100 libraries in my nuget "packages" folder. When I clear the symbol database and open my solution again (which uses "only" 10 packages") it parses packages the solution doesn't depend upon. As a result the parsing takes longer than it's supposed to.

When I goto VA options -> C/C++ Directories, with Platfomr="project defined", "Show directories for"="system include files", I can see packages that are definitely not used by the solution. For instance an old Boost version that's used by a completely different solution.

Probably VA doesn't pick up the right include directories as defined by nuget. Could you investigate how that works and in a future release of VA fix that, perhaps? I'm sure many people have this problem but they don't report it, they just experience VA as being sluggish.

I'm on VA build 2341.2.
feline Posted - Sep 11 2018 : 06:24:03 AM
Thank you for the update. It is strange that removing the extra libraries fixed this problem. Based on my tests, and what I am seeing, VA stops parsing at the first matching boost header file it finds, so there is no obvious problem caused by VA having several versions of Boost available to parse.

I just wonder what the full trigger for this problem is. Hopefully now VA is working well again it will stay working, and you won't have any further problems, but obviously, if this problem does come back again please let me know, and any clues you can provide about the trigger would be most welcome.
darkpotpot Posted - Sep 11 2018 : 04:07:00 AM
Oh, glad you have been able to reproduce the first part of the problem.

Yesterday I removed all the boost libraries except the 1.65.1.0 and I only worked on projects using this one. Problem was gone, it took a long time to parse it at the beginning and then it was good all day.
feline Posted - Sep 10 2018 : 10:26:52 AM
Ah, now I see what you are doing, I have been able to reproduce this include directory problem here. I have placed 3 separate solutions together, so that the .SLN files are all in the same directory, but each solution uses a different version of Boost via NuGet. When I open any one of the solutions in VS2017, VA thinks that all 3 versions of Boost are included in the stable include directories list for the solution.

case=119002

So I am seeing the extra directories, but so far I have not been able to reproduce any extra parsing. VA is parsing just the amount of Boost that it needs to, and nothing more. So this problem on its own does not seem to explain the parsing problem you are seeing. So something else must be going on as well here.
darkpotpot Posted - Sep 10 2018 : 03:27:10 AM
The problem is I never told the IDE or visual assist to include those subfolder in the "D:\develop\main\packages" folder. In the solution I listed the info, only boost 1.65.1.0 was used, the other one are used by other solution. Projects inside my solution are all using the same version of boost. But I think I might have an idea why they are listed.

In our company, all solution files (sln) are inside the same directory (d:\develops). So it means they all have the same $(SolutionFolder), which is "d:\develops".
Nuget uses for its packages the folder "$(SolutionDir)\Packages". It means all the nuget packages of all our solutions are inside the "D:\develops\packages" folder. That's why we see other boost folders, or even some libraries not even used in this solution (openssl for exemple). I have the impression that visual assist parse the whole $(SolutionDir)\packages folder instead of only the nuget package folder used.

Maybe you can reproduce it by creating another solution in the same directory (both sln files have to be in the same directory). Then add a nuget package on this solution, then open the other one and the subdirectory should be listed even though it's not used.
feline Posted - Sep 07 2018 : 10:51:27 AM
Currently I know basically nothing about NuGet, so I am learning this and working it out as I go along. At a basic level, if you tell the IDE, and thus VA, that you have the following library directories:

D:\Fruit\Apple\include;
D:\Fruit\Banana\include;
D:\Fruit\Orange\include;
D:\Fruit\Mango\include;

then you are going to want and expect VA to search inside all of these directories for the header files and libraries that you are using.

So, following the same basic logic, if you are including 4 versions of Boost, it would make some sense if VA parsed all 4 versions, especially since your specific bug report is that VA is spending far to much time parsing boost. But for now this is just a theory, just an initial guess.

Trying to set up a proper test here, I have found that I cannot install 2 different versions of the same NuGet package at the same time into a single project. But I can have different versions of the same NuGet package in different projects in the same solution. So I now have a default C++ console application, and I have added 3 C++ dll projects to the solution. Each of these 4 projects uses a different version of the Boost, so I have one solution with 4 versions of Boost.

So far though, based on the status bar messages that flash by to tell me that VA is parsing, VA is only parsing the first version of Boost it is finding.

When you see the problem in your main solution, assume that when you open "foo.cpp" you see VA parsing a lot of Boost code. Once VA has finished parsing, if you now open "bar.cpp" what happens?

If any parsing happens, let it finish, and now return again to "foo.cpp". Is Boost code parsed again, or is VA happy that having parsed it once it still knows and remembers what is going on with the Boost library?

So far I have not been able to reproduce any problems here with my test solution with 4 versions of NuGet Boost, so what ever is happening does not automatically go wrong. So any clues you can give me to help track down the trigger would be very much appreciated.
darkpotpot Posted - Sep 07 2018 : 03:57:09 AM
Yes, there is a reason (well for some of them).

Boost version 1.60 is used by our projects which are still using visual studio 2010 compiler. Version 1.65.1 is used by our main project and version 1.67 is tested on some other projects for validation.

But why Visual Assist is looking into all of them ? In the solution I have, all projects are using version 1.65.1. There are even nuget packages (like pugixml) which are listed but not used in my solution.




feline Posted - Sep 06 2018 : 10:03:16 AM
Is there a reason you have several different versions of Boost, all at once?

Does deleting all of the older versions of the Boost NuGet package make any difference? You also have more than one version of a few other libraries as well. NuGet may manage this so that the compiler only looks at the newest version, but I wonder if VA is scanning all versions equally, which might help to explain what is going wrong here.
darkpotpot Posted - Sep 06 2018 : 05:34:36 AM
Hello,

License: [email protected] (8-user license) Support ends 2018.06.09
VA_X.dll file version 10.9.2270.0 built 2018.04.30
DevEnv.exe version 15.8.28010.2016 Professional
msenv.dll version 15.0.28010.2016
Comctl32.dll version 6.10.9600.18006
Windows 8.1 6.3 Build 9600
16 processors (x86-64, WOW64)
Language info: 1252, 0x40c

Platform: Project defined
Stable Includes:
D:\Develops\Main\packages\boost.1.60.0.0\lib\native\include;
D:\Develops\Main\packages\boost.1.65.1.0\lib\native\include;
D:\Develops\Main\packages\boost.1.66.0.0\lib\native\include;
D:\Develops\Main\packages\boost.1.67.0.0\lib\native\include;
D:\Develops\Main\packages\curl.7.30.0.2\build\native\include;
D:\Develops\Main\packages\libssh2.1.4.3.1\build\native\include;
D:\Develops\Main\packages\libssh2.1.4.3.3\build\native\include;
D:\Develops\Main\packages\openssl.1.0.1.21\build\native\include;
D:\Develops\Main\packages\pugixml.1.9.0\build\native\include;
D:\Develops\Main\packages\zlib.1.2.8.1\build\native\include;
D:\Develops\Main\packages\zlib.v120.windesktop.msvcstl.dyn.rt-dyn.1.2.8.8\build\native\include;
D:\Develops\Main\packages\zlib.v140.windesktop.msvcstl.dyn.rt-dyn.1.2.8.8\build\native\include;
C:\Program Files (x86)\Windows Kits\NETFXSDK\4.6.1\Include\um;
C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\winrt;
C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\shared;
C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\um;
C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\VC\Auxiliary\VS\UnitTest\include;
C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\ucrt;
C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\VC\Auxiliary\VS\include;
C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\VC\Tools\MSVC\14.14.26428\atlmfc\include;
C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\VC\Tools\MSVC\14.14.26428\include;
D:\Develops\Main\Common\AbstractLayer.ColorManagement\Sources;
D:\Develops\Main\Common\AbstractLayer.Graphics.Rembrandt\Sources;
D:\Develops\Main\Common\AbstractLayer.Graphics\Sources;
C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\VC\Tools\MSVC\14.15.26726\atlmfc\include;
C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\VC\Tools\MSVC\14.15.26726\include;
D:\Develops\Main\Common\APPE_Interface\APPE_CMM\Sources;
D:\Develops\Main\Common\APPE_Interface\APPE_CMM\Source;
D:\Develops\Main\Common\APPE_Interface\APPE_Common\Sources;
D:\Develops\Main\Common\APPE_Interface\APPE_Interface\Sources;
D:\Develops\Main\Common\APPE_Interface\APPE_Server\Sources;
D:\Develops\Main\Common\APPE_Interface\APPE_Server\Source;
D:\Develops\Main\Common\APPE_Interface\Marker\Sources;
D:\Develops\Main\Common\APPE_Interface\Marker\build\v141\source\bitblt;
D:\Develops\Main\Common\APPE_Interface\Marker\build\v141\source\framemarker;
D:\Develops\Main\Common\APPE_Interface\Marker\build\v141\source\imagemarker;
D:\Develops\Main\Common\APPE_Interface\Marker\build\v141\source\scanlinemarker;
D:\Develops\Main\Common\APPE_Interface\Marker\build\v141\source\support;
D:\Develops\Main\Common\APPE_Interface\Marker\build\v141\api;
D:\Develops\Main\Common\APPE_Interface\Marker\build\v141\source\common;
D:\Develops\Main\Common\IpdsCmdDll\Sources;
D:\Develops\Main\Common\MODCADll\Sources;
D:\Develops\Main\Common\Rembrandt\LineArtDll\Sources;
D:\Develops\Main\Common\Rembrandt\PluginManager\Sources;
D:\Develops\Main\Common\Rembrandt\PluginManager\Source;
D:\Develops\Main\Common\Rembrandt\Plugins\PL_APPE_Server\Sources;
D:\Develops\Main\Common\Rembrandt\Plugins\PL_BMP\Sources;
D:\Develops\Main\Common\Rembrandt\Plugins\PL_BMP\Source;
D:\Develops\Main\Common\Rembrandt\Plugins\PL_GIF\Sources;
D:\Develops\Main\Common\Rembrandt\Plugins\PL_GIF\Source;
D:\Develops\Main\Common\Rembrandt\Plugins\PL_IPDS\Sources;
D:\Develops\Main\Common\Rembrandt\Plugins\PL_IPDS\Source;
D:\Develops\Main\Common\Rembrandt\Plugins\PL_JP2\Sources;
D:\Develops\Main\Common\Rembrandt\Plugins\PL_JP2\Source;
D:\Develops\Main\Common\Rembrandt\Plugins\PL_JPEG\Sources;
D:\Develops\Main\Common\Rembrandt\Plugins\PL_JPEG\Source;
D:\Develops\Main\Common\Rembrandt\Plugins\PL_NoHeader\Sources;
D:\Develops\Main\Common\Rembrandt\Plugins\PL_SVG\Sources;
D:\Develops\Main\Common\Rembrandt\Plugins\PL_SVG\Source;
D:\Develops\Main\Common\Rembrandt\Plugins\PL_TIFF\Sources;
D:\Develops\Main\Common\Rembrandt\Plugins\PL_TIFF\Source;
D:\Develops\Main\Common\Rembrandt\TypeImageLib\Sources;
D:\Develops\Main\Common\TraceLogDll\Sources;
D:\Develops\Main\Common\TraceLogDll\Source;
D:\Develops\Main\Common\TypeLib\Sources;
D:\Develops\Main\Common\XMLAccessDll\Sources;
D:\Develops\Main\Common\XMLAccessDll\Source;
C:\Program Files (x86)\Windows Kits\8.1\Include\winrt;
C:\Program Files (x86)\Windows Kits\8.1\Include\shared;
C:\Program Files (x86)\Windows Kits\8.1\Include\um;
C:\Program Files (x86)\Windows Kits\10\Include\10.0.10240.0\ucrt;
D:\Develops\Main\Tools\PDF\PDF2Img_CopyToExecutable\Sources;
D:\Develops\Main\Tools\PDF\PDF2Img_CopyToExecutable\Source;
D:\Develops\Main\Tools\PDF\PDF2ImgC\Sources;
D:\Develops\Main\Tools\PDF\PDF2ImgC\Source;
D:\Develops\Main\Tools\Postscript\PSUtils\source\api;
D:\Develops\Main\Tools\Postscript\PSUtils\Sources;

Other Includes:

Stable Source Directories:
C:\Program Files (x86)\Windows Kits\10\Source\10.0.16299.0\ucrt;
C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\VC\Auxiliary\VS\src;
C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\VC\Tools\MSVC\14.14.26428\crt\src;
C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\VC\Tools\MSVC\14.14.26428\atlmfc\src\atl;
C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\VC\Tools\MSVC\14.14.26428\atlmfc\src\mfcm;
C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\VC\Tools\MSVC\14.14.26428\atlmfc\src\mfc;
C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\VC\Tools\MSVC\14.15.26726\crt\src;
C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\VC\Tools\MSVC\14.15.26726\atlmfc\src\atl;
C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\VC\Tools\MSVC\14.15.26726\atlmfc\src\mfcm;
C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\VC\Tools\MSVC\14.15.26726\atlmfc\src\mfc;
C:\Program Files (x86)\Windows Kits\10\Source\10.0.10240.0\ucrt;

feline Posted - Sep 05 2018 : 12:11:58 PM
I ended up with a Universal Windows project since some of the pages I was reading suggested I needed CLI, or something similar to get this to work.

I have now created a new, default C++ console solution, and added the Boost NuGet package to this project. In my VA about information I have this section:

Platform: Project defined
Stable Includes:
C:\src2017\cpp_console_boost_nuget\packages\boost.1.68.0.0\lib\native\include;

which is the directory under which the Boost package has been unpacked and placed. To use it, I can just add:

#include <boost/shared_ptr.hpp>

to one of my cpp files, and everything is happy.

When I re-load the solution VA does not reparse anything from the Boost library.

With the problem solution open can you please go to:

VA Options -> System Info -> Copy Info

and paste the details (from the clipboard) into your reply. This will give us the basic information about your setup, and also tell me if your main solution, with the problem, is doing the Boost include the same way my test solution is.
darkpotpot Posted - Sep 05 2018 : 03:57:28 AM
Hm, I don't know what is C++ Blank App (Universal Windows) ; I always create a Console Application. I forgot to mention that I also disabled Intellisense, I don't know if it's relevant.

I'll also test if I can reproduce it on a smaller C++ solution. Because we can't use VisualAssist anymore in our company since it seems completely broken on VS 2017 in C++ (at least for our projects).



feline Posted - Aug 31 2018 : 09:51:45 AM
It turns out I really don't know anything about NuGet, so I have been working this out as I go along.

On a Windows 10 test machine I have loaded VS2017 (version 15.8.2) and created a new, default C++ Blank App (Universal Windows). Once this was created, I used Solution Explorer and Right clicked on "References", and used "Manage NuGet Packages..." to download and install Boost 1.68.0

Once this had finished my cpp file had been updated with:

using namespace BoostNugetCpp;

So far so good. No sign of VA parsing any Boost directories or header files though. Plus, no sign of any boost entries in listboxes. I am trying to create and use a "boost::shared_ptr" since this is a simple test to start with, but so far no luck.

Am I doing something obviously wrong here? Or missing some key step? So far most of the examples I am seeing for NuGet are aimed at C#, which is a little bit different.
darkpotpot Posted - Aug 31 2018 : 03:15:43 AM
Boost header directory is neither listed in "Additional Include Directories" or "Include Directories" since we use nuget package.

Yes, I have used Boost before without nuget packages and it was working well.

"Parse all files when opening a project" is turned on. I also tried to Clear everything and Rebuild Symbol databases but it's still the same.
feline Posted - Aug 29 2018 : 07:24:06 AM
Can you please look at your project settings, and see if the Boost header directory is listed under either or both of these settings:

Project properties -> C/C++ -> General -> Additional Include Directories

Project properties -> VC++ Directories -> Include Directories

since Boost is being listed in the VA stable include directories it should only be listed in the "VC++ Directories" setting, and not in the "C/C++" setting as well. But if so, I am not sure what is going on here.

Have you used Boost with VA before?

Do you have:

VA Options -> Performance -> Parse all files when opening a project

turned On or Off?

VA only parses the boost headers that have been included, so if you open a file in your solution that VA has not yet parsed, and this is including several new Boost headers, then these headers will then be parsed, but only the once. Once VA has parsed them it should remember them, so any repeated parsing of Boost should soon stop happening.

© 2023 Whole Tomato Software, LLC Go To Top Of Page
Snitz Forums 2000