## Description
Updates outdated dependencies for the Angular, React and React redux templates.
## Customer Impact
Customers creating new projects get obsolete versions of some javascript dependencies and need to update them manually.
## Regression?
- [ ] Yes
- [X] No
[If yes, specify the version the behavior has regressed from]
## Risk
- [ ] High
- [ ] Medium
- [X] Low
The changes only update dependencies and have been tested manually.
## Verification
- [X] Manual (required)
- [ ] Automated
## Packaging changes reviewed?
- [ ] Yes
- [ ] No
- [X] N/A
Remove MicrosoftAspNetCoreAuthenticationJwtBearerPackageVersion and MicrosoftAspNetCoreAuthenticationOpenIdConnectPackageVersion if there are not need eg. user wants only OpenApi.
Co-authored-by: Andrzej Król <andkrul@gmail.com>
Description
We introduced a public property as part of #27907 to enable users to opt-in. Turns out that this caused issues since we didn't update the target pack.
As a result, the Razor compiler treats this new property as a regular HTML attribute (of type string) instead of as a boolean.
In turn this causes the template to error at runtime when the application starts.
Customer Impact
Customers using 5.0.1 won't be able to create and run new blazor apps out of the box. They can fix the template code by preceding the true value in the attribute with @ to force the compiler to interpret it as C#. (Which is the same fix we are applying).
Regression?
Yes, 5.0.0. Users were able to create new blazor templates without this issue.
Risk
Low. We've manually validated the fix against a new project from a 5.0.1 template.
Description
In 5.0 we introduced two features on Blazor routing that enable users to write routing templates that match paths with variable length segments. These two features are optional parameters {parameter?} and catch all parameters {*catchall}.
Our routing system ordered the routes based on precedence and the (now false) assumption that route templates would only match paths with an equal number of segments.
The implementation that we have worked for naïve scenarios but breaks on more real world scenarios. The change here includes fixes to the way we order the routes in the route table to match the expectations as well as fixes on the route matching algorithm to ensure we match routes with variable number of segments correctly.
Customer Impact
This was reported by customers on #27250
The impact is that a route with {*catchall} will prevent more specific routes like /page/{parameter} from being accessible.
There are no workarounds since precedence is a fundamental behavior of the routing system.
Regression?
No, these Blazor features were initially added in 5.0.
Risk
Low. These two features were just introduced in 5.0 and their usage is not as prevalent as in asp.net core routing. That said, it's important to fix them as otherwise we run the risk of diverting in behavior from asp.net core routing and Blazor routing, which is not something we want to do.
We have functional tests covering the area and we've added a significant amount of unit tests to validate the changes.
Description
This PR updates the version of the caniuse-lite dependency to the latest version on our React and React/Redux SPA templates. The caniuse-lite dependency provides a database of browser features and their support across different browsers (as seen in caniuse.com). We were getting a warning because the dependency was out-of-date which meant that it was reporting compatibility info that was no longer accurate.
This PR also updates the version of node-sass to the latest version which no longer depends on the no-longer-supported Python 2.
Customer Impact
This bug was discovered during CTI validation.
This bug has a low severity because the user application can still run although JavaScript-based build tooling might report that the developer is leveraging browser features that aren't supported by the browser when they actually are.
Users can workaround this by running npx browserslist@latest --update-db inside their ClientApp directory. Users can also manually upgrade node-sass to v5 by editing their package.json file.
Regression?
No.
Risk
Low risk, because:
Change was validated manual
This fix applies the changes recommended by the browserlist library
* Updated icons for projects that appear in VS with icons that have the
language adornment.
This PR should fix#25973.
* updating icons for asp.net core templates in vs
* Fix chrome/selenium tests (#25330)
* Revert "Disable failing/hanging tests due to Chrome/Selenium issue (#25323)"
This reverts commit 332f1504128a63431cb67830703922cdeefee525.
* Update Selenium to latest
* Update API
* Try specifying a version
* Update Selenium to 4.0.0-beta5
* Disable browser log tests
* Fix components e2e tests and disable blazor standalone template test
* Disable tests using browser log
* Disable template test
* Avoid using .NET formatted strings in tests
* Annotate BasicTestApp suggesting that it needs the all globalization data
* Culture specific formatting relies on the ICU data carried by the OS. This
causes issues in our tests if WebAssembly carries a different set than the OS. Instead
updating these tests to use hardcoded strings.
* Additionally fixing an issue where some projects in the solution were using tasks from
the .dotnet SDK rather than the local copy of the SDK. This was causing issues building locally.
Co-authored-by: Pranav K <prkrishn@hotmail.com>
* Correct `$(SharedFxVersion)` and `$(TargetingPackVersion)` values
- Ensure `$(SharedFxVersion)` doesn't change in `$(NoSemVer20)` projects
- Ignore current project's `$(VersionSuffix)` in `$(TargetingPackVersion)`
- Never assume `$(AspNetCoreBaselineVersion)` matches released targeting pack
- Stabilize both versions correctly
- Use these properties more widely
- Remove other mechanisms to get the same values
- Reduce use of the `_GetPackageVersionInfo` target
- Reduce use of `$(SharedFxVersion)` for the targeting pack
nits:
- Correct comments about old RTMVersions.csproj project
- Fix or remove a few other comments
* Do not pass package filenames on Helix command Lines
- remove parsing of these command-line arguments from `RuntestOptions`
- instead craft the names using passed `$(SharedFxVersion)`
- restore `$(DotNetRuntimeSourceFeedKey)` on Helix command line
- lost somewhere along the line
- correct argument count in runtests.sh
- treated 11th argument as both Helix timeout and feed credential
- count was messed up somewhere alone the line
nits:
- update C# syntax in `RuntestOptions` e.g. remove unused `public` setters
- sort and group properties and their assignments
templates will be showing the templates directly in the New Project
Dialog instead in the One ASP.NET dialog.
In this PR I have updated the English titles. For localized strings we
will need to get those from the localization team. I believe we are not
setup for that to be automated here.
I think we should merge the English strings because they are the most
used, and for other locales we will show the old localized names for
now. If it's difficult to get those localized, I can work with @phenning
to see if we can localize those files this time.
* Fix header tab ordering issues. Fixes 1163117
* Ensure text can be zoomed to 200% without switching to mobile layout. Fixes 1163184.
* Ensure "Log out" link can show focus state. Fixes 1162890
* Use screen reader-friendly link text. Fixes 1163642
* Update template test
* Update JS interop to use auto-loaded ES6 module
* Test update
* Make it lazy for compatibility with prerendering
* Update comment
* Code style: go back to .AsTask - it's probably easier to read
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.
* Updating Web project templates to ms.id.web 0.3.0-preview
* version bump
and quick fix to the Blasorwasm default values for
the Web api so that customers have a better experience
* Microsoft.Graph is brought in transitively by MS.ID.Web
Co-authored-by: John Luo <johluo@microsoft.com>
* Updates to IdentityServer 4.0.4
* Updates templates with the new migrations.
* Fixes a small configuration bug that required the configuration for the key to be specified.
* Updates the error url in IdentityServer config to match our template defaults.
* Use BlazorWebAssemblySDK
* Update projects to use the BlazorSDK
* Remove tasks and targets from RazorSDK
* Remove workarounds from BlazorSDK
* Fixup
* Fixup
* Add workaround for deprecated overload in authentication scenarios
* Respond to feedback from peer review
* Use explicit version in Version.props
* Temporarily disable NU1065 warning
* Always use latest package version