| T O P I C R E V I E W |
| Uniwares |
Posted - Nov 11 2020 : 1:13:28 PM
Those symbols show up in a VB only solution. The symbols are from a C# project that is in a folder under the solution, but NOT included in the solution neither referenced, the C# project also was never opened in VS.
Not sure if that should show up then or not. Makes not much sense since its not related in any way, except that its on the file system.
|
| 2 L A T E S T R E P L I E S (Newest First) |
| Uniwares |
Posted - Nov 12 2020 : 07:38:31 AM
The solution contains only one VB project using .NET 4.8. The files listed from the C# project, have never been loaded into VS, I extracted them from an archive to look up some code with Notepad++ (yeah, i do use this frequently).
Thats why i wondered if the files should actually show up as references or not. Obviously VA is parsing the files in the folder anyway. |
| feline |
Posted - Nov 12 2020 : 07:08:55 AM
The type of project you are using is probably a factor here.
If you open a C++ project, a .VCXPROJ file in a text editor, all of the code files that are part of the solution are explicitly listed, so VA knows exactly which files it should be parsing.
Do the same thing with a C# project file, a .CSPROJ file and sometimes you get a list of files, and sometimes you don't get any files listed at all. I am not sure of the trigger for the different behaviour, but I think that .NET framework version might be involved, if not the full reason. But when no files at all are listed then the only logical definition of the code to parse is "all code files in all sub-directories".
I don't know if the same happens with different types of VB project, but it wouldn't surprise me.
If you look at the project files that the main SLN file references, which type are they? Do they reference files clearly, or do they just leave us with "look for all code files"?
It is also possible that these symbols are being drawn in from VA's symbol database, not from the current solution. In theory that shouldn't happen, but I wonder if it is happening for you. It would explain some part of the VB colouring problem you are seeing... I have a vague memory that this is a known bug, that you have encountered...
Here we are:
case=142203
It is possible to end up with a corrupt C# symbol database when the solution references NuGet packages, and the sample project that demonstrated the problem came from you. So this could be part of what is going on here. |
|
|
