Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Malformed-XML error messages no longer have filename + location #1286

Closed
rainersigwald opened this issue Oct 31, 2016 · 0 comments
Closed

Malformed-XML error messages no longer have filename + location #1286

rainersigwald opened this issue Oct 31, 2016 · 0 comments

Comments

@rainersigwald
Copy link
Member

rainersigwald commented Oct 31, 2016

The error message for bad XML is missing the filename, line, and column location that it used to have.

I suspect this is due to the changes in #1004 (the XmlTextReader we're using no longer knows the path of the file, because we're giving it a stream instead.

Expected and actual output
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003"
      DefaultTargets="t1">
  <Target Name="t1">
    <Message Text= [p2.t1]/>
  </Target>
  <Target Name="t2">
    <Message Text="[p2.t2]"/>
  </Target>
</Project>

Current:

S:\work\1244940>\msbuild\bin\Bootstrap\15.0\Bin\MSBuild.exe pE.proj
Microsoft (R) Build Engine version 15.1.0.0
Copyright (C) Microsoft Corporation. All rights reserved.

Build started 10/31/2016 11:14:10 AM.
Project "S:\work\1244940\pE.proj" on node 1 (default targets).
MSBUILD : error MSB4025: The project file could not be loaded. '[' is an unexpected token. The expected token is '"' or '''. Line 4, position 26. [S:\work\1244940\pE.proj]
Done Building Project "S:\work\1244940\pE.proj" (default targets) -- FAILED.


Build FAILED.

"S:\work\1244940\pE.proj" (default target) (1) ->
  MSBUILD : error MSB4025: The project file could not be loaded. '[' is an unexpected token. The expected token is '"' or '''. Line 4, position 26. [S:\work\1244940\pE.proj]

    0 Warning(s)
    1 Error(s)

Time Elapsed 00:00:00.23

MSBuild 14:

S:\work\1244940>MSBuild.exe pE.proj
Microsoft (R) Build Engine version 14.0.25420.1
Copyright (C) Microsoft Corporation. All rights reserved.

Build started 10/31/2016 11:14:39 AM.
Project "S:\work\1244940\pE.proj" on node 1 (default targets).
S:\work\1244940\pE.proj(4,26): error MSB4025: The project file could not be loaded. '[' is an unexpected token. The expected token is '"' or '''. Line 4, position 26.
Done Building Project "S:\work\1244940\pE.proj" (default targets) -- FAILED.


Build FAILED.

"S:\work\1244940\pE.proj" (default target) (1) ->
  S:\work\1244940\pE.proj(4,26): error MSB4025: The project file could not be loaded. '[' is an unexpected token. The expected token is '"' or '''. Line 4, position 26.

    0 Warning(s)
    1 Error(s)

Time Elapsed 00:00:00.02
@rainersigwald rainersigwald added this to the Visual Studio 15 RTM milestone Oct 31, 2016
rainersigwald added a commit to rainersigwald/msbuild that referenced this issue Oct 31, 2016
When dotnet#1004 moved the standard XML reading approach to be stream-based
rather than file-based, the exceptions thrown on malformed XML
changed--System.Xml no longer knows the path, so it isn't included in the
XmlException. That caused MSBuild to fail to report the location of the
XML error in a nice way as it had done before.

Almost every case where we constructed a BuildEventFileInfo object already
had access to the full path, so I added a constructor that accepted that
as an argument and overrides the possibly-empty path returned from
XmlException.SourceUri.

Fixes dotnet#1286.
@rainersigwald rainersigwald self-assigned this Oct 31, 2016
rainersigwald added a commit that referenced this issue Oct 31, 2016
When #1004 moved the standard XML reading approach to be stream-based
rather than file-based, the exceptions thrown on malformed XML
changed--System.Xml no longer knows the path, so it isn't included in the
XmlException. That caused MSBuild to fail to report the location of the
XML error in a nice way as it had done before.

Almost every case where we constructed a BuildEventFileInfo object already
had access to the full path, so I added a constructor that accepted that
as an argument and overrides the possibly-empty path returned from
XmlException.SourceUri.

Added a unit test to verify that the information is indeed preserved in the exception.

Fixes #1286.
@AR-May AR-May added the triaged label Feb 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants