* Make some tweaks to the default content globs
- Don't publish/copy launchSettings.json
- Make sure static content and configuration work with single file turned on
- Added test
\n\nCommit migrated from 63e8681fff
* Modify tag helper infrastructure to configure case sensitivity
* Cleanup and added more tests
* More cleanup and added necessary diagnostics
* More feedback
* Added more tests
\n\nCommit migrated from 20b8286751
- Updated existing tests to use `public` accessibility for parameters. As part of this also updated baselines.
- We now recommend that `[Parameter]`'s should be `public`. In the future this will be a requirement.
aspnet/AspNetCoredotnet/aspnetcore-tooling#8825
\n\nCommit migrated from 2ceb597f82
- Without this any diagnostics from Analyzers will be doubly reported. One for the declaration compilation and one for the view compilation.
aspnet/AspNetCoredotnet/aspnetcore-tooling#8825
\n\nCommit migrated from 6d115d460b
- Added a feature flag to ensure this functionality does not impact pre-3.0 applications. This change is in fact a breaking change because some less-common scenarios will no longer be valid. For instance, `@Name!.Hello`used to treat the `!.Hello` as markup, now it will be treated as part of the expression.ExpressionChunkGenerator
- Updated parser flags tests
- Updated parser tests
- Updated the C# 8.0 integration tests to include the new nullable forgiveness scenarios.
aspnet/AspNetCoredotnet/aspnetcore-tooling#11188
\n\nCommit migrated from 625c605607
This fixes a regression in the new `@ref` support, where the build will
fail during the declaration pass.
The problem is that the EliminateMethodBodyPass runs really early and
wipes out the usage of `@ref` before we have a chance to see it. The
solution is to make it run really late. This makes sense because we
basically just use this pass to do cleanup.
\n\nCommit migrated from 09b50151ef
Adds the code generation support for culture + bind.
Some additonal changes are needed for the compiler support for bind, we
need to pass the culture into the code that unwraps the value as well.
There's no need to eagerly push these changes into the runtime (can wait
for the compiler change to go in) because nothing in our runtime tests
use the new feature.
\n\nCommit migrated from 6aad9748e8
Adds the ability to specify that an `<input type="..." />` for some
specific value of `type` maps to the invariant culture and/or provides
a default format.
The primary examples of usage would be the number field which wants to
use invariant culture, or datetime which wants to use invariant culture
and a format string.
\n\nCommit migrated from 60f2d563a6
Updates our Components shim to use the ref assembly code. This is just
cleanup and will help us keep up-to-date with API review changes since
we can just copy-past the files.
I made two modifications to make this simple.
- Removed our built-in components
- Removed the HTTP stuff
This makes it easier for us to maintain the shim. You can see cases
where I had to update tests because they diverged from what the real
APIs look like (no product bugs).
I'd still like to improve this workflow so suggestions wanted xD
\n\nCommit migrated from 8517be2bac
This change makes @ref define a field for you by default. We didn't do
this originally because we weren't sure if the compiler generating a
field would always be what you want, and more importantly,
we didn't have the expressiveness to add an opt-out.
Now that we have directive attributes, it's easy to create an opt-out
for the field generation. The special thing about it is that where
you opt-out has to be static. For this reason the @bind:suppressField
attribute cannot be used with a value, you either have the flag or not.
Additionally, we don't support automatic field generation for
generics, because usually we can't write the field name. If we
want to in the future could make this work when the generic
type arguments are specified. So in the case of generics,
you have to opt-out, and you will get a diagnostic
that tells you so.\n\nCommit migrated from dadf9faf22
Currently FindAssembliesWithReferencesTo produces a stacktrace when P2P builds fail - for instance
if the referenced project has a compiler error. This changes it to use LogErrorFromException.
In addition, there was a typo in the property that disabled the feature.
Fixes https://github.com/aspnet/AspNetCore/issues/11226\n\nCommit migrated from 87c12a116c
- add feeds that SDK no longer provides automatically when building test apps
- add another allowed build warning in some integration tests\n\nCommit migrated from cfd4698381
* Add TagHelperDescriptorProvider
* Remove bad life-choice
* Add some AddRange love
* Add splatting lowering and codegen
* PR feedback
\n\nCommit migrated from 9c8dd1cae7
* Allow @bind:event override when used with @bind
* Added more tests to cover standalone @bind-value=... case
* fix
\n\nCommit migrated from a399bd072e
- It looks that when we first did VCTH we never put in the effort to reduce our footprint on available parameters for `ViewComponentTagHelper`s. I went ahead and added several underscores to the generated fields/parameters to reduce collisions.
- Updated tests to reflect the new codegen.
aspnet/AspNetCoredotnet/aspnetcore-tooling#8645
\n\nCommit migrated from b545a4de75
- WTE needs a way to detect if a `TagHelperDescriptor` is a component based `TagHelper` in order to turn features like validation, completion etc. on/off.
- Updated tests to add verification points for the new `IsRazorComponentTagHelper` method.
\n\nCommit migrated from 6fcd12e60b
* Adds support for publishing static web assets
* At publish time, it copies all the referenced assets from referenced
projects and packages into their final locations.
* Automatically pack static web assets for consumption
* Generate Microsoft.AspNetCore.StaticWebAssets.props and pack it into
build\Microsoft.AspNetCore.StaticWebAssets.props
* Generate `<<PackageId>>.props` and pack it into `build\<<PackageId>>.props`
importing Microsoft.AspNetCore.StaticWebAssets.props
* Generate `<<PackageId>>.props` and pack it into buildMultiTargeting\`<<PackageId>>.props`
importing `build\<<PackageId>>.props`
* Generate `<<PackageId>>.props` and pack it into buildTransitive\`<<PackageId>>.props`
importing buildMultiTargeting\`<<PackageId>>.props`
* Pack all the static web assets from the current project into `staticwebassets\**`\n\nCommit migrated from 87817bed3e
* Define static web assets in the current project
* These are assets under the wwwroot folder.
* By convention, the base path for these assets is `_content/<<PackageId>>`
with spaces and dots removed and all characters lower-cased.
* Retrieve static web assets from referenced projects\n\nCommit migrated from 50646aae64
* Specify UpToDateReloadFileTypes
Specify a list of file extensions that VS will monitor for file changes to reload the app.
Includes .razor and .cshtml files.
\n\nCommit migrated from 9a964127bf
This came up in the context of discussion around aspnet/AspNetCoredotnet/aspnetcore-tooling#5071.
Browsers use a 'first attribute wins' rule for evaluating attributes and
building the DOM - though duplicate attributes are considered to be a
spec violation.
Blazor wants to use 'last attribute wins' rules because that's most
sensible when you consider evaluation order and splatting.
This means that we have to have the markup block pass do the same thing
as the Blazor runtime when duplicates appear. However, since this is a
spec violation I'm proposing that we just make it an error (like we do
for malformed tags). There's no useful purpose for duplicate attributes
since browsers ignore it.
Since we're not going to allow this for elements. Let's go all of the
way and block it for components as well. And while we're here, lets
block some of the invalid cases where users try to mix onchange and
bind. These don't work today, so we should make them an error. If we
decide to add support for this case to the runtime that would require
compiler work anyway.
\n\nCommit migrated from 0c59ca5f74
* Directive attributes part 1: Support parameters in bound attributes
* update
* Fix test
* feedback
* Updated design
* Do case sensitive comparison
* more
* Bug fix
\n\nCommit migrated from 9bbf240948
* Imports static assets from packages containing custom msbuild
targets defining a StaticWebAsset item group.
* Generates an embeds a manifest into the application assembly
that contains a list of paths to the content roots of the
assets defined in the packages custom msbuild targets.\n\nCommit migrated from 8e70013b70
* Move the globs from the project system into the Razor SDK on a separate file that can be imported by itself.
* Import the file conditionally based on the EnableRazorContent property\n\nCommit migrated from 62e33dac1d
The intention here would have been to add to the existing GetCopyToOutputDirectoryItemsDependsOn property, defined in Microsoft.Common.Targets. Instead what was happening is that it was being completely overwitten with the _RazorGetCopyToOutputDirectoryItems entry, given that $(GetCopyToOutputDirectoryItems) doesn't exist as a property and must have been a typo (it exists as a task, not a property).
An effect of this bug was that the `AssignTargetPaths` target is not always executed before the `GetCopyToOutputDirectoryItems` target, which should explicitly depend on it. `AssignTargetPaths` is responsible for populating the `ContentWithTargetPath` itemgroup. Left empty, it appears to `GetCopyToOutputDirectoryItems` task that there are no Content files to copy to the final output directory, when in fact there are.\n\nCommit migrated from 4597bc3d55
David Fowler
Ajay Bhargav Baaskaran
N. Taylor Mullen
Ryan Nowak
Javier Calvarro Nelson
Ryan Nowak
Pranav K
Doug Bunting
Steve Sanderson
Nate McMaster
Ajay Bhargav Baaskaran
Alex Lorimer