Whole Tomato Software Forums

Whole Tomato Software Forums

All Forums

Visual Assist

Technical Support

VA 2392: C# symbols from not included project

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

Screensize:

UserName:

Password:

Format:

Message:

Forum code is on.
Html is off.

[quote][i]Originally posted by feline[/i]
[br]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.
[/quote]

Check to include your profile signature.
Check to subscribe to this topic.

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.

Snitz Forums 2000