I've been thinking that MGCB could really use some care to make it more easy to deal with, this includes the following list of changes that I would like to make:
Change the output structure and make it more easy to parse
MSDN: Formatting the Output of a Custom Build Step or Build Event
A result of this is that errors & warnings are shown in the Error List panel of Visual Studio. Currently VS will show a single error about MGCB's errorlevel/ExitCode.
SourceFile, something which now is ignored.The only thing I couldn't fix was to make VS recognize messages with multiple lines as a single error/warning. Probably XNA pipeline implements a logger listener and attaches directly to VS logger provider (or something complicated like that...), bypassing output/parsing altogether.
However, it's still a good idea to improve the output in a standard way.
The only thing I couldn't fix was to make VS recognize messages with multiple lines as a single error/warning. Probably XNA pipeline implements a logger listener and attaches directly to VS logger provider (or something complicated like that...), bypassing output/parsing altogether.
However, it's still a good idea to improve the output in a standard way.
I think multi line errors are nice for debugging in case we have a bug on our end, but horrible for informing the user of the actual error that occurred. I mean just look at: #5790, horrible error information.
That's common with unhandled exceptions!
It doesn't matter what type of exception it was, we would still be writing the entire exception stack. For a new user it would seem more like the compiler crashed than that there is something wrong with the content they are trying to compile...
@nkast My point is error message for compiling content should be short and to the point of explaining what is wrong with the content that the user has tried to compile (and possibly tell you how to fix it, like with compression and power of two options).