* 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
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
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 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
Pranav K
Ryan Nowak
Ajay Bhargav Baaskaran
Steve Sanderson
N. Taylor Mullen
Javier Calvarro Nelson
Andrew Stanton-Nurse
Ryan Nowak
Nate McMaster
Nate McMaster
Ajay Bhargav Baaskaran