* Add legacy 3.1 fork of the whitespace tests, with baselines based on 5.0 behavior
* Remove non-applicable Legacy_3_1_WhiteSpace_WithPreserveWhitespace test
* Set the legacy tests to run with RazorLanguageVersion.Version_3_0
* Add legacy fork of the whitespace pass
* Consolidate both versions of whitespace pass and show it doesn't affect the baselines
* Revert BOM change
* Fix test
The RazorTagHelper task in the SDK is invoked by targets outside the SDK.
Consequently, any new requirements on the tasks need to be compatible with these versions.
In 5.0, we changed the task to expect the path to be passed in by the ToolExe property. This changes allows
using dotnet.exe from the ambient PATH to be used instead (the previous behavior)
For 5.0, we made a change to exclude .Views.dll from the single file bundle as a reaction
to changes in bundling. However the SDK change also applied to .NET 3.1 apps. This change
limits the exclusion to 5.0 and newer apps.
Fixes https://github.com/dotnet/aspnetcore/issues/27831
* Move all PublicAPI.Unshipped.txt files to PublicAPI.Shipped.txt
- we have now shipped this API surface
* Add eng/PublicAPI.empty.txt file
- make it easier to add new implementation projects
* Add missing public API baseline files
- #26784 part 1/2
- a few unexpected files turned up missing beyond the #26784 list…
* Reference Microsoft.CodeAnalysis.PublicApiAnalyzers more often
- #27484 part 2/2
- emit errors when API baseline files are missing
- update categorization of some projects
- specification tests are not implementation projects
- but _were_ project reference providers (keep that)
- correct `$(IsTestAssetProject)` setting for Razor shims et cetera
- correct `$(IsSampleProject)` setting for casing of some Sample directories
- Microsoft.AspNetCore.Analyzer.Testing should be treated as test asset
- add `$(AddPublicApiAnalyzers)` property to support overrides
- e.g. for `msbuild` task projects and tools
nit:
- remove useless `$(IsTestProject)` setting in a specification test project
- wrap some long `Condition`s
* Do not run public API analyzer in `RazorCoreCompile` target
* Remove old `$(EnableApiCheck)` settings
- property does nothing
- also remove a dangling ApiCheck comment
* Move to 5.0.1 versions
* Move to GA .NET SDK
- required for some tests to pass
* Remove feeds that won't be needed after 5.0.0 is GA
* Cherry-pick `$(CrossgenOutput)` and Directory.Build.*.in changes from master
- [master] Update dependencies from dotnet/runtime dotnet/efcore (#26788)
- 219ecd688012
- when project template tests run test assets, need latest shared Fx bits
- hit `BadImageFormatException`s otherwise
- test projects build against uploaded packages
- those packages reference the 5.0.1 shared framework
- the ASP.NET parts of the 5.0.1 shared Fx are `crossgen`ed to target Windows
- Use runtime and ref/ assemblies matching repo in Helix testing
- add Directory.Build.*.in files based on project template test infrastructure
- use files as import boundary where the project doesn't create its own Directory.Build.* files
- ensure `dotnet-watch` tests also use the latest runtime and ref/ assemblies
- Extend Helix Directory.Build.* workarounds
- generate Directory.Build.* files when restoring any projects
- include generated files in Helix runs needing the latest runtime
- copy generated files when testing `dotnet-watch` locally
- include generated content in Microsoft.NET.Sdk.BlazorWebAssembly.IntegrationTests test assets
- remove duplicate settings from existing Directory.Build.* files
- ensure shared framework and targeting packs are laid out under .dotnet/ before test assets restore
- Disable `crossgen` when building for Helix runs
- make `$(CrossgenOutput)` property override-able
- use override in CI jobs that submit to other platforms
- for now, leave the ARM64 Helix jobs alone (build on Ubuntu, run in Debian)
* Correct an `$(IsTestAssetProject)` setting
- affected projects are all test assets or provide test support
- without this, a number of the projects are incorrectly marked as shipping
* Baseline released 5.0.0 packages
- this is a complete rewrite of eng/Baseline.xml
- based on the 5.0.0 MergedManifest.xml file
* Add 5.0.0 PackageOverrides.txt and PlatformManifest.txt files
- need consistent versions when servicing targeting packs
Co-authored-by: dotnet-maestro[bot] <42748379+dotnet-maestro[bot]@users.noreply.github.com>
Description
We had support for the UpToDateCheck in Visual Studio with CSS isolation but the target was not being run at design time. This change introduces a new target that runs at design time and makes sure the UpToDateCheckInput and UpToDateCheckBuilt ItemGroups are populated.
Customer Impact
When using CSS isolation from within Visual Studio, a change in a scoped CSS file is not picked up and the project is not rebuilt as a result.
Regression?
No. This feature was introduced in 5.0.
Risk
Low. The new target we added only runs as part of Visual Studio builds.
Fixes
#26843
This change includes several improvements to CSS isolation that we have gathered from validation and usage feedback.
We have switched from producing a single scoped CSS bundle file for the entire application with all the scoped css files from the current project, referenced projects and package projects to producing one bundle per referenced project/package and to include those bundles into an "application" bundle throught CSS @import statements.
We have cleaned up the bundle names to make them more unique by including the project name on them and we have also cleaned up the bundle extensions.
We have decided to put the individual bundles generated for the project scoped css assets into the static web assets base path of the project, so that when developers reference assets from their scoped css files (like using the CSS url function) the path they use matches what they have inside their library wwwroot folder.
We have decided to put the application bundle on the root path of the application provided that the developer has not overriden the default StaticWebAssetsBasePath.
This is so that the bundle location is consistent across templates, and can be found at ProjectName.styles.css independent of whether the app is a blazor webassembly app or a server side blazor app.
For cases where the default StaticWebAssetBasePath has been overriden, the value is respected and the bundle is placed at $(StaticWebAssetBasePath)/ProjectName.styles.css.
Packaged razor class libraries with scoped css files now package a "project" bundle instead of the individual files.
- always use `$([MSBuild]::VersionXYZ(...))` for version checks
- use `$(NETCoreAppFrameworkIdentifier)` where it's available
- move `$(KnownAppHostPackOrFrameworkReferenceTfm)` setting to Directory.Build.props
- use it to correct `@(KnownFrameworkReference)` updates
- metadata of those items still uses `netcoreapp5.0`
- see also https://github.com/dotnet/efcore/pull/22279#discussion_r478674176
nits:
- do not assume `$(TargetFrameworkVersion)` starts with a 'v'; valid w/o it
- add `$(_IsMicrosoftNETCoreApp20OrOlder)` property in OpenAPI targets file
- evaluate the `Condition` once instead of three times
* Support pseudoelements in CSS scoping. Fixes#25268
* CR: More test cases
* Another pseudoelement case
* Case insensitivity for single-colon pseudoelements
Not that anybody should ever want to do this
* Avoid an allocation
* Add net461 TFM to netstandard2.0 projects
* Fix a couple of errors
* Fix some errors
* Get rid of Sockets reference
* Respond to feedback
* net461 -> property
* Fixup clientSample
* Remove net461 from analyzers/razor
* Remove net461 from test projects
* Feedback
* Add net461 test configs
* Remove some incompatible test configs
* Fix test
dotnet-watch expects full paths to files to watch in all added items. For files in the current project, this
happens to work. However this does not work very well for files in referenced projects. Using the FullPath metadata
does not work during global evaluation, but we're able to do this in a target.
This change adds extensibility to the dotnet-watch tool that allows calling a target as part of "watch" evaluation.
Fixes https://github.com/dotnet/aspnetcore/issues/22219
* Reject @import rules in scoped CSS files
* CR feedback: Use SourceText
* CR feedback: Another test case
* Use same file reading mechanism as "generate" command
Create new instances of List<T> with an appropriate capacity for the items that will be added.
Use Array.Empty<T>() where appropriate, rather than create an empty list and then return it.
* Use BlazorWebAssemblySDK
* Update projects to use the BlazorSDK
* Remove tasks and targets from RazorSDK
* Remove workarounds from BlazorSDK
* Fixup
* Fixup
* Remove Internal.AspNetCore.Analyzers
This resolves build flakiness caused by referencing the analyzer:
```
2020-08-07T21:22:39.1149296Z ##[error].dotnet\sdk\5.0.100-rc.1.20379.10\Microsoft.Common.CurrentVersion.targets(4188,5): error MSB3026: (NETCORE_ENGINEERING_TELEMETRY=Build)
Could not copy "F:\workspace\_work\1\s\artifacts\obj\Internal.AspNetCore.Analyzers\Release\netstandard1.3\Internal.AspNetCore.Analyzers.dll"
to "F:\workspace\_work\1\s\artifacts\bin\Internal.AspNetCore.Analyzers\Release\netstandard1.3\Internal.AspNetCore.Analyzers.dll". Beginning retry 1 in 1000ms.
The process cannot access the file 'F:\workspace\_work\1\s\artifacts\bin\Internal.AspNetCore.Analyzers\Release\netstandard1.3\Internal.AspNetCore.Analyzers.dll' because it is being used by another process.
```
The analyzer checks if pubternal types are being exposed in public APIs. We no longer author pubternal types, so this is no longer a concern.
* Remove DisablePubternalApiCheck
* Remove LinkerWorkaround.xml
The workaround file is no longer needed, now that the underlying bugs are fixed in the dotnet/runtime libraries.
Fix#23262
* Also remove LinkerWorkaround from Components/WebAssembly
- #20818, fix e.g. references to Microsoft.Web.Xdt.Extensions in our packages
- make `@(Reference)` items much more broadly applicable
- emit an error when `@(ProjectReference)` is used instead of `@(Reference)`
- then get rid of the errors (!!)
- rename a couple of projects to match their assembly names
- then regenerate the `@(ProjectReferenceProvider)` items
- switch intersection approach from Exclude / Exclude to Copy / Update / Copy
Projects of particular interest:
- src/DefaultBuilder/src/Microsoft.AspNetCore.csproj
- honouring metadata left e.g. Microsoft.AspNetCore.Components.WebAssembly.DevServer package unchanged
- removed redundant metadata after that confirmation
- src/Razor/tools/Microsoft.AspNetCore.Razor.Internal.Transport/
- content of this package unchanged but metadata avoids extra work
- add a comment about the extra work
- src/SiteExtensions/LoggingAggregate/src/Microsoft.AspNetCore.AzureAppServices.SiteExtension/
- success! removes Microsoft.Web.Xdt.Extensions dependency from the package
- src/SiteExtensions/Runtime/Microsoft.AspNetCore.Runtime.SiteExtension.pkgproj
- add a `Condition` to avoid an ordering issue I hit here
- src/Tools/Extensions.ApiDescription.Server/src/
- avoid errors the new build ordering and timing caused
Separately, up the timeout in the `<DownloadFile />` task
- hit repeated timeouts downloading dotnet-runtime-5.0.0-rc.1.20370.4-win-x64.zip
nits:
- remove dupe `@(Reference)` item in Microsoft.AspNetCore.Components.WebAssembly.DevServer.csproj
- remove useless `%(ProjectReference.IsImplicitlyDefined)` metadata as well as its misspellings
- remove extra spaces from ProjectReferences.props
- clean up a few comments in ResolveReferences.targets
* !fixup! Correct other references to renamed projects
The output of the declaration file for Razor components are unaffected by all inputs other than the input .razor file.
Consequently we can avoid regenerating these files if the output is newer than the input. This is the same heuristic we apply to Blazor WebAsssembly's
compression artifacts.
This PR combines these two improvements for a ~90ms (10%) improvement in the inner loop.
```
17 ms GenerateBlazorWebAssemblyBootJson 1 calls
22 ms Copy 8 calls
39 ms ProcessFrameworkReferences 1 calls
40 ms RazorTagHelper 1 calls
51 ms ResolveAssemblyReference 1 calls
70 ms GetFileHash 1 calls
80 ms RazorGenerate 2 calls
111 ms Csc 2 calls
Time Elapsed 00:00:00.95
```
```
17 ms GenerateBlazorWebAssemblyBootJson 1 calls
21 ms Copy 8 calls
37 ms ProcessFrameworkReferences 1 calls
51 ms ResolveAssemblyReference 1 calls
70 ms Csc 1 calls
72 ms GetFileHash 1 calls
79 ms RazorGenerate 2 calls
Time Elapsed 00:00:00.86
```
In after: Csc calls reduced to one, RazorTagHelper call removed.
* Wires up CSS isolation on the build.
* Transforms the css files during build.
* Bundles all scopes css into a single file and exposes it on _framework/scoped.styles.cs
* Packs pre-processed files as static web assets.
* Wires up CSS isolation on the build.
* Transforms the css files during build.
* Bundles all scopes css into a single file and exposes it on _framework/scoped.styles.cs
* Packs pre-processed files as static web assets.
* Simplify ref/ assembly generation
- followup 1/2 for 5266918ed2
- correct the Razor.Tools project
- `%(Reference.Version)` metadata does not bleed through into `@(PackageReference)` items
- much more work to do so than to add this special case
- remove `$(Razor_NewtonsoftJsonPackageVersion)`
- remove RTMVersions project and use RepoTasks instead
- make it an error if RepoTasks is not restored before anything else builds
- add items and properties for System.Security.AccessControl
nits:
- remove invalid (ignored) metadata in Directory.Build.props and AzureAppServices.SiteExtension project
- improve / extend a couple of comments
- move `@(Reference)` items together in Microsoft.AspNetCore.Razor.Tools
DotNet Bot
Steve Sanderson
Pranav K
Doug Bunting
Javier Calvarro Nelson
Kevin Pilch
Brennan
Artak
William Godbe
Chris Sienkiewicz
Martin Costello
Pranav Krishnamoorthy
Eric Erhardt
dotnet-maestro[bot]
Tanay Parikh
Safia Abdalla
Tanay Parikh