This change updates the snapshot of components APIs used in compiler
tests and updates the tests to react tot hose changes.
\n\nCommit migrated from c8cc588bca
* Removes the need for a custom property when resolving static web assets from referenced projects
* Rolls in several improvements suggested by the MSBuild folks to improve performance.\n\nCommit migrated from 5335245b08
The code-generated TypeInference type resides in a custom namespace.
Any types that it refers to in user code must be qualified using the "global::" prefix
to avoid type \ namespace conflicts.
Fixes https://github.com/aspnet/AspNetCore/issues/12116\n\nCommit migrated from f0e09e4a97
- The core issue is that the Razor parser splits attribute values based on whitespace. Therefore, when it encounters `@onclick="() => Foo()"` it breaks it into three different tokens based on the spaces involved. This separation results in multiple adjacent classified spans for C# which is currently unsupported by WTE due to multiple seams overlapping. All that being said we have the opportunity to be smarter when generating attribute values that we feel can be simplified or collapsed; because of this in this PR I changed the `TagHelperBlockRewriter` phase to understand "simple" collapsible blocks and to then collapse them. In the future a goal would be to take a collapsing approach to all potential attributes and then to re-inspect each token individually at higher layers in order to decouple our TagHelper phases from what the parser initially parses.
- Added an integration and parser test to validate the new functionality. Most of the testing is from the fact that no other tests had to change because of this (it doesn't break anything).
- Added a new SyntaxNode method `GetTokens` that flattens a node into only its token representation.
aspnet/AspNetCoredotnet/aspnetcore-tooling#11826
\n\nCommit migrated from 80f1bc76a4
Don't even try to review this xD
This change moves RenderTreeBuilder to the .Rendering namespace and then
updates literally every component baseline.
\n\nCommit migrated from aa8624f46e
- Roslyn now default to 8.0 C# so it's no longer specified in a users project file. Because of this restriction we can no longer see the projects `LangVersion` when generating Razor files. Meaning, we can't conditionally generate C# 8.0 aware code because our Razor default is not C# 8.0. Therefore, when we detect that the C# lang version hasn't been provided we don't set a C# version and instead rely on what the default configuration for the Razor project is. In practice this looks like:
- MVC1.X = C# 7.3
- MVC2.X = C# 7.3
- MVC Latest = C# 8.0
- I thought about adding a feature flags variant for `RazorCodeGenerationOptions` but decided not to since C# features are all configurable options that are based on more than just the `RazorLangVersion`.
- Added integration tests to ensure that command line builds with implicit `LangVersion`s result in proper C# nullability handling.
aspnet/AspNetCoredotnet/aspnetcore-tooling#12594
\n\nCommit migrated from f039aa9354
- We would default to improper C# language versions when given non-numeric `LangVersion`s. For instance when given `CSharpLanguageVersion.Latest` we'd default to 7.3 which was inconsistent with how the rest of the C# world functioned.
- Added a test.
aspnet/AspNetCoredotnet/aspnetcore-tooling#11139
\n\nCommit migrated from a08d0b0673
- Updated instances of our code to no longer use reference type checks on `ISymbol`s. This was a new restriction added by Roslyn [here](https://github.com/dotnet/roslyn-analyzers/issues/2084). We also have a follow up AspNetCore issue [here](https://github.com/aspnet/AspNetCore/issues/12747) to bring these level of changes to AspNetCore.
- Had to pin `Microsoft.CodeAnalysis.Analyzers` in our VSIX projects in order to workaround version conflicts of `Microsoft.CodeAnalysis.Analyzers`. The version conflict is introduced from our dependency on `Microsoft.VisualStudio.ProjectSystem.Managed.VS`. It transitively depends on `Microsoft.CodeAnalysis.Analyzers` `2.6.3` where as our latest Roslyn bits transitively depend on `Microsoft.CodeAnlalysis.Analyzers` `2.9.4`. Tried updating to the latest, private, `Microsoft.VisualStudio.ProjectSystem.Managed.VS` but it also had the version conflict.
- Pinned our runtime bits to the latest public Roslyn NuGet package and pinned our tooling bits to the latest private NuGet package (both are compatible flavors of 3.3.0).
\n\nCommit migrated from 83d5e2c36f
- Prior to this a user could have private, protected or public parameters. We now require public and plan to update analyzers to enforce good usage of public component parameters.
- Removed private `ComponentTagHelperDescriptorProvider` workaround. meta data workaround since we no longer operate on private parameters.
- Updated existing tests to not have private parameter setters. I missed these in my last pass.
- Added two new tests to validate parameters which are private or have private setters are ignored.
aspnet/AspNetCoredotnet/aspnetcore-tooling#12291
\n\nCommit migrated from bb543aa166
- Directives utilize helpers to add to colorization errors, etc. in Razor files. These helpers typically look like `MyType __something = default(MyType)`. The issue with this approach is that `default(MyType)` can be `null` yet `MyType` is a non-nullable type. To workaround this restriction I added nulllability forgiveness operators to the type and member directive tokens (the only two that could possibly generate `null` based output).
- Updated baselines to reflect new forgiveness operator.
aspnet/AspNetCoredotnet/aspnetcore-tooling#10919
aspnet/AspNetCoredotnet/aspnetcore-tooling#11478
\n\nCommit migrated from d0617ed578
- Updated `BuildVariables` to lift the `Microsoft.Net.Compilers.Toolset` package version into C# so we can pass it as a parameter to our testapps when building them.
- Flowed the `MicrosoftNetCompilersToolsetPackageVersion` to transitive testapp projects on restore. This enables `build.cmd` to properly pre-build our `testapp` projects with the latest version of Roslyn.
- Added several conditions to detect if a user is attempting to independently build a `testapp` at which point we fallback to using the SDKs Roslyn compiler toolset version.
aspnet/AspNetCoredotnet/aspnetcore-tooling#12268
\n\nCommit migrated from 57a72ecc46
* Correctly set UpToDateReloadFileTypes
UpToDateReloadFileTypes was incorrectly set in the preview6 DesignTime targets and this was worked
around in the SDK's targets. Unfortunately the updated copy of DesignTime targets (current as of 7/13)
also has a bug.
This fixes the issue and adds some tests to verify we're correct with the past, present & future.
Fixes https://github.com/aspnet/AspNetCore/issues/11873
\n\nCommit migrated from 525d0c1ad3
* Fix weakly-typed component bind
The globalization change regressed this. For weakly typed component bind
we don't want to do any conversions, we need the values to match
exactly.
Note that there's no compiler-generated type checks because its
weakly-typed.
* pr feedback
\n\nCommit migrated from 2d74721815
- This is a temporary workaround until we're able to get on the latest SDK which includes the latest Roslyn bits. Without them we can't properly publish testapps in a standalone fashion without investing in temporary infrastructure.
\n\nCommit migrated from 21fcd9c2f5
- Verified the fix with VS16.2-preview2 + latest CLI with modified `Nullable` entry on disk
- Updated tests.
- Note: This change will not pass the build until we have a new CLI that has an updated Roslyn that understands `Nullable`.
aspnet/AspNetCoredotnet/aspnetcore-tooling#10218
\n\nCommit migrated from fee9c35bee
* Update ref assembly APIs
There are some impactful changes here for the compiler that are part of the API review.
The next few commits will implement all of the required changes.
* React to API review + globalization changes
* Updates to generated baselines
* Add missed file
* Update src/Razor/src/Microsoft.CodeAnalysis.Razor/EventHandlerTagHelperDescriptorProvider.cs
Co-Authored-By: Steve Sanderson <SteveSandersonMS@users.noreply.github.com>
* more baseline updates
\n\nCommit migrated from d955be5013
* Make some tweaks to the default content globs
- Don't publish/copy launchSettings.json
- Make sure static content and configuration work with single file turned on
- Added test
\n\nCommit migrated from 63e8681fff
* Modify tag helper infrastructure to configure case sensitivity
* Cleanup and added more tests
* More cleanup and added necessary diagnostics
* More feedback
* Added more tests
\n\nCommit migrated from 20b8286751
- Updated existing tests to use `public` accessibility for parameters. As part of this also updated baselines.
- We now recommend that `[Parameter]`'s should be `public`. In the future this will be a requirement.
aspnet/AspNetCoredotnet/aspnetcore-tooling#8825
\n\nCommit migrated from 2ceb597f82
- Without this any diagnostics from Analyzers will be doubly reported. One for the declaration compilation and one for the view compilation.
aspnet/AspNetCoredotnet/aspnetcore-tooling#8825
\n\nCommit migrated from 6d115d460b
- Added a feature flag to ensure this functionality does not impact pre-3.0 applications. This change is in fact a breaking change because some less-common scenarios will no longer be valid. For instance, `@Name!.Hello`used to treat the `!.Hello` as markup, now it will be treated as part of the expression.ExpressionChunkGenerator
- Updated parser flags tests
- Updated parser tests
- Updated the C# 8.0 integration tests to include the new nullable forgiveness scenarios.
aspnet/AspNetCoredotnet/aspnetcore-tooling#11188
\n\nCommit migrated from 625c605607
This fixes a regression in the new `@ref` support, where the build will
fail during the declaration pass.
The problem is that the EliminateMethodBodyPass runs really early and
wipes out the usage of `@ref` before we have a chance to see it. The
solution is to make it run really late. This makes sense because we
basically just use this pass to do cleanup.
\n\nCommit migrated from 09b50151ef
Adds the code generation support for culture + bind.
Some additonal changes are needed for the compiler support for bind, we
need to pass the culture into the code that unwraps the value as well.
There's no need to eagerly push these changes into the runtime (can wait
for the compiler change to go in) because nothing in our runtime tests
use the new feature.
\n\nCommit migrated from 6aad9748e8
Adds the ability to specify that an `<input type="..." />` for some
specific value of `type` maps to the invariant culture and/or provides
a default format.
The primary examples of usage would be the number field which wants to
use invariant culture, or datetime which wants to use invariant culture
and a format string.
\n\nCommit migrated from 60f2d563a6
Updates our Components shim to use the ref assembly code. This is just
cleanup and will help us keep up-to-date with API review changes since
we can just copy-past the files.
I made two modifications to make this simple.
- Removed our built-in components
- Removed the HTTP stuff
This makes it easier for us to maintain the shim. You can see cases
where I had to update tests because they diverged from what the real
APIs look like (no product bugs).
I'd still like to improve this workflow so suggestions wanted xD
\n\nCommit migrated from 8517be2bac
This change makes @ref define a field for you by default. We didn't do
this originally because we weren't sure if the compiler generating a
field would always be what you want, and more importantly,
we didn't have the expressiveness to add an opt-out.
Now that we have directive attributes, it's easy to create an opt-out
for the field generation. The special thing about it is that where
you opt-out has to be static. For this reason the @bind:suppressField
attribute cannot be used with a value, you either have the flag or not.
Additionally, we don't support automatic field generation for
generics, because usually we can't write the field name. If we
want to in the future could make this work when the generic
type arguments are specified. So in the case of generics,
you have to opt-out, and you will get a diagnostic
that tells you so.\n\nCommit migrated from dadf9faf22
Currently FindAssembliesWithReferencesTo produces a stacktrace when P2P builds fail - for instance
if the referenced project has a compiler error. This changes it to use LogErrorFromException.
In addition, there was a typo in the property that disabled the feature.
Fixes https://github.com/aspnet/AspNetCore/issues/11226\n\nCommit migrated from 87c12a116c
- add feeds that SDK no longer provides automatically when building test apps
- add another allowed build warning in some integration tests\n\nCommit migrated from cfd4698381
* Add TagHelperDescriptorProvider
* Remove bad life-choice
* Add some AddRange love
* Add splatting lowering and codegen
* PR feedback
\n\nCommit migrated from 9c8dd1cae7
* Allow @bind:event override when used with @bind
* Added more tests to cover standalone @bind-value=... case
* fix
\n\nCommit migrated from a399bd072e
- It looks that when we first did VCTH we never put in the effort to reduce our footprint on available parameters for `ViewComponentTagHelper`s. I went ahead and added several underscores to the generated fields/parameters to reduce collisions.
- Updated tests to reflect the new codegen.
aspnet/AspNetCoredotnet/aspnetcore-tooling#8645
\n\nCommit migrated from b545a4de75
* Update build.cmd to install .NET Core into $repoRoot/.dotnet instead of $repoRoot/.dotnet/x64
* Move restore sources from build/sources.props into eng/Versions.props (following arcade conventions)
* Remove usages of RuntimeFrameworkVersion in tests and build
* Update Blazor VSIX to use Arcade VSIX tools
* Rename Common.Tests to IIS.Common.TestLib and make it a test asset
* Remove custom versions props for ANCM installer code
* Remove duplicate references to xunit and remove usages of IsTestProject
* Remove duplicate references to Internal.AspNetCore.Analyzers
* Import Arcade.Sdk props and targets and remove custom versioning props
* Remove references to Internal.AspNetCore.Sdk
* Rename PackageLicenseType => PackageLicenseExpression
* Remove dependency on tasks in Internal.AspNetCore.Sdk, add ref to Internal.AspNetCore.BuildTasks as a temporary workaround
* Use Arcade's nuspec support
* Rename SignalR.Client.FunctionalTests to SignalR.Client.FunctionalTestApp
* Fixes for changes to property evaluation order
* Update BaseLineGenerator to netcoreapp3.0
* React to changes in evaluation order in RPM files and quirks in using <Exec> instead of <Run>
* Update Microsoft.Extensions.ApiDescription.Server to react to changes in Arcade packaging
* Workaround aspnet/AspNetCore#11009
- WTE needs a way to detect if a `TagHelperDescriptor` is a component based `TagHelper` in order to turn features like validation, completion etc. on/off.
- Updated tests to add verification points for the new `IsRazorComponentTagHelper` method.
\n\nCommit migrated from 6fcd12e60b
* Adds support for publishing static web assets
* At publish time, it copies all the referenced assets from referenced
projects and packages into their final locations.
* Automatically pack static web assets for consumption
* Generate Microsoft.AspNetCore.StaticWebAssets.props and pack it into
build\Microsoft.AspNetCore.StaticWebAssets.props
* Generate `<<PackageId>>.props` and pack it into `build\<<PackageId>>.props`
importing Microsoft.AspNetCore.StaticWebAssets.props
* Generate `<<PackageId>>.props` and pack it into buildMultiTargeting\`<<PackageId>>.props`
importing `build\<<PackageId>>.props`
* Generate `<<PackageId>>.props` and pack it into buildTransitive\`<<PackageId>>.props`
importing buildMultiTargeting\`<<PackageId>>.props`
* Pack all the static web assets from the current project into `staticwebassets\**`\n\nCommit migrated from 87817bed3e
* 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
* Update dependencies from https://github.com/dotnet/arcade build 20190423.2
- Microsoft.DotNet.GenAPI - 1.0.0-beta.19223.2
* Adjust to GenApi change in `enum` ordering
- was sorted by name, now by value
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
- 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
- There's nothing specific about the TagHelperResolver that needs to be bound to VS. Moving it to the workspaces assembly so it can be used by VSCode.
- Also changed the `TagHelperResolver` to be an `IWorkspaceService`.
\n\nCommit migrated from 9f73afef3a
Changes:
* Make Visual Studio 2019 a prerequisite for building this repo
* Update .sln files
* Update Windows SDK to 17134
* Update developer docs
* Disable ANCM tests
* Update to .NET Core SDK 3.0 Preview 2
* Use Microsoft.NET.Sdk.Razor as a package consistently accross the repo
* React to changes in metadata from Microsoft.NETCore.App
* React to changes in .NET Core SDK
* Attempt to workaround CodeCheck.ps1 failure which doesn't repro locally or on different agents. Possibly due to differences in the version of the PowerShell task?
* Remove dead YML file
* Rename usages of win7-{x64,x86} to win-{x64,x86}
* Update KoreBuild to 3.0.0-build-20190219.1
* 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
When a `<Reference>` is named `*.Sources`, set PrivateAssets=All (exclude from generated nuspec) and IncludeAssets=ContentFiles (only consume content files, not .dll's)
Changes:
* Add support for a property, `IsAspNetCoreApp`, in the .csproj file of assemblies which are part of the shared framework.
* Remove unused dependencies
* Remove reference which have become part of 'netcoreapp3.0'
- 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
- 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
As part of migrating the CodeGeneration targets in to the Razor.Sdk,
the SDK broke the contract that RazorReferencePaths includes the full closure
of assemblies during tag helper discovery.
This change restores the behavior to be compatible with the 2.x Razor.Design
package and adds tests to verify TagHelper discovery works in a range of projects.
Fixes https://github.com/aspnet/AspNetCore/issues/6825
\n\nCommit migrated from 99938c9b7e
* Remove unused package versions
* Remove references to Html.Abstractions
Removing this package since it's from the aspnet/AspNetCore.
* Remove System.ValueTuple package inside remove
* Add versions.details.xml items from corefx
* Add Microsoft.NETCore.App
* Fill up Version.Details.xml
* Update dependencies
* Fix failing test
\n\nCommit migrated from bd7fc9ddf6
* Use _RazorComponentInclude to determine the set of files to set Generator property for
* Run RazorGenerateComponentDeclarationDesignTime instead of RazorComponentGenerate during design time builds
* Update design time targets to set Generator for content files with .razor extension.
Fixes https://github.com/aspnet/AspNetCore/issues/6859
Fixes https://github.com/aspnet/AspNetCore/issues/6860
\n\nCommit migrated from 37d96aa417
- Also nuked tests and resource entries specific to the template engine.
Addresses aspnet/AspNetCoredotnet/aspnetcore-tooling#5079
\n\nCommit migrated from d5f0b4c0b4
- 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 bb2134a536
Adds a new API for WTE to call given a TagHelperBinding to determine if
the binding should colorize/classify only the attributes of the HTML
element in source code. This is driven by a new metadata item that the
Components 'directive attributes' all set. There's no way for a user to
access this feature via tag helpers currently, but it could be added
easily in the future.
Also fixing dotnet/aspnetcore-tooling#6376 while I'm in there. 👍
\n\nCommit migrated from df449beea9
The issue here is that the downlevel SDK (2.1/2.2) don't define the
component-related targets needed for the component design time build.
Depending on the ordering of targets, this can break all features in VS
that depend on the design-time build.
Since we want this to noop in those cases, the best fix is to make our
targets depend on a target property that will be empty in the downlevel
SDKS, but will contain our targets in the 3.0 SDK.
(cherry picked from commit dotnet/aspnetcore-tooling@b88b32c73a)
\n\nCommit migrated from 1c4b19ae88
.NET Core 2.0 reached EOL last year. This removes multi-targeting our test projects and test assets to only use .NET Core 2.1 and .NET Framework 4.6.1.
Fixes aspnet/AspNetCoredotnet/aspnetcore-tooling#6480
We were missing handling for the attribute value prefix of a markup
attribute during the markup block rewrite pass. This is properly handled
inside the runtime code writer so you wouldn't see this bug if the
contents of the element were dynamic (and thus could not be rewritten).
Most of the churn here is due to renaming classes. We generally prefer
the term *markup* over *html* in code artifacts, and this was one piece
of new code that refers to html.
\n\nCommit migrated from d16eafd667
Leading up the release of VS 16.0p1 we added workarounds to the SDK to
make Razor fall back to the 2.1 configuration for design-time. Since
we're adding the 3.0 language support to preview2 we can remove these
workarounds. These features have been available in internal builds for
some time.
\n\nCommit migrated from e6be8a7a3e
This is the final set of enabling features for VS.. including:
- Adding component types to IDE project engine
- Using file kind in the editor
- Enabling component documents in the project system
- Fixing some bugs in the xaml/msbuild authoring
- Adding a missing capability for component projects
The only thing here that probably bears explaining is the class name
mangling. This is a carry over from Blazor, basically because the
generated code is part of the workspace, we have to mangle the class
name to avoid collisions. The work to resolve this is tracked
separately, and will require coordination from a few teams to resolve.
\n\nCommit migrated from d0a8aa3f97
Interim solution to allow components to share the .cshtml extension. When declared in
the project file, the SDK will prevent RazorComponent items from being included
in the RazorGenerate itemgroup.
\n\nCommit migrated from 92e2c70b69
This is a bug fix for the RazorComponentWithTargetPath xaml rule. We
need to have separate targets for components and views.
The other fix here is a change to the set of workarounds we're using for
components currently. We need this project capability for the correct
project host to be used when loading the project.
\n\nCommit migrated from 78163f7e4f
This commit enables us to initialize projects with the correct file
kind, thus allowing mixed views and components in the same project.
This isn't hooked up to MSBuild yet, so for now nothing will initialize
this code with the correct file kind.
\n\nCommit migrated from 7216d18cfb
This code all got dumped here during the port. This change deletes tests
that have already **moved** to the aspnet/AspNetCore repo.
Also fixed the markup rewriter tests for components.
\n\nCommit migrated from 86cc904004
Fixes: aspnet/AspNetCoredotnet/aspnetcore-tooling#6184
This gives us parity with the current behavior. Since comments aren't
meaningful in a component/render-tree context, we ignore everything
inside of them for codegen/lowering.
\n\nCommit migrated from 7250dd2624
We need to be able to wire up these features from outside of the Razor
repo. For layering reasons this can't be done in the main Razor
assembly, so it can't be done by default.
\n\nCommit migrated from 386e2b3797
The issue here is that the compiler generates a different syntax tree
for `data-` attributes :(. I've added a note to dotnet/aspnetcore-tooling#6112 to follow up on
the compiler behavior. We used to parse data- attributes differently for
components, but I really don't think having the compiler special case
them makes sense.
For now I've added a workaround here to lower `data-` attributes in a
fashion similar to other dynamic attribute values.
\n\nCommit migrated from f5109fbfec
The bug here is that we have extra whitespace being written out when the
component renders. This happens because parser adds an empty C#
statement node to wrap all of the whitespace that precedes `@functions`.
This is tracked by aspnet/AspNetCoredotnet/aspnetcore-tooling#6207.
To fix this issue I'm allowing the whitespace pass to skip over an empty
C# statement to remove whitespace. This is sound because an empty C#
statement produces no output - we allow removing whitespace before and
after all nodes that produce no output.
\n\nCommit migrated from e68d93f458
This change contains the enabling features to use Razor Components in a
class library. Currently we require a few workarounds, see the test
project file. This is good enough to get things unblocked.
One part that was needed was to register the correct component features
in the rzc. This is a good example, of why we don't like to add new
features that get registered conditionally, it's error-prone :)
The other part that was needed was to make some of the MVC-related
features for assembly attributes conditional on the TFM. We need to be
able to use the 3.0 (all inclusive) SDK, but without the MVC-related
features. This isn't the right heuristic, but it gets us unblocked.
\n\nCommit migrated from 8dbf02076b
This change ports the existing Blazor component compiler features to
work on top of the Razor compiler. These new features are on once Razor
Language version is set to V3 or higher.
The tests and code for the old Blazor compiler were added to this repo
in previous changes. This change adds the necessary enabling features,
and gets the tests working.
Code generation for tests tests is identical with a few exceptions.
Design time directives now include line mappings (as they should). The
infrastructure seems to prefer windows style line-endings whereas the
Blazor code did the opposite. I plan to leave this alone unless it's a
problem for testing on *nix.
IR Generation will be cosmetically different due to different node names
and formatting. Structure should generally be the same.
----
In order to implement this support, I had to add the following core
features.
Configuring passes/engine-features based on the langauge version. This
required revisiting a *lot* of old tests and forcing them to use a
version appropriate Razor engine. A lot of our tests for legacy things
were using new versions of the language :(.
Configuring passes/engine-features to switch on/off depending on the
document kind.
Configuring directives depending on the file-kind. Directives are a
parser feature, so this decision needs to be made before the IR phase.
Directives that are specific to a file kind will override directives
that are not - this allows components to customize templates for
instance.
Adding functions/inherits/implements directive as mainline features that
are always on in V3. I'm not quite motivated to do this yet for
typeparam, but we might end up there. Remember that directives are
reserved words in Razor.
\n\nCommit migrated from a04addb86f
This change cleans up the intermediate node types that we have so far
for components and changes the naming, visibility, etc to match our
existing nodes.
The next change will integrate these types with the IR lowering process.
\n\nCommit migrated from 34cf523c0d
Update the build scripts to support building subfolders or subgroups of projects
* Add build scripts for ci
* Remove obsolete scripts
* Add flags like --test and --pack to control running just test or packaging
* Add flags like --managed and --native to control building sub-types of projects
* Remove KoreBuild bootstrapper flags
* Update to extensions 3.0.0-preview.18619.1 (needed to get a fix for aspnet/Extensions#815 to make this change work on MSBuild.exe)
This change adds all of the code from the Blazor/Components compiler into
the Razor language assembly. Minimal refactoring or integration work has
been done, that is next :)
All of the code compiles and all unit tests pass, except the one I had
to skip until integration work is done.
\n\nCommit migrated from aa5c82ca5e
This is a bit of a rework of how we initially set this up, but with more
forethought to how this will work in the project system. I have not yet
surfaced this through VS.
My immediate next step is to light up the component integration tests
and something like this is on the critical path to get that work since
we need a way to specify in tests that a document should be treated as
a component.
\n\nCommit migrated from 6b81da3f02
This is a dump of the existing component codegen tests from
the Blazor effort.
I'm also adding the minimal Component types as a new shim to get things
to compile. This is similar to how our shims work already for MVC.
The next step will be add port functionality until the tests pass.
\n\nCommit migrated from 49f49dd9f0
- This happens because a completion session starts when we've rendered a marker directive token without a line pragma and then we return our parse results which provide a C# buffer with a line pragma. This pull request fixes that.
- Updated tests and verified in VS d16.0stg.
aspnet/AspNetCoredotnet/aspnetcore-tooling#4810
\n\nCommit migrated from ca593c80f7
Replaces package references the following packages with local code:
Microsoft.AspNetCore.Certificates.Generation.Sources
Microsoft.Extensions.CopyOnWriteDictionary.Sources
Microsoft.Extensions.ClosedGenericMatcher.Sources
Microsoft.Extensions.ObjectMethodExecutor.Sources
Microsoft.Extensions.PropertyActivator.Sources
Microsoft.Extensions.PropertyHelper.Sources
Microsoft.Extensions.RazorViews.Sources
Microsoft.Extensions.SecurityHelper.Sources
Microsoft.Extensions.StackTrace.Sources
Microsoft.Extensions.WebEncoders.Sources
- Stop producing the 'Universe' lineup package
- Removes all PackageLineup code
- Use full msbuild on Windows
- Fix invalid reference to internal.aspnetcore.sdk in 2.1.x
- Fix shared folder references for PackageArchive task.
John Luo
Doug Bunting
Ajay Bhargav Baaskaran
William Godbe
Pranav K
Kevin Pilch
Ryan Nowak
Nick Guerrera
N. Taylor Mullen
dotnet-maestro[bot]
Javier Calvarro Nelson
Ryan Nowak
David Fowler
Steve Sanderson
Nate McMaster
Ajay Bhargav Baaskaran
Alex Lorimer
Ben Adams
dotnet-maestro[bot]
Doug Bunting
Andrew Stanton-Nurse
Sebastien Ros
Nate McMaster
Pavel Krymets
Doug Bunting
Chris Ross
Justin Kotalik