- 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.
- Prior to this we were unconditionally adding the `DotNetCoreRazorConfiguration` capability resulting in 1.0 projects looking like 2.1+ projects.
- Added a project capability test that verifies we're maintaining project capabilities for netcoreapp3.0 projects.
- Added a project capability test that verifies we don't muck with 1.1 project capabilities.
aspnet/Razordotnet/aspnetcore-tooling#2751
\n\nCommit migrated from 8d733ecc04
- When we detect a design time build we force tooling to use 2.1
- In runtime builds (i.e. rzc) it still uses the 3.0 configuration for 3.0 apps.
(cherry picked from commit dotnet/aspnetcore-tooling@0326abe530)
\n\nCommit migrated from a6dc88e455
When a user builds a 2.1 or 2.2 project with a 3.0 they can get an error
due to invalid command line options from rzc. What happens is that the
3.0 tasks (which are a singleton) are talking to the 2.X build tool
(which is NOT a singleton).
Recently some changes were make to the 3.0 tasks which caused this bug
because it did not properly accomodate downlevel versions of rzc. We
have an integration test for this scenario for but the regression was
not detected, so obviously something is wrong with the test setup. I'll
investigate that separately.
(cherry picked from commit dotnet/aspnetcore-tooling@1aace2b6c7)
\n\nCommit migrated from d2654d0847
When a user builds a 2.1 or 2.2 project with a 3.0 they can get an error
due to invalid command line options from rzc. What happens is that the
3.0 tasks (which are a singleton) are talking to the 2.X build tool
(which is NOT a singleton).
Recently some changes were make to the 3.0 tasks which caused this bug
because it did not properly accomodate downlevel versions of rzc. We
have an integration test for this scenario for but the regression was
not detected, so obviously something is wrong with the test setup. I'll
investigate that separately.
Nate McMaster
Ajay Bhargav Baaskaran
Ajay Bhargav Baaskaran
Pranav K
N. Taylor Mullen
Ryan Nowak
Nate McMaster
Chris Ross
Justin Kotalik
Ryan Nowak
Ryan Brandenburg