* Remove all ref/ projects
* Remove GenAPI infrastructure
* Remove notion of a reference assembly project
- remove `$(IsReferenceAssemblyProject)`, `$(ReferenceReferenceAssemblies)` and `$(ReferenceImplementationAssemblies)`
- remove unnecessary `$(NoWarn)` settings
nits:
- remove a few misleading comments
- wrap some long lines
* Move .0 package version workaround into Versions.props
- touch up SharedFramework.External.props
* Expose `%(LatestPackageReference.RTMVersion)` metadata
- automate use of properties in the `@(LatestPackageReference)` item group to make this maintainable
- add a couple of special cases at the bottom of eng/Dependencies.props
- add one more `$(...PackageVersion)` property to avoid yet-another special case
* Enable Roslyn reference assemblies
- exclude ref/ assembly from packages other than targeting pack
- update Microsoft.AspNetCore.App.Ref.csproj
- `%(IsReferenceAssembly)` and `%(ReferenceGrouping)` metadata no longer relevant
- only ref/ assemblies are in `@(ReferencePathWithRefAssemblies)` item group
nits:
- remove now-unnecessary workaround
- issues with TFM transition are behind us
- clean up Microsoft.AspNetCore.App.Runtime.csproj slightly
- use `GeneratePathProperty="true"`
- reorder item / property settings for meta-expansion
- correct spelling errors and phrasing in comments
* Update documentation to reflect recent changes
- remove CrossRepoBreakingChanges.md; was tied to old TeamCity infrastructure
- also much less relevant given repo merges
- adjust details and examples in ReferenceResolution.md
- reflect repo merges, Dependencies.props changes, and current Maestro++ channels
- add a few more details e.g. specific files where Version.Details.xml versions are used
* !fixup! Remove another irrelevant doc file
* !fixup! Address PR review suggestions
- convert a couple of warnings to errors
- use consistent casing for Microsoft.NETCore.App.Runtime.* packages
- reduce `%(LatestPackageReference.Version)` metadata special cases
- add and improve comments e.g.
- improve comments about `$(*V0PackageVersion)` properties
- improve placement of comments about item removal in ResolveReferences.targets
- confirmed `$(*V0PackageVersion)` property list is complete
nits:
- fix solution example in ReferenceResolution.md
- remove item group definition for `@(LatestPackageReference)`
- remove `%(LatestPackageReference.VersionName)` metadata after use; large item group
- similarly, remove `%(LatestPackageReference.RTMVersion)` when not needed; just complicates `Condition`s
When I squash, I must remember this fixes
- #14801
- dotnet/aspnetcore-internal#2693
* Actually use `%(LatestPackageReference.RTMVersion)` metadata
- gather RTM package references in a new project
- a (very) separate project to work around package conflict resolution
- empty `Test` target works around Arcade's testing approach
- new target in ResolveReferences.targets updates relevant assembly paths to use the RTM packages
- done as soon as possible after `ResolvePackageAssets` determines the paths
- done for all compilation inputs, not just ref/ assemblies
* Default new runtime feature switches
These new feature switches have been added to the runtime to make applications smaller. Setting reasonable defaults to Blazor wasm projects.
Fix#23716
* PR feedback
* Default new runtime feature switches
These new feature switches have been added to the runtime to make applications smaller. Setting reasonable defaults to Blazor wasm projects.
Fix#23716
* PR feedback
* Add framework support for lazy-loading assemblies on route change
* Configure lazy-loaded assemblies in WebAssemblyLazyLoadDefinition
* Move tests to WebAssembly-only scenarios
* Refactor RouteTableFactory and add WebAssemblyDynamicResourceLoader
* Address feedback from peer review
* Rename 'dynamicAssembly' to 'lazyAssembly' and address peer review
* Add sample with loading state
* Update Router API and assembly loading tests
* Support and test cancellation and pre-rendering
* Apply suggestions from code review
Co-authored-by: Steve Sanderson <SteveSandersonMS@users.noreply.github.com>
* Spurce up API and add tests for pre-rendering scenario
* Use CT instead of CTS in NavigationContext
* Address feedback from peer review
* Remove extra test file and update Router
Co-authored-by: Steve Sanderson <SteveSandersonMS@users.noreply.github.com>
All rules are currently disabled, except for one that I enabled for
src/Http via a new ".editorconfig" file I added there.
Other changes:
* Allow editorconfigs in MVC and Razor to flow to the root
* Consolidate a few editorconfig settings
* Tweak Ruleset config in Azure/AzureAD where it clashed.
Addresses the beginning of #9620, but it's a fair chunk of work to
enable most rules through the whole repo. That can be done directory by
directory and rule by rule by dropping .editorconfig files though.
* The underlying Json issue is fixed.
* The X509 issue is not an issue when TrimMode is set to link (which is it now by default).
Contributes to #23262
* Add support for gzip compression during build and publish
3.2 shipped with gzip compression during build and publish. During the port to 5.0, the build and publish
pipeline was different and ended up only during brotli compression during publish. However, during build
the app size is now up to 20MB. Statically compressing runtime assets during build reduces the payload size
to about 8.5 MB. This should help with faster initial boot ups and perception.
* Quarantine test
* More quarantine
* Use linker extensibility to enable better trimming
* Configure TrimmerDefaults=link if unspecified
* Allow Microsoft.AspNetCore.* and Microsoft.Extensions.* packages to be trimmed.
* Make producing the trimmer root descriptor more incremental
* Ensure BlazorWebAssembly.js is present
* Unquaratine blazor template tests
* The failure issue https://github.com/dotnet/aspnetcore/issues/20479 was resolved, but the assembly level quarantine was
missed being removed.
* Use shorter project file names to avoid long path issues.
* Update blazorwasm template tests to react to net5 updates
* Update src/ProjectTemplates/Shared/ProjectFactoryFixture.cs
Specifying the RID and PublishDir when publishing the driver app causes all sorts of
build issues. This change moves specifying the RID in to the driver app and ensures PublishDir
does not flow to the referenced RazorSDK project.
* Fix docker build
* Update readme typos
The linker doesn't resolve assemblies correctly if the file extension (.dll) is included in the assembly name in the descriptor xml file.
See also https://github.com/mono/linker/issues/1294
* Fix up Blazor ILLink Descriptor files
1. Add the typegranularity file to TrimmerRootDescriptor.
2. Remove the application assembly descriptor file, since the application assembly is passed in as a RootAssembly already.
* Razor SDK fixups for blazor
* Only include dlls when generating type granular assemblies
* Write server-worker to the obj directory
Co-authored-by: Eric Erhardt <eric.erhardt@microsoft.com>
* Enable `/warnAsError` in Windows builds
- already enabled in non-Windows builds because override existed only in build.ps1
* Allow some warnings related to closed issues
- common `<NoWarn>$(NoWarn);CS1591</NoWarn>` case unchanged
- /Directory.Build.props ensures that warning remains a warning but doesn't hide it
* !fixup! Root build.sh _does_ disable warnings as errors
- variable eng/common/tools.sh uses named `warn_as_error`
* nit: Remove useless `$(HasReferenceAssembly)` settings
- set in /Directory.Build.targets
- `true` only in `$(IsAspNetCoreApp)` projects
* nit: Remove useless `$(CompileUsingReferenceAssemblies)` settings
- no current versioning differences between ref/ and src/ assemblies when targeting default TFM
* Add more `$(GenerateDocumentationFile)` settings
- increases the number of generated doc files, mostly without problems
- !fixup! correct typo in `DebugProxyHost` doc comments
- was not generating a doc file before
- remove previous (ineffective) src/Components/Directory.Build.targets setting
- nit: remove a duplicate `$(GenerateDocumentationFile)` setting
* nit: Remove useless `$(IsPackable)` settings
- only analyzers and implementation projects are packable by default
- main use case for explicit setting is projects shipping only in shared framework
- conditional setting in src/Mvc/Directory.Build.props just subset logic in /Directory.Build.targets
* nit: Remove useless `$(IsProjectReferenceProvider)` settings
- only implementation projects are providers by default
* nit: Remove useless `$(IsTestAssetProject)` settings
- set in src/Mvc/test/WebSites/Directory.Build.props
* !fixup! Looks like `InProcessNewShimWebSite` must compile w/o ref/ assemblies
- restore `$(CompileUsingReferenceAssemblies)` in this one project
- Enabled Helix for:
- `Microsoft.AspNetCore.Mvc.Razor.Extensions.Test`
- `Microsoft.AspNetCore.Mvc.Razor.Extensions.Version1_X.Test`
- `Microsoft.AspNetCore.Mvc.Razor.Extensions.Version2_X.Test`
- These tests depended on our MVC shim project's deps.json's to exist in the test bin directory during publish. Therefore added an additional target copy over those assets at publish time.
- There were some tests that were relying on source positions from a string to match a runtime generated source position. In Helix dll's are built on Windows (string's get compiled with \r\n) and then deployed to potentially non-Windows boxes resulting in mismatches of expectations. To address this I changed the test that had this dependency to dynamically generate the input string.
- Our common language test project used to rely on test files being on disk. At some point in the past those test files started being embedded in the assembly but we maintained directory checking logic to ensure various directories existed on disk (no longe required). Changed the logic to not enforce directories to be on disk (they aren't in Helix) and instead only rely on the embedded TestFiles.
dotnet/aspnetcore#22100
This additionally gets rid of an extra whole buffer allocation in the ParserContext. The most complex bit of the change is around avoiding TextLineCollection.GetLocation.
Overall, I'm seeing a pretty big win here, about 35% less time spent in RazorSyntaxTree.Parse for the typing scenario I was doing in a very large file.
This method allocated multiple strings on every invocation when they were rarely needed. With this change, I see a reduction in memory allocated during RazorProjectEngine.ProcessDesignTime of 1.4%.
This is the last of the easy wins that I could find for typing in large razor files (minus the logged bug to move the divergence checker code off the UI thread). In the profile for the large document editing, these changes reduce allocated memory during RazorSyntaxTree.Parse by about 25%. CPU wise, the win isn't quite as dramatic, only a couple percent improvement under RazorSyntaxTree.Parse.
* Razor SDK build ordering issues
* Build the SDK completely regardless of the MSBuild runtime type
* Split SDK integration tests into a separate project. Clean up project file
* Add project to sln
* Update Microsoft.NET.Sdk.Razor.csproj
* Fixup tests
* Avoid rebuilding dependencies if they appear up to date. Fixup tests
* Fixup
* Update CSharp.Common.props
* Cleanup the build
* Add mechanism where IR token generation can defer allocation of it's content.
It turns out that many IR tokens access their content, and thus allocating it is unnecessary. In particular, with this change against a large file, I've seen allocations under SyntaxNodeExtensions.GetContent reduced by about 33%. Performance wise, I've seen the number of CPU samples in the profile under GetContent reduce by about 40% (in my sample I typed 26 characters and there was about 600 ms less spent in GetContent)
* ContentGetter => ContentFactory
* Make tests happy with the switch from IntermediateToken to IntermediateTokenWithDeferreedContentAllocation
* IntermediateTokenWithDeferredContentAllocation => LazyIntermediateToken
* Previous optimization didn't help as much as intended.
By specifying a method group as the arguments to method like ReadWhile, an allocation was still occurring. Instead, cache the Func as a member in the class and use it instead of the method group.\n\nCommit migrated from 2e6aa150bc
* Improve CSharpLanguageCharacteristics.MapKeyword performance
The razor typing perf test profile I'm looking at has 156 ms of CPU cycles spent in this method, mostly in Enum.ToString()
\n\nCommit migrated from e821a4642e
In the razor perf typing test, Accept was showing 27 ms allocating enumerators. Additionally, modified ReadWhile to only allocate if it would return a non-empty collection (and to not use the complexity introduced by using yield enumerators)\n\nCommit migrated from 27a14af36a
The razor perf test shows about 70 ms CPU of WithSpanContext is in allocation. GetAnnotation similarly is showing about 60 ms in allocation (of which this only partly improves)\n\nCommit migrated from a060f129ff
Our razor typing test measured 153 CPU ms in this method. Optimized by fewer calls to CurrentCharacter, not checking '<' twice, and uswing a switch stmt.\n\nCommit migrated from c601c2f11e
* Several changes targeted to improving perf of RazorSyntaxTree.Parse
1) Modify ParserHelpers.IsNewLine to use a switch instead of Array.IndexOf
2) Modify Tokenizer.CreateToken to take in an array of RazorDiagnostics rather than an IReadOnlyList as that was causing a ToArray call on an empty diagnostics very often (during a SyntaxFactory.Token call)
3) Modify TokenizerBackedParser.Putback to allow an IReadOnlyList as a parameter to not require creation of a reverse enumerator.
4) Cut down allocations in HtmlMarkupParser.GetParserState by:
a) Using an IReadOnlyList instead of IEnumerable to get rid of the allocations from the .any calls
b) Don't allocate while reading initial spacing
c) Inline the IsSpacingToken code so cut down on code executed and need to allocate a separate Func
5) Modify CSharpCodeParser.IsSpacingToken to now be a set of methods instead of a single method that allocates a Func. This is a very high traffic method.
6) Implement a fairly rudimentary Whitespace token cache, as they can be reused. This was based off Roslyn's SyntaxNodeCache, but simplified significantly. It's probably worth investigating whether you should more fully embrance token caching outside of whitespace.
* PR feedback and added one more optimization in LocateOwner that's been bugging me for years. Assuming all chidlren are contained within a nodes span, we can short-circuit the DFS this code was doing significantly cutting time in this method which is important as it's exercised on the main thread during typing.
* missed a space
* StringTextToSnapshot's switch to IsNewLine needed to use start as the index to begin the search, not zero.\n\nCommit migrated from 45411f7526
I noticed several hundred ms spent in this method from a customer profile. Primarilly, the method was doing a linear scan of all lines trying to find one that contained the requested position. I changed this to a binary search, but kept/improved the optimization around checking next/previous lines before instigating the search.
Note, there was also a bug where the old code did:
else if (absoluteIndex > _currentLine.Index && _currentLine.Index + 1 < _lines.Count)
but it should have been coparing absoluteIndex with _currentLine.Start
\n\nCommit migrated from 32a0f28708
* Improves the reliability of the affected tests with retries
* Pack and restore fail/hang in some occasions. The retries minimize
the chances of these happening.
* For pack, we retry a few times but we ultimately continue as we've
seen the package gets generated when pack hangs and looks correct.
If that were not to be the case in the future, the test will fail.\n\nCommit migrated from 0d03b57617
- 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
Pranav K
Doug Bunting
Stephen Halter
Eric Erhardt
Brennan
Steve Sanderson
Safia Abdalla
Kevin Pilch
msftbot[bot]
Tanay Parikh
Ajay Bhargav B
N. Taylor Mullen
Chris Ross
Todd Grunke
Javier Calvarro Nelson
John Luo
dotnet-maestro[bot]
Jan Joneš
Kevin Pilch
Ryan Brandenburg