Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
Anders Åberg
@abergs
Because the readme got 2 lines longer. I decreased the unit test coverage with 2.4%. hahah.
Tomasz Maczyński
@tmaczynski
the problem with nuget badge is that sometimes an image is not loaded
Johan Larsson
@JohanLarsson
Yeah, it is a bit buggy.
Sam Harwell
@sharwell
@abergs Not sure why coverage is reported like that
Andrew Arnott
@AArnott
My project has the same problem. I think it's the non-deterministic nature of the unit tests given the multithreaded environment.
Johan Larsson
@JohanLarsson
What do you guys prefer here:
this:
public Task FooAsync()
{
    return this.BarAsync(this.CreateArgument());
}
or this:
public async Task FooAsync()
{
    await this.BarAsync(this.CreateArgument()).ConfigureAwait(false);
}
Andrew Arnott
@AArnott
It depends. The first is more efficient but the latter gives a better return stack view. I usually go for the first though.
Sam Harwell
@sharwell
Especially the first if BarAsync has restricted visibility and the caller (FooAsync) will be obvious from other context.
Johan Larsson
@JohanLarsson
Yeah, it depends, I usually go with the first also.
Andrew Arnott
@AArnott
There are slight variations on this pattern where you have to go with the latter. For example when the tasks being returned have different T types, which requires that the outer method await in order to repackage the task result.
Sam Harwell
@sharwell
@AArnott Any objection to this?
DotNetAnalyzers/AsyncUsageAnalyzers#65
Andrew Arnott
@AArnott
Not at all. That looks good.
Sam Harwell
@sharwell
While you're here
Need to change behavior of ANTLR's custom item types for .NET SDK projects
Planning to trigger behavior change on Condition="'$(TargetFramework)' != ''"
As my trickery in lieu of dotnet/sdk#534
Andrew Arnott
@AArnott
You might want to trigger based on Condition="'$(TargetFramework)' != '' or '$(TargetFrameworks)' != ''" so that it works on multi-targeting "cross build" builds as well.
Sam Harwell
@sharwell
<Antlr4IsSdkProject>False</Antlr4IsSdkProject>
<Antlr4IsSdkProject Condition="'$(TargetFramework)' != '' OR '$(TargetFrameworks)' != ''">True</Antlr4IsSdkProject>
Andrew Arnott
@AArnott
seems reasonable
Sam Harwell
@sharwell
I'll give users a way to work around bugs:
<PropertyGroup Condition="'$(Antlr4IsSdkProject)' == ''">
  <Antlr4IsSdkProject>False</Antlr4IsSdkProject>
  <Antlr4IsSdkProject Condition="'$(TargetFramework)' != '' OR '$(TargetFrameworks)' != ''">True</Antlr4IsSdkProject>
</PropertyGroup>
Andrew Arnott
@AArnott
:+1:
Phil Tremblay
@jesuissur
Hi guys
Does this feature dotnet/roslyn#20782 has been integrated in the AsyncUsageAnalyzers project?
Sam Harwell
@sharwell
@jesuissur No, but I'd love to see it included.
Andrei Volkov
@zvolkov
anything special needs to be done for these analyzers to kick in during the build? We're running style cop ones by having this in our project.json, but no luck with AsyncUsageAnalyzers?
"AsyncUsageAnalyzers": {
            "version": "1.0.0-alpha003",
            "type": "build"
}
do the rules need to be explicitly enabled, or is this because I'm not running the latest version?
Sam Harwell
@sharwell
I'm actually not sure. I haven't used project.json before
Maybe ask in dotnet/Roslyn
Andrew Arnott
@AArnott
@sharwell What is the future of this project? I see lots of issues filed and a couple of very stale PRs on it. I'm keenly interested because with the advent of ValueTask, the analyzers are misfiring saying I shouldn't use the Async suffix on method names that return ValueTask. The vs-threading analyzers already do some of what the 3 analyzers in this project do, so I'm trying to decide whether I should invest time in a PR for this project to add support for ValueTask at least (and hope the PR is accepted and a new version published to nuget.org) or just abandon use of this package and add the equivalent functionality to vs-threading.
Sam Harwell
@sharwell
@AArnott let's set up a meeting this week and talk about options
Andrew Arnott
@AArnott
Sounds good. Thanks for #70 BTW
KLuuKer
@KLuuKer
@sharwell @AArnott so what are the results of that meeting?
Sam Harwell
@sharwell
vs-threading analyzers will be updated to include most if not all rules from AsyncUsageAnalyzers, and should provide a more complete overall set of analyzers. We have a goal of allowing vs-threading analyzers to be used even in projects that do not use vs-threading (e.g. asynchronous web applications that don't even have a main thread), and believe the analyzers are already usable in these cases. The primary missing piece right now is documentation regarding the expected configuration for these scenarios.
Andrew Arnott
@AArnott
The latest stable release of Microsoft.VisualStudio.Threading.Analyzers already is a proper superset of AsyncUsageAnalyzers. We filled in the remaining gaps (Microsoft/vs-threading#382) in our 15.8.168 release.
The analyzers can already be used without using the Microsoft.VisualStudio.Threading library as well, although it's possible some rules will suggest fixes that don't apply to your app yet, in which case you can turn off those individual rules (and please file a bug if you notice this happening). As for the documentation, and a way to automatically set up appropriate default rulesets per app-type, that's something we're working on.
KLuuKer
@KLuuKer
@AArnott there really should be some kind of document or whatever that makes it easy to find these kinds of extensions
never knew it existed until now
Andrew Arnott
@AArnott
Are you talking about the threading analyzers? Where would you look for such a document?
KLuuKer
@KLuuKer
analysers in general, I always keep on missing some kind of analyser I should have because I am unable to find them
because this is my current list of analysers
AsyncFixer
Microsoft.CodeAnalysis.CSharp
Microsoft.CodeAnalysis.CSharp.Workspaces
Microsoft.CodeAnalysis.FxCopAnalyzers
Microsoft.DotNet.Analyzers.Compatibility
StyleCop.Analyzers
ToStringWithoutOverrideAnalyzer
and after some more searching (again) I found these
Microsoft.VisualStudio.Threading.Analyzers
IDisposableAnalyzers
ReflectionAnalyzers
Andrei Volkov
@zvolkov
Hello, a user checking in here. Last time I wanted to use these, they did not work with project.json - now that we are on Core 2.1 and back on MsBuild, this is expected to work OOB, right? I can just grab Microsoft.VisualStudio.Threading.Analyzers and use them as any other analyzer?
Andrew Arnott
@AArnott
@zvolkov project.json is dead. No new features being developed are tested with such projects. You can't target .NET Core 2.1 with project.json AFAIK.
But yes, you should be able to use MS.VS.Threading.Analyzers and use them as any other analyzer.
Andrei Volkov
@zvolkov
Okay cool. Looks like it just works OOB.
Sam Harwell
@sharwell
I archived AsyncUsageAnalyzers and changed the description to point to Microsoft/vs-threading