* 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
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
Ajay Bhargav Baaskaran
Ryan Nowak
N. Taylor Mullen
Steve Sanderson
Pranav K
Ajay Bhargav Baaskaran