-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Use HelpLink for errors/warnings that already have a URL #5493
Comments
@rainersigwald I am interested in doing this if its available. I have not contributed before so any pointers on what I need to do to get involved is welcome! Looking at the code, this enhancement looks fairly straightforward for most cases. How were you imagining storing the urls? For example we currently have:
Would I just add it as another resource following some naming convention like:
|
Hi, |
I think the URLs can be just string literals in the source code. Because HTTP server can redirect the browser to a localised article, MSBuild can use the same URLs for all languages and need not place them in string resources where they could be localised. |
@PeteBoyRocket sorry! I was out on parental leave when you posted and it looks like the team missed this :( Since that was two years ago I'm going to assume you've moved on, as only makes sense . . . @vijaya-lakshmi-venkatraman Yes, I'll assign this to you. As @KalleOlaviNiemitalo mentioned, the URLs can be hardcoded in source, as long as they're fwlink or |
So, the change should be just changing the value tag as below & removing the comment tag? |
Lines 102 to 106 in ef92093
LogErrorWithCodeFromResources could be overloaded with a method that takes a msbuild/src/Shared/TaskLoggingHelper.cs Lines 840 to 850 in 65c50fb
msbuild/src/Shared/TaskLoggingHelper.cs Lines 670 to 683 in 2db11c2
If there is concern about duplicating the same URLs in the source code of many tasks, then they can be defined as const strings in some internal class. Another possible strategy would be to change LogErrorWithCodeFromResources to extract the help link from the resource string, too. This would have a higher risk of breaking compatibility, if some third-party tasks call this method and have URLs in their resources but don't want to use them as help strings. Also, it would require keeping the help links in the resource data and formatting them in a consistent way (e.g. always surrounded with By the way, I assumed that LogErrorFromException would read Exception.HelpLink, but it doesn't seem to do that. |
I agree with your analysis @KalleOlaviNiemitalo though I think I lean toward "make a new method named something like Extracting a URL from the resource sounds nice but a) I'm not sure of the format we'd want to enforce--as you mention should it be |
If the help link were in the resource string, I think it should be near the code, which is likewise extracted and removed automatically: <data name="TaskRequiresFrameworkFailure" xml:space="preserve">
<value>MSB4803 <https://aka.ms/msbuild/MSB4803>: The task "{0}" is not supported on the .NET Core version of MSBuild. Please use the .NET Framework version of MSBuild.</value>
<comment>{StrBegin="MSB4803 <https://aka.ms/msbuild/MSB4803>: "}</comment>
</data> The author of the message could then decide whether to repeat the URI in the human-readable part of the string and how to format it there. |
From scratch I like that approach but I think it'd break existing parsing approaches (like |
Does CanonicalError parse the resource strings? I thought the resources were used only with LogErrorWithCodeFromResources and similar. |
That's true, unless you run MSBuild in an Exec task (shudder) or (more common) parse MSBuild's messages using your own similar regex, like |
How would the resource strings be written to stderr bypassing LogErrorWithCodeFromResources and ResourceUtilities, which would remove the prefix? msbuild/src/Shared/ResourceUtilities.cs Lines 122 to 125 in 2db11c2
|
We have several errors/warnings that have a URL in the text of the message. After #5488 (thanks, @jmezac!) we'll have a structured way to represent this that will eventually (dotnet/project-system#6335) be used in the Visual Studio UI.
We should use that!
Likely candidates:
The text was updated successfully, but these errors were encountered: