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.
(cherry picked from commit dotnet/aspnetcore-tooling@78163f7e4f)
\n\nCommit migrated from f8835ce7a8
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
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
Ajay Bhargav Baaskaran
Ajay Bhargav Baaskaran
Pranav K
Ryan Nowak
N. Taylor Mullen