-
Notifications
You must be signed in to change notification settings - Fork 4.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Extensions: Adding FileProviders and FileSystemGlobbing #33212
Conversation
bee8a39
to
9132d57
Compare
I'm not seeing this? |
@steveharter @layomia looks like Json tests timed out here:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sln files?
@@ -15,7 +17,7 @@ | |||
<StrongNameKeyId>MicrosoftAspNetCore</StrongNameKeyId> | |||
<IsAspNetCoreApp>true</IsAspNetCoreApp> | |||
<!-- Temporarily ignore nit warning/errors (e.g. extra whitespace) from Extensions projects --> | |||
<NoWarn Condition="!$(MSBuildProjectName.EndsWith('.Tests'))">$(NoWarn);SA1129;SA1028;SA1027;SA1121;CA1200</NoWarn> | |||
<NoWarn Condition="!$(MSBuildProjectName.EndsWith('.Tests'))">$(NoWarn);SA1129;SA1028;SA1027;SA1121;CA1200;SA1000;CA1507;CA1802;CA1825</NoWarn> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For the curious (like me)
SA1129: DoNotUseDefaultValueTypeConstructor
SA1028: CodeMustNotContainTrailingWhitespace
SA1027: UseTabsCorrectly
SA1121: UseBuiltInTypeAlias
CA1200: Avoid using cref tags with a prefix
SA1000 : KeywordsMustBeSpacedCorrectly
CA1507: Use nameof in place of string
CA1802: Use Literals Where Appropriate
CA1825: Avoid zero-length array allocations
Most of these should be easy to come back and fix at once.
Match what extensions did, which should be 1:1 library to package. |
<TargetFrameworks>netstandard2.0;$(DefaultNetCoreTargetFramework)</TargetFrameworks> | ||
<TargetFrameworks Condition="'$(DotNetBuildFromSource)' == 'true'">$(DefaultNetCoreTargetFramework)</TargetFrameworks> | ||
<GenerateDocumentationFile>true</GenerateDocumentationFile> | ||
<PackageTags>aspnetcore;validation;options</PackageTags> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Where do these "PackageTags" go now? If we are removing them here, where should it go?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we wanted to maintain them they'd go in the pkgproj, but we'd need to fix this: https://github.com/dotnet/arcade/blob/ed8c23ff7c4f4988a754ff9afc626571f16e3382/src/Microsoft.DotNet.Build.Tasks.Packaging/src/build/Packaging.targets#L52
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Honestly I don't think they are worth preserving, but I'm happy to hear otherwise if folks feel strongly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do you feel they are not worth preserving? They assist when searching on nuget.org.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well aspnetcore
is not really accurate anymore, and I the other two don't feel very informative (though I could be wrong). My experience with this sort of thing is that folks put stuff there because it was in a template then it gets stale. If on the other hand there was a concerted effort to deliberately set tags and make them meaningful then by all means keep them. It doesn't hurt to just copy all these into the pkgproj for now and we'll fix the bug where they don't make it into nuspec.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@anurse @bradygaster - how much effort/thought went into the existing tags?
I agree we can easily dropp aspnetcore
from these. But I'm not so sure about the other tags.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thought? Almost none ;). Feel free to change them at-will.
src/libraries/Microsoft.Extensions.FileSystemGlobbing/src/Properties/InternalsVisibleTo.cs
Show resolved
Hide resolved
...s/Microsoft.Extensions.FileSystemGlobbing/src/Microsoft.Extensions.FileSystemGlobbing.csproj
Show resolved
Hide resolved
...s/Microsoft.Extensions.FileSystemGlobbing/src/Microsoft.Extensions.FileSystemGlobbing.csproj
Show resolved
Hide resolved
@ericstj that should show up in next PR |
...nsions.Configuration.Abstractions/ref/Microsoft.Extensions.Configuration.Abstractions.csproj
Show resolved
Hide resolved
08edf57
to
ec06b61
Compare
I have not seen a timeout here before. I looked at the test and it doesn't seem possible to get a hang\deadlock. The test uses ~.5MB -- is memory low on the hardware? |
…nd FileSystemGlobbing
…iders and FileSystemGlobbing
note: will be replaced by GenerateReferenceSource afterwards
from: Resources.resx to Resources\Strings.resx
-- note: in a previous bulk commit, descriptions for FileProviders and FileSystemGlobbing were already added in json file - [ ] TODO: test packaging failed with message: Unable to find description for package Microsoft.Extensions.FileSystemGlobbing (perhaps because it wants to create package for netcoreapp)
- [x] Enable on Directory.Build.props - [x] build ref/src projects and used GenerateReferenceSource - [x] cleanup src csproj properties - [x] set proper targetframeworks TODO - [ ] Add package, 3 projects go in one package - [ ] Fix failing test on M.E.FP.Physical with message: Could not load file or assembly 'Microsoft.Extensions.FileProviders.Abstractions, Version=5.0.0.0
- Fix packaging issue - Remove InternalsVisibleTo in src csproj - Add sln file
- Abstractions - Composite - Physical
Done: [x] bring over more history from extensions repo for - TaskExtensions.cs - ITestCondition.cs - OperatingSystems.cs - OSSkipConditionAttribute.c
ec06b61
to
c1233d6
Compare
...nsions.FileProviders.Physical/tests/Microsoft.Extensions.FileProviders.Physical.Tests.csproj
Outdated
Show resolved
Hide resolved
This looks good now. CI is going 📗 🚀 |
Looking over the failing tests on CI, e.g.: |
The remaining failure on the CI is for System.IO.FileSystem.Watcher.Tests This should be good to merge |
Did you open an issue for the FileSystem.Watcher test failure? Was there one already tracking it? |
Here we go: #24181 Please make sure you take some action when you observe a failure that isn't caused by your change. That's how we get better 👍 |
Todo on this PR:
For upcoming PRs:
there will be some tasks I'll get to once all projects are building, like: