* Use RandomNumberGenerator.Fill()
Use the new RandomNumberGenerator.Fill() method instead of maintaining instances of RandomNumberGenerator to use GetBytes().
* Revert RandomNumberGenerator.Fill()
Revert usage of RandomNumberGenerator.Fill() as the project still targets netstandard2.0.
- match changes that are in 'release/3.1' but not 'release/3.0'
- e.g. `StaticComponentRenderer`'s namespace change and newly-added members
- redo GenAPI exclusions
- remove some unecessary workarounds getting in the way of keeping up w/ API changes
- add more GenAPI exclusions, enabling `--all` without hitting dotnet/arcade#4488
* Change csv content type to text/csv
According to RFC4180: https://tools.ietf.org/html/rfc4180 MIME type for .csv file should be "text/csv"
* Add comment
This changes the z-index of the Blazor reconnect modal to be aligned
with the z-index used by Bootstrap for modals overlays. If users rely on
Bootstrap for overlays within application this would prevent obstruction
of the Blazor's reconnect information with other overlays in the
application.
Addresses #12867
* updating inline "code" tag to "c" tag
* Apply suggestions from code review
Co-Authored-By: Andrew Stanton-Nurse <andrew@stanton-nurse.com>
* reverting tag
* reverting tag
* reverting entire file
* 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
Fixes: #14789
Users can hit this error case when using a route parameter that has a
special meaning in MVC, in attribute routing with a route constraint.
This will cause us to fail while expanding the route pattern, because
the canonical value associated with the parameter won't satisfy the
constraint.
TLDR: don't do that. Using MVC's reserved parameter names for
application-level concerns will always cause bugs.
This was a case where you'd fail with a totally unactionable error
message. Updating it to reflect the proper root cause and our guidance
to fix it.
* Update dependencies from https://github.com/aspnet/Blazor build 20191121.2
- Microsoft.AspNetCore.Blazor.Mono - 3.1.0-preview4.19571.2
* Update dependencies from https://github.com/aspnet/Blazor build 20191126.1
- Microsoft.AspNetCore.Blazor.Mono - 3.1.0-preview4.19576.1
* Update dependencies from https://github.com/aspnet/Blazor build 20191126.2
- Microsoft.AspNetCore.Blazor.Mono - 3.1.0-preview4.19576.2
* Add missing extensions feed
Seems like the feed with stable versions has been deleted in the updated. I've re-added it and that should fix the existing restore issues.
* Pass an empty array to entry point
Fixes https://github.com/aspnet/AspNetCore/issues/17419
* Use System.Reflection.Metadata to generate BootConfig
* Remove reference to Mono.Cecil
* Remove support for auto embedded css \ js
* Remove blazor.webassembly.js
- #13864
- use latest Arcade from '.NET 3 Tools'
- pick up @joeloff's #4083 signing validation fixes
- update signing validation exclusions to get them working
- remove custom embedded package icon bits and use Arcade approach
- also switch VS.Redist.* packages to use license expressions
* Make constraint cache thread safe
Fixes: #17101
This changes the constraint cache to use ConcurrentDictionary. This code
is invoked in a multithreaded way in Blazor server resulting in internal
failures in dictionary.
Since this is a threading issue there's no good way to unit test it, but
I noticed we're missing tests in general for this class, so I added a
few for the caching behavior.
* PR feedback
Fixes: #16922
This change updates our analyzers that need access to the symbols to use
`IOperation` where possible. Using syntax analysis for this kind of
analyzer has worse performance. These analyzers run on generated code,
which can include EF migrations, the design of which amplifies these
effects.
On the path to this, I also added support for a few more cases that
operations make easy. Since we're doing this anyway, I want to have
confidence that we're checking everything (within reason). In some cases
the diagnostic experience changed a bit (including more of the
declaration/code) - I felt like all of these were OK changes. Given the
kinds of error message reported by the analyzers "don't use that type"
it seems like it's still a good enough experience without
micro-optimizing all of the locations.
* Now works on ns2.1, but links too much
* Now only link System.* assemblies
* Clean up. Also link Microsoft.Extensions.* now too, since it works.
* x-plat slash consistency
* Change all Blazor.* projects to netstandard2.1
* Further TFM updates
* Stop linking Microsoft.Extensions for now, since it requires a more detailed treatment to avoid breaking things
This commit allows ASP.NET Core to be built on arm64 machines directly,
without relying on cross-compilation.
There's a few changes in here:
1. Ask msbuild to look into the BuildArchitecture
By default, our build systems assums the machine is x64. This
modifies the build configuration to check the architecture of the
currently running build machine, and set BuildArchitecture to that.
2. Fix crossgen in Microsoft.AspNetCore.App.Runtime
We run crossgen for supported architectures (including x64 and
arm64). For that, we need a jit that we can point crossgen to.
Generally, we can rely on the build scripts to find the right
`libclrjit.so`. However, arm64 has multiple `libclirjit.so`, for
different use-cases. There's one for arm64 (for running on arm64) and
there's another one for cross-compiling for arm64 on x64. We need to
figure out and use the right one explicitly rather than assuming the
right one gets picked up.
See https://github.com/dotnet/core-setup/pull/8468 for similar
changes made in core-setup.
This also needs https://github.com/aspnet/AspNetCore/pull/14790 to fully
work on arm64.