* Define static web assets in the current project
* These are assets under the wwwroot folder.
* By convention, the base path for these assets is `_content/<<PackageId>>`
with spaces and dots removed and all characters lower-cased.
* Retrieve static web assets from referenced projects\n\nCommit migrated from 50646aae64
* Specify UpToDateReloadFileTypes
Specify a list of file extensions that VS will monitor for file changes to reload the app.
Includes .razor and .cshtml files.
\n\nCommit migrated from 9a964127bf
This came up in the context of discussion around aspnet/AspNetCoredotnet/aspnetcore-tooling#5071.
Browsers use a 'first attribute wins' rule for evaluating attributes and
building the DOM - though duplicate attributes are considered to be a
spec violation.
Blazor wants to use 'last attribute wins' rules because that's most
sensible when you consider evaluation order and splatting.
This means that we have to have the markup block pass do the same thing
as the Blazor runtime when duplicates appear. However, since this is a
spec violation I'm proposing that we just make it an error (like we do
for malformed tags). There's no useful purpose for duplicate attributes
since browsers ignore it.
Since we're not going to allow this for elements. Let's go all of the
way and block it for components as well. And while we're here, lets
block some of the invalid cases where users try to mix onchange and
bind. These don't work today, so we should make them an error. If we
decide to add support for this case to the runtime that would require
compiler work anyway.
\n\nCommit migrated from 0c59ca5f74
* Directive attributes part 1: Support parameters in bound attributes
* update
* Fix test
* feedback
* Updated design
* Do case sensitive comparison
* more
* Bug fix
\n\nCommit migrated from 9bbf240948
* Imports static assets from packages containing custom msbuild
targets defining a StaticWebAsset item group.
* Generates an embeds a manifest into the application assembly
that contains a list of paths to the content roots of the
assets defined in the packages custom msbuild targets.\n\nCommit migrated from 8e70013b70
* Move the globs from the project system into the Razor SDK on a separate file that can be imported by itself.
* Import the file conditionally based on the EnableRazorContent property\n\nCommit migrated from 62e33dac1d
The intention here would have been to add to the existing GetCopyToOutputDirectoryItemsDependsOn property, defined in Microsoft.Common.Targets. Instead what was happening is that it was being completely overwitten with the _RazorGetCopyToOutputDirectoryItems entry, given that $(GetCopyToOutputDirectoryItems) doesn't exist as a property and must have been a typo (it exists as a task, not a property).
An effect of this bug was that the `AssignTargetPaths` target is not always executed before the `GetCopyToOutputDirectoryItems` target, which should explicitly depend on it. `AssignTargetPaths` is responsible for populating the `ContentWithTargetPath` itemgroup. Left empty, it appears to `GetCopyToOutputDirectoryItems` task that there are no Content files to copy to the final output directory, when in fact there are.\n\nCommit migrated from 4597bc3d55
- This is a pre-requisite to properly warnings users about TagHelpers in code blocks. With this change VS indicates that there's an asynchronous operation happening in a code block but because the code is auto-generated it happens behind the scenes and therefore always gets logged as a line 1 error (unusable). Therefore, to fix this issue there will be a partner PR that will go out in AspNetCore that adds analyzer errors for cases where `__tagHelperRunner.RunAsync` exists in code blocks that do not return `Task` and are not marked with `async` properly.
- Updated test files to reflect the new TagHelper codegen at design time.
- Note: This doesn't solve the `~/` case that will be in a follow up PR.
aspnet/AspNetCoredotnet/aspnetcore-tooling#8630
\n\nCommit migrated from 17af3efccd
- This adds support for C# single line variations of: `if`, `for`, `foreach`, `do`, `while`, `lock` and `using`.
- Turns out the existing parser had 99% of the support for these scenarios already. Therefore, in this change set I went ahead and added exhaustive tests to verify things worked end-to-end.
- Added a restriction to single line markup to not allow markup in single line control flow statements. Updated resx to provide a better error message for cases when users do use markup in single line control flow statements.
dotnet/aspnetcore-tooling#9637
\n\nCommit migrated from cf474c97aa
- Diagnostics were not being raised to the `RazorSyntaxTree` and weren't being ordered on final output. This resulted in some of our tests missing the fact that certain cases were generating errors.
- Made all three phases of Razor parsing order their diagnostics.
- Added `GetAllDiagnostics` methods to `SyntaxNode`s to be more consistent with IR documents.
- Updated test files. In some cases new errors were found because we're now lifting them to the `SyntaxTree`, in most others the errors are re-ordered.
**Note: In end-to-end scenarios diagnostics were not hidden, only unordered. The IR phase would find nested/hidden documents and lift them to the IR/C# documents.**
\n\nCommit migrated from ef31a9683b
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
- This would cause our functional tests to time out and occasionally crash due to dotnet first run experience sentinels being locked.
aspnet/AspNetCore-Internaldotnet/aspnetcore-tooling#1859
\n\nCommit migrated from 2668a0e8a9
* Add new APIs to ComponentShim
* Add new APIs to ComponentsApi
* Add EventCallback metadata
* Add discovery of EventCallback properties
* Errata for Runtime APIs
* Add ability to use EventCallback as parameter
* Add support for bind to component
* Use EventCallback for bind-... to elements
* Use EventCallback<T> for event handlers
\n\nCommit migrated from a0b6bc0e52
- Added a step to full fidelity verification that does a `LocateOwner` at every source location. If we find a `null` owner we build a snippet with a detailed response to enable us to diagnose the problem.
Addresses aspnet/AspNetCoredotnet/aspnetcore-tooling#7718
\n\nCommit migrated from 08587a30fd
- Added general C# 8 tests that we can use to include nullability when the time comes.
- Added statement test to ensure syntax tree is correct for await foreach.
aspnet/AspNetCoredotnet/aspnetcore-tooling#5078
\n\nCommit migrated from 27e1d8c011
- Removed the differences of workspace project and `HostProject` in regards to `ProjectSnapshotManager` methods. We now just have `ProjectAdded`, `ProjectRemoved` etc.
- Obsoleted Workspace related members from the `ProjectSnapshot`in order to ensure that current LiveShare continues to work. Once LiveShare has been incorporated into Razor we can remove these members from the project snapshot.
- Removed several TagHelper calculating logic pieces from the document tracker. This is now done entirely from the ProjectSnapshotManager so there's no secondary route that needs to be taken in order to resolve TagHelpers for VS windows cases.
- Updated the `ProjectState` to take in TagHelpers and removed the internal logic it had to resolve TagHelpers.
- Added a TagHelpers property to ProjectSnapshot to indicate that they're no longer calculated, they're part of the project inputs.
- Added a ProjectWorkspaceChange generator to be responsible for calculating any workspace related information that is needed for a `ProjectSnapshot`. For now, this just calculates TagHelpers but in the future it may do more.
- Added a `FilePathComparison` static helper class which acts similarly to `FilePathComparer`.
- Changed our dynamic file info provider to no longer care about `ProjectIds`. Before this, it kept track of the project ids internally but never used them so this is a noop functional change.
- Changed how the out of process remote TagHelper resolution flow works. Prior to this you'd pass a Project across the wire as part of a project snapshot handle and then resolve TagHelpers the old fashioned way.
- Updated all existing tests to respect the new `ProjectWorkspaceState` flows.
- Added tests for new APIs.
dotnet/aspnetcore-tooling#6672
\n\nCommit migrated from a5621641f8
- The SDK tests were occasionally failing with access denied due to the test using the machines dotnet.exe (instead of the local projects dotnet.exe).
dotnet/aspnetcore-tooling#1667
\n\nCommit migrated from 1a96714921
Nate McMaster
Ajay Bhargav Baaskaran
Javier Calvarro Nelson
Pranav K
Ajay Bhargav Baaskaran
Ryan Nowak
Alex Lorimer
N. Taylor Mullen
Steve Sanderson
Ryan Nowak
dotnet-maestro[bot]
Doug Bunting
Andrew Stanton-Nurse
Nate McMaster