Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

File and Line Numbers for Errors are not Displaying in the Error List Unless the File Is Open

I have a solution where the file name and line number of the error isn't displaying in the Error List, unless I have the file open.

I have another solution where just three errors show up when I build the solution, and they do display the line number and file. If I open the file with the error, another 3 errors pop up, but when I close the file, all the errors disappear until I rebuild again.

The only issue I've seen from googling is that the path is too long or too weird, but I don't think this is an issue. Path is C:\TFS\Apps\Rel_2013.7.1\S3\CrmSvcUtil Extensions for the solution that is partially working and C:\TFS\Apps\Rel_2013.7.1\S3 for the one that doesn't work at all.

Edit 1

Just to make it clear what I'm seeing: I have multiple projects in my solution but one of them doesn't show the file or line number of the error unless the file is open.

In this screen shot I've added two dumb errors, each in a different project, and have built the solution. The Test Project displays the file and line number as expected. The Common project isn't displaying the file or line number error even though it should and does when I actually open the file with the error in it. The Warning isn't displaying the file because it is a project level warning, not a file level warning, this makes sense.

Example Error

When I open the file with the error the file name and the line number do show up, but on a different error:

Error displays along other error

If I change the int to a string, only the line numbered error is removed. I actually have to build in order for the error to be removed.

like image 978
Daryl Avatar asked Oct 25 '13 14:10

Daryl


3 Answers

I had the same issue on projects that are using legacy Workflow framework V3. Interesting to note, that if project has only compiler warnings, the file and line are shown correctly, but error causing all warnings and errors refer to file C:\Windows\Microsoft.NET\Framework\v4.0.30319\Workflow.Targets(121,5):

The nasty workaround that I found is

  1. Unload the project
  2. Comment out at the bottom of the .csproj file the line
<Import Project="$(MSBuildToolsPath)\Workflow.Targets" />
  1. Reload the project and compile it. Compiler errors will be shown with correct file name and line numbers.
  2. Fix compiler errors
  3. Again unload the project, restore Workflow.Targets import and reload the project.

The similar solution was reported to MS https://connect.microsoft.com/VisualStudio/feedback/details/797056/state-machine-workflow-projects-using-vs-2012

If you forget to restore Workflow.Targets import, there will be run-time errors like

System.Workflow.ComponentModel.Compiler.WorkflowValidationFailedException: The workflow failed validation.
   at System.Workflow.Runtime.WorkflowDefinitionDispenser.ValidateDefinition(Activity root, Boolean isNewType, ITypeProvider typeProvider)
   at System.Workflow.Runtime.WorkflowDefinitionDispenser.LoadRootActivity
like image 100
Michael Freidgeim Avatar answered Sep 21 '22 08:09

Michael Freidgeim


Certain errors such as schema errors are reported but don't affect the final build. Depending on the file you may/may not see errors unless the file is open. Here are some things to try

  1. Build in debug/release mode and see if that changes things for either build.
  2. Change the MSBuild Project Build Output Verbosity (Tools-> Projects & Solutions -> Build and Run) to see if that has an effect. I surmise that will only add to the output but not affect on the Error List Window.
  3. Does this happen in VS2013? That might provide a clue.

It is not unusual there to be differences between output builds and intellisense errors as reported.

like image 26
ΩmegaMan Avatar answered Sep 23 '22 08:09

ΩmegaMan


Sounds to me like you are just looking at errors that are generated by the IntelliSense parser. Which only looks at open files. When you close the file then those IS errors will be removed from the list again. Seeing the error list change after you've built and open a file is similarly explained, the IS parser takes over again.

This is all by design, get ahead by just fixing the errors.

like image 27
Hans Passant Avatar answered Sep 19 '22 08:09

Hans Passant