The newline in the warning messages causes the warning message to appear as two separate warnings in the build output:
Microsoft.NET.Sdk.Razor\build\netstandard2.0\Sdk.Razor.CurrentVersion.targets(805,5): warning RAZORSDK1004: One or more Razor view or page files were found, but the project is not configured to add Razor support for MVC. The MSBuild property 'AddRazorSupportForMvc' must be set to correctly
Microsoft.NET.Sdk.Razor\build\netstandard2.0\Sdk.Razor.CurrentVersion.targets(805,5): warning RAZORSDK1004: compile Razor files that target MVC. For more information, see https://go.microsoft.com/fwlink/?linkid=868374.
This change fixes the warning message to appear as a single warning:
Microsoft.NET.Sdk.Razor\build\netstandard2.0\Sdk.Razor.CurrentVersion.targets(805,5): warning RAZORSDK1004: One or more Razor view or page files were found, but the project is not configured to add Razor support for MVC. The MSBuild property 'AddRazorSupportForMvc' must be set to correctly compile Razor files that target MVC. For more information, see https://go.microsoft.com/fwlink/?linkid=868374.\n\nCommit migrated from 373bf2b74f
* Shorten Microsoft.AspNetCore.Razor.Language.Test paths
- aspnet/AspNetCoredotnet/aspnetcore-tooling#9358 and aspnet/AspNetCoredotnet/aspnetcore-tooling#7882
- do 4046 renames
- adjust solutions to renamed directory
- special-case directory of the Microsoft.AspNetCore.Razor.Language.Test project in `TestProject`\n\nCommit migrated from 72b939d855
* Correctly update the .NET Core SDK used in Razor
* Replace LangVersion 8.0 with LangVersion Preview
* Remove AddRazorSupportForMvc from projects that do not require it
* Cleanup how AspNetCore.App is not referenced in the project
* Remove uses of _RazorComponentInclude from tests\n\nCommit migrated from 81ea07caf7
- Obsoleted old `GetItem` API.
- Updated tests to take new API.
- Added a new test to verify the broken scenario.
dotnet/aspnetcore-tooling#8972
\n\nCommit migrated from 2dd34b8dd8
* Move targets for component design time generation to
Components.targets
* Provide a better error message when referencing a 2.x Razor.Design
package in a 3.0 project
* Do not produce a warning for unresolved configuration when building
2.x projects\n\nCommit migrated from b5b1647646
* Better support for _Imports.razor
* Special case component imports when generating code
* Prevent a future VS crash
* Rebased and updated
* update
* Removed unnecessary newline
\n\nCommit migrated from abbfe00bdc
- When adding additional C# 8 tests found that we didn't fully support this.
- Updated the C# 8.0 test to fully encompass everything C# 8.0.
- Added a feature flag to control using variable declaration errors when not top level.
- Added using variable declaration specific tests.
aspnet/AspNetCoredotnet/aspnetcore-tooling#5092
\n\nCommit migrated from ac08ad3659
Updates the bindtaghelperdescriptorprovider to use the changed event property type name on the bound attribute instead of the value property type attribute.\n\nCommit migrated from 3009045206
- Expanded the `ProjectWorkspaceStateGenerator` to extract the C# language version when building the `ProjectWorkspaceState`. This approach enables all platforms to get nullability support without any changes (as long as they support `ProjectWorkspaceState`, which they do). Also, Roslyn suggested that we avoid dealing with LangVersion directly because there are several factors that impact its "effective" value on a project when run in tooling.
- Updated the `LinePragma` code generation to include `#nullable restore` and `#nullable disable` lines to allow for project restored nullability state for user code.
- Added a new `RazorProjectEngineBuilderExtensions` class that adds Roslyn specific project engine modifications. In this case it allows us to set the C# language version for a project engine and configure underlying features accordingly.
- Added a `SuppressNullabilityEnforcement` flag that only turns on if C# < 8 is specified.
- Updated LiveShare, VS4Mac and RazorGenerate to understand CSharpLanguageVersion.
- Added a single test output to show the change.
dotnet/aspnetcore-tooling#5092
\n\nCommit migrated from 1df8128b87
* Support importing components with @using directives
* Suppress taghelper directive completion in component documents
* feedback
* More feedback
* Update tests
* Update CodeAnalysis.Razor tests
* Flow filekind
* Changes
* More code gen tests
* More tests
* fix
* Added more tests
* Made stuff internal
* Filter out temporary tag helper descriptors
* update
* Do the needful
\n\nCommit migrated from 343f37748e
- Allow markup to exist in all code blocks. Prior to this change whenever we'd see nested curly braces we would do dumb brace matching to skip over any potentially risky code; now we treat every curly brace as an opportunity to intermingle Markup.
- One fix I had to introduce was now that functions blocks are parsed like `@{}` blocks I ran into cases where certain reserved keywords would get improperly parsed. This exposed a bug in our parsing where we’d treat **class** and **namespace** as directives without a transition in a `@{}` block. For instance this:
```
@{
class
}
```
would barf in the old parser by treating the `class` piece as a directive even though it did not have a transition. To account for this I changed our reserved directives to be parsed as directives instead of keywords (it's how they should have been parsed anyhow). This isn't a breaking change because the directive parsing logic is a subset of how keywords get parsed.
- One quirk this change introduces is a difference in behavior in regards to one error case. Before this change if you were to have `@if (foo)) { var bar = foo; }` the entire statement would be classified as C# and you'd get a C# error on the trailing `)`. With my changes we try to keep group statements together more closely and allow for HTML in unexpected or end of statement scenarios. So, with these new changes the above example would only have `@if (foo))` classified as C# and the rest as markup because the original was invalid.
- Added lots of tests,
- Modified the feature flag to maintain the old behavior when disabled.
aspnet/AspNetCoredotnet/aspnetcore-tooling#5110
\n\nCommit migrated from 5ffd84e56d
- Added a `FilePathComparison` object since not all string methods allow a comparer.
- Updated `RazorDirectiveCompletionProvider` to also understand `.razor` files. This is an edge case scenario where users have disabled modern completion and are using Razor components (you need a reg key to disable the modern completion or MS needs to disable it).
- Tested this in VS by referencing the latest Razor SDK (preview 3) from NuGet and then replacing the Razor design time targets in VS to be the ones from the preview 3 package.
- Added workspace project state change detector tests.
dotnet/aspnetcore-tooling#8064
\n\nCommit migrated from 6a83ed13fc
- The `DocumentWriter` case should never be called because you need to override a lot of the internals of the RazorEngine to get to the document writer. Therefore, little harm in removing the method.
- `ProjectChangeEventArgs` used to be uised by the LiveShare extension. We've since taken ownership of those bits and no longer need to maintain those constructors.
- `DefaultTagHelperDescriptorProvider.DesignTime` didn't actually do anything. Removing since the code was truly dead and did nothing functionally.
dotnet/aspnetcore-tooling#7146
\n\nCommit migrated from ba6450a695
Ajay Bhargav Baaskaran
Steve Sanderson
Ryan Nowak
dotnet-maestro[bot]
Pranav K
Doug Bunting
N. Taylor Mullen
Javier Calvarro Nelson
Andrew Stanton-Nurse