- Moved from 3.4.0 Roslyn to 3.6.0-3.20168.4 for tooling builds.
- As part of this change I found that our package versions were starting to get really confusing for which Roslyn packages were runtime vs. which ones were tooling. Therefore, I rebranded each of the versions to be `Tooling_` or `Runtime_` accordingly. Moved all `VSIX_` => `Tooling_`.
- Roslyn's bits depended on a newer `StreamJsonRpc`, `Microsoft.VisualStudio.Threading` and `Microsoft.VisualStudio.LanguageServer.Client` packages so updated those dependencies to not have version conflicts.
- This new update brought in loads of new analyzers. Went through the warnings and either applied the fix or suppressed.
- This is in preparation for consuming new pieces from latest Roslyn packages.
\n\nCommit migrated from df5261e418
- Prior to this we would start tracking LSP documents when an `ITextView` was associated with our `ITextBuffer`. The issue with this is when the `ILanguageClient` infrastructure initializes itself before we do and starts our `LanguageServer` it's we start retrieving requests that require access to our `LSPDocumentManager`. That's an issue because our `LSPDocumentManager` may not have been initialized yet resulting in failure to fulfill requests.
- Changed how we initialize `ITextBuffer`s. Before we were setting up all of the logic to change the content type of a text buffer and populate its properties at the `EditorFactory` layer; however, how we were doing it (waiting for the ITextBuffer to load) resulted in `ITextDocumentListener` events firing prior to our content type changes would occur. This is a problem becasue the `ILanguageaClient` infrastructure will start making its decision to turn on LSP features for your `ITextBuffer` at the point and time. Now we change the `ITextBuffer`s content type (and set properties) during the `ITextDocumentListener` created pipeline.
This resulted in almost all of our logic in our editor factory to be split out into two classes.
1. `LSPEditorFeatureDetector`, we needed to be able to detect the "enabledness" of features in two locations. Once at the `EditorFactory` layer to ensure we know when to disallow other editor factories participation in the `ITextBuffer` creation and a second at the `ITextDocumentListener` layer when we inspect an `ITextDocument` and need to determine if we want to "initialize" it (change its content type etc.).
2. `RazorLSPTextDocumentCreatedListener`, this is our `ITextDocumentListener` i've been referring to. It now houses the logic on how to change the content type and populate the `ITextBuffer`'s properties.
- Changed our `LSPDocumentManager` to no longer depend on `ITextView`s for ref counting documents. Instead we just take an `ITextBuffer` and keep an internal count of how many times we've been asked to track a document. In practice this number never goes past 1 however it doesn't hurt to be defensive.
- Added IVT from CodeAnalysis.Razor to our LanguageServerClient project in order to enable the retrieval of our `FilePathComparison` type.
- Given the new refactoring of our feature detector and the `ITextDocumentListener` pieces I was able to add extensive testing to ensure all things work as expected.
Fixes dotnet/aspnetcoredotnet/aspnetcore-tooling#19160
\n\nCommit migrated from d0a7dfce09
- This is a pre-requisite work item to run our language server in-process in Visual Studio. VS is a .NET framework application so we can't have a language server which targets netcoreapp be loaded. Therefore, in order to account for this I needed to re-target our language server library to netstandard2.0 so it can be referenced via a netcoreapp (rzls.exe) and a .NET framework app.
- Added a new `rzls` project to be the maintainer of our OOP language server
- Had to make adjustments to the existing language server project to be compatible with netstandard2.0.
- Created a new `RazorLanguageServer` type to initiate our Language Server but not start and initialize it. To enable a consumer to initialize the new language server I had to use private reflection to `Initialize` O#'s internal type. This is a temporary measure which I intend to expand the O# lib to make their Initialize method public.
dotnet/aspnetcoredotnet/aspnetcore-tooling#19185
\n\nCommit migrated from 79841b9371
- Multi-target ObjectPool
- Move Embedded.Manifest.Task.Internal.Entry to the public namespace
- Remove ref assemblies from AspNetCore.Testing
- Skip TestPathUtilitiesTest since it's a pattern we want to migrate away from
- Fix FileProviders.Abstractions version in Embedded.*.nuspec
- Add workarounds for project references to FileProviders.Embedded
LSP Razor formatting for Razor code block directives
- Support for @code/@functions block formatting
- Except when it contains Markup or other Razor constructs
- Added a RazorFormattingService which is invoked by the RazorFormattingEndpoint.
- Added a custom razor/rangeFormatting command that the server can use to ask the client to format a range of the projected C# or HTML document
- Added a CSharpFormatter and HTMLFormatter that invoke the above mentioned command
- Added FormattingSpan and its corresponding visitor to represent Razor understanding of indentation
- Moved the document mapping code to a separate RazorDocumentMappingService service for ease of use
- Added necessary extension methods for convenience. Some of them were copied from Roslyn
- Some cleanup
- Added a C# test formatter to enable unit testing. Right now it calls Roslyn APIs directly. As far as I've seen its behavior is the same as OmniSharp formatting except it doesn't remove trailing whitespace and empty lines. I am following up with people to understand why that is the case.
Added/updated tests
\n\nCommit migrated from 62051b9ad7
* Mark AspNetCore projects that aren't packaged explicitly
- avoid NU5104 warnings due to confusing versioning
- `$(IsShippingPackage)` was semantically incorrect in any case
* Remove redundant `$(IsShippingPackage)` settings in `$(IsAspNetCoreApp)` projects
- default is `true` for all implementation projects
* Use `$(IsPackable)` when deciding how `$(IsAspNetCoreApp)` projects are handled
- remove all use of `$(IsShippingPackage)` for shared framework composition
- update documentation to match these changes
nits:
- remove odd default for `$(IsPackable)` in Directory.Build.targets
- no longer relevant since all `$(IsAspNetCoreApp)` projects are `$(IsShippingPackage)` too
- include more information in docs/ProjectProperties.md
* Add direct System.Text.Json references
- avoid MSB3277 warnings
- This test has around a pretty high failure rate. Always find myself having to retry builds to work around this. Skipping for now until flakyness can be resolved.
dotnet/aspnetcoredotnet/aspnetcore-tooling#18561
\n\nCommit migrated from 09514f5b4d
This test has around a 50% pass rate. Always find myself having to retry builds to work around this. Skipping for now until flakyness can be resolved.
dotnet/AspNetCoredotnet/aspnetcore-tooling#18543\n\nCommit migrated from 4187049b4f
* Rely on regular restores for RID-specific package restores
* Pin the runtime to a previously shippped version in SDK tests
* Update src/Razor/test/testapps/Directory.Build.targets
\n\nCommit migrated from b0a60a0231
[StaticWebAssets] Updates manifest generation to allow multiple content roots under the same base path for a single project\n\nCommit migrated from 5e957b4c3b
* Remove useless src/PackageArchive files
- not used outside 2.x branches
* Improve use of ref/ assemblies
- compile against ref/ assemblies but do not change package metadata
- update the metadata of implementation projects to include the ref/ assembly path
- update `@(ReferenceAssembly)` metadata for Extensions packages, not `@(PackageReference)`
- can be disabled using `$(CompileUsingReferenceAssemblies)` e.g. when generating ref/ projects
- include ref/ projects in source build by default
- remove `$(ExcludeFromSourceBuild)` overrides from ref/ project files
- use latest package references and use project references even when _not_ building the targeting packs
- restore previous `@(Reference)` -> `@(PackageReference)` logic
- add build-only Microsoft.Internal.Extensions.Refs package reference in most cases
- remove IndirectReferences.props and `@(_ExtensionInternalRefAssemblies)`; no longer needed
* Improve ref/ project generation
- use ../src/**/AssemblyInfo.cs files instead of including attributes in *.Manual.cs files
- for same reason, copy `@(InternalsVisibleto)` items from src/ to ref/ projects
- use eng/targets/CSharp.ReferenceAssembly.props instead of ref/Directory.Build.props files
- use TFM-specific *.Manual.cs files in ref/ project files instead of ref/Directory.Build.props files
optimizations and usability improvements:
- add `$(BuildMainlyReferenceProviders)` property to focus on reference providers when generating ref/ projects
- disable `$(UseReferenceAssemblyInImplementation)` to avoid using ref/ projects while generating them
nits:
- clean up whitespace and remove blank lines in ref/ project files
* Perform smaller cleanup
- remove `$(IsTargetingPackPatching)`; use only `$(IsTargetingPackBuilding)`
- remove `$(DisableServicingFeatures)`; enable the servicing features we need
- suppress baseline references even in servicing builds
- restore `$(AdditionalGenApiCmdOptions)`; useful when updating *.Manual.cs files
nits:
- simplify conditions using `$(HasReferenceAssembly)`
- correct spelling in comments
- shorten long lines
* Use a response file for GenAPI commands
- work around dotnet/arcade#4021 and help with additional ref assemblies
- mimic 111462e0c2 and integrate w/ other changes here
* Undo some manual ref/ project changes
- now done automatically or centrally
- remove manual `[TypeForwardedTo]` and `[InternalsVisibleTo]` attributes
- fully qualify a type now that `using` is gone
- remove dupe `@(Compile)` items for *.Manual.cs files; included in the ref/ project files
- remove redundant `$(AllowUnsafeBlocks)` and `$(NoWarn)` settings
nits:
- rename a *.Manual.cs file that's not TFM-specific
- remove `private` members
* Correct use of `@(ProjectReference)` items for reference providers
- use `@(Reference)` instead
* Remove recently-added `@(Compile)` and `@(Reference)` items
- were added due to missing `[InternalsVisibleTo]` attributes in ref/ assemblies or as early workarounds
- plus, now transitive references **Just Work™️**
- expose `ClosedGenericMatcher` in the usual (*.Manual.cs) way
- also undo Microsoft.Extensions.ApiDescription.Server workaround
* Remove `private` members from ref/ *.Manual.cs files
- not useful and bloat the ref/ assemblies
* Cleanup warnings
- avoid "CSC warning CS2008: No source files specified." building site extensions
- correct warnings (as errors) about `RenderToStringResult` being obsolete
- add Microsoft.AspNetCore.SpaServices.Tests to Middleware solution
* Remove `@(RuntimeHostConfigurationOption)` workarounds
- deps files are unaffected by new ref/ assembly handling and test projects aren't special-cased
- also execute a test previously skipped due to deps file problems
* Regenerate ref/ projects
- pick up the latest generation changes
(unclear why Mvc.RazorPages/ref/Microsoft.AspNetCore.Mvc.RazorPages.netcoreapp3.0.cs changed but works)
* Fill in missing `internal` types 1 of n
- rename Microsoft.AspNetCore.Components.netstandard2.0.Manual.cs; need `RenderTreeFrame` type everywhere
- add types needed in unit and perf tests to *.Manual.cs files
* Clean up recent commits
- remove recently-added `private` members
- restore `_dummyPrimitive` fields in Microsoft.AspNetCore.Server.HttpSys.Manual.cs
* Add *.Manual.cs files for more projects
* !fixup! fields in *.Manual.cs `struct`s
- GenAPI sometimes generates `_dummy` and `_dummyPrimitive` fields _instead of_ visible members
- what GenAPI generates sometimes have the right length but actual fields don't hurt
- that is, using the real fields corrects both the visible API and `struct`s' sizes
nits:
- consolidate `namespace`s in Microsoft.AspNetCore.Mvc.Core.Manual.cs
* Remove special case for generating ref/ projects on non-Windows
- referenced issue was closed with no action but workaround still not required
- no tabs in generated content
* Only create ref/ projects for assemblies in the shared framework
- restrict when `$(HasReferenceAssembly)` is `true` by default
- add warnings when `$(IsAspNetCoreApp)` or `$(HasReferenceAssembly)` have unexpected values
* Remove "extra" ref/ projects
- associated implementation projects no longer have `$(HasReferenceAssembly)` set to `true`
* Add a few GenAPI exclusions
- see dotnet/arcade#4488
- generation for these members leads to NREs
* Add more `internal` types and members
- Identity/Core
- Identity/Extensions.Core
- Mvc/Mvc.ViewFeatures
* Add direct dependencies to work around CS1705 errors
- add direct references to some test and sample projects to make intent clear i.e. address CS1705 root cause
- these projects must use implementation assemblies for those direct references
- requirement also applies to anything depending on them e.g. functional tests
- for simplicity, use `$(CompileUsingReferenceAssemblies)` instead of targeted `@(Reference)` metadata
- leads to ~40 projects that do not themselves add ref/ metadata
- this is _not_ transitive i.e. it applies only to projects that override `$(CompileUsingReferenceAssemblies)`
* nits: Remove a few more `private` members in *.Manual.cs files
* !fixup! correct namespaces of a few types in *.Manual.cs files
* Try another way to fix Microsoft.AspNetCore.Blazor.Build.Tests
* Try another way to fix missing targets in Web.JS.npmproj
* Update dependencies from https://github.com/dotnet/arcade build 20190924.3
* Update dependencies from https://github.com/aspnet/Blazor build 20191003.2
* Update dependencies from https://github.com/aspnet/AspNetCore-Tooling build 20191007.2
* Update dependencies from https://github.com/aspnet/EntityFrameworkCore build 20191010.4
* Remove potentially unnecessary feeds
* Install the runtime during source build
* Pin m.nc.app.ref
* Add aspnetcore-dev feed back to nuget.config
* Pin internal refs package
* Move efcore internal refs dependency
* Compile against ref assemblies
* Add manually generated internal ref assembly:
* DataProtection
* Kestrel
* Hosting
* Http
* Mvc
* Middleware
* SignalR
* Identity
* Components
* Fix crossgen for ref compilation
* Fix tools for ref compilation
* Explicitly specify ExcludeFromSourceBuild
* Build targeting pack for 3.0.1
* Improve condition for building targeting pack in 3.0.1
* Fixing siteex build for ref compilation
* Resolve reference assemblies from Extensions
* Don't build refPack during source build
* Add big list of project references, for tests to use
* Exclude sources files from indirect references
* The types in these packages will be compiled into the binaries of the projects that directly depended o it
* Add manual indirect references to project references
* Add samples/test assets
* Don't add indirect refs for ProjectRefs with ReferenceOutputAssembly=false
* Fix JSInterop for ref compilation
* Do not substitute ext ref assemblies in ref pack
* Disable the TestFramework assembly attribute from Logging.Testing
There's custom logic in ProjectTemplates.Tests to use a different TestFramework instead
* Fix Functional tests
* Issues caused by incorrect deps files working around this via test infrastructure instead
* Mvc
* Analyzers
* StaticFiles
* SignalR
* HttpOverrides
- The Blazor runtime doesn't support adding attributes prior to any sort of content frames being applied. This change ensures that `ComponentAttributes` (how preventDefault / stopPropagation are represented) are handled like other HTML attributes (applied first).
- Updated existing tests and their baselines.
aspnet/AspNetCoredotnet/aspnetcore-tooling#16611
\n\nCommit migrated from 1513cd2a5b
- We now do aggressive detection on the type of C# class that's being edited. In order to not impact C# scenarios we only do work if C# assets are available to us. Meaning, we inspect the old document and if that document has its' semantic model available we spend cycles to determine if it's a component. In the case that we find a C# component class that wasn't previously caught we enqueue an update.
- Added several tests to ensure we enqueue and that we properly detect component classes.
aspnet/AspNetCoredotnet/aspnetcore-tooling#14646
\n\nCommit migrated from d8b62e121f
- The 3.0 SDK adds RazorDeclaration files to the compile list if they exist. If a user builds in VS and then does a project level operation (adding a property group or item group to their project file) a design time build will trigger for unrelated reasons and declaration files will be included as part of the C# compilation resulting in duplicate member errors. This change ensures that even if declaration files are added we then remove them to ensure we avoid those declaration additions.
- One unfortunate aspect of this change is that declarations are added to the compile list for a brief moment resulting in errors and then are instantly removed in some situations. I say "some situations" because when this happens it is highly dependent on how / when the project system decides to perform a design time build.
aspnet/AspNetCoredotnet/aspnetcore-tooling#14646
\n\nCommit migrated from b64c9317c4
Fixes aspnet/AspNetCoredotnet/aspnetcore-tooling#13181
The big change here is that we have to allow an HtmlAttributeIRNode to have
a dynamically computed attribute name. This isn't something that exists
anywhere else in the system.
\n\nCommit migrated from 559f0f5e52
This change updates tag helper binding logic to allow directive
attributes (when they appear alone) to bind to any kind of tag
(start/end, void, self-closing).
Tag Helpers don't have a semantic that allows this level of flexibility
- using StartTagOnly as suggested in the issue means that this would
*only* work for void elements.
There's no change to any of the directive attribute implementations
because this is a global change in the tag helper infra.
\n\nCommit migrated from fd72afc1c6
- No longer mark declaration files as single file generators. Prior to this we relied on SingleFileGenerators to dynamically update the declaration files when .razor files changed. However, to make partial classes work we can no longer depend on declaration files being available because their existence causes us to have to mangle class names for opened documents; otherwise you get two files with same name and result in ambiguous definition errors.
- Stopped including declaration files as part of the users compilation. This was intended to make the design time experience operate more similar to how Blazor apps function at runtime (directly access each component instead of their declarations). We now rely on the background code generation effort built from the find all references work to supply users with strongly typed component names.
- Stop mangling class names for Visual Studio. Razor.VSCode has its own set of configurations which i'm not addressing as part of this changeset.
- Start generating components with the partial modifier to their class name to enable partial class support.
- Updated existing tests to expect partial modifier.
aspnet/AspNetCoredotnet/aspnetcore-tooling#5487\n\nCommit migrated from 73858cdd37
- Added the `.vscode-test` to `.gitignore` because that's the VSCode folder that gets created when dynamically downloading VSCode for CI purposes.
- Migrated functional tests to use the non-deprecated VSCode functional testing APIs. This involved creating a runTest file to control downloading VSCode and passing in appropriate parameters as well as creating an index that discovers tests that should be run.
- Changed functional tests to operate on the existing Razor testapps (instead of the old ones).
- Updated the "default" completion tests to be latest Razor/Blazor.
- Added VSCode launch configurations to enable easy debugging via F5.
aspnet/AspNetCoredotnet/aspnetcore-tooling#13494
\n\nCommit migrated from 66e4e8a169
- Added tests for both the language server and the common language server projects.
- Updated publish MSBuild bits to publish to `artifacts/LanguageServer/$(Configuration)/TFM`
- Updated the language server to be netcoreapp3.0
aspnet/AspNetCoredotnet/aspnetcore-tooling#13494
\n\nCommit migrated from 984c638b37
N. Taylor Mullen
Jan Joneš
Kevin Pilch
Ryan Brandenburg
Tanay Parikh
Ajay Bhargav B
John Luo
Brennan Conroy
Stephen Halter
Doug Bunting
Ajay Bhargav Baaskaran
Kevin Pilch
Pranav K
dotnet-maestro[bot]
Justin Kotalik
Justin Kotalik
Artak
Javier Calvarro Nelson
William Godbe
Ryan Nowak
dotnet-maestro-bot