Thank you so much for your uplifting feedback @bayn.es. I am really glad you liked my session.

I just left a couple of rough months behind me, so your kind words are a true pick-me-up for my spirit.

You are very welcome.

‪@rlittlesii.bsky.social‬

We are now starting a series on #Benchmarking #Roslyn Compiler Extensions.

We begin with setting up the project and building a first prototype.

bsky.app/profile/flas...

We're building up to it:
Today, we will inspect, together with @kevingosse.net, what methods and calls really are

bsky.app/profile/flas...

and then - probably next episode - kick-start our journey of Tools for Roslyn Compiler Extensions; starting with Benchmarking.

We'll ping you when announced.

Not quite yet.
But we are about to get back into live-streaming next week, and will be building up towards Benchmarking of Roslyn Compiler Extensions.
I'll get back to you once we actively start that endeavour.

From what I read is that "Compiler-Extensions" is the official term used in (limited) documentation for Plugins that Roslyn-Hosts may load for compilations (Analyzers, Suppressors, Generators) and IDEs/Editors may interact with via Workspaces (Fixers, Refactorings, Completions).

Also ... so I think, I'm not positive though ... that, technically speaking, if your Extensions only use types that they are safe/meant to use, in accordance with the respective [Attribute], you should be fine putting all together in a single Assembly and it should work for the most common scenarios

...

Example:
Should you use a type from "Microsoft.CodeAnalysis.CSharp.Workspaces" in your Analyzer or Suppressor or Generator, but your Extension is loaded in a Build/Compilation-Scneario (only Editor-Scenarios usually require the Workspaces-APIs to be loaded), then your Extension might not work.

...
The reason for this guideline is that Roslyn is a Library which can be hosted by any tool, so the Extension-Author does not necessarily know under which environment the Compiler will run and whether, e.g., the Workspaces-Assembly is loaded or just "Microsoft.CodeAnalysis.CSharp/VisualBasic".
...

...

And for NuGet, you can pack them together in PackagePath="analyzers/dotnet/cs".

I usually have a separate CSPROJ that only represents the NuGet package and packs all netstandard2.0 libraries together.

...

I love/hate to say: It depends.

For maximum compatibility and safety, separate Roslyn-Extensions by Diagnostics-API (Analyzers + Suppressors + Generators) and Workspaces-API (Fixers + Refactorings), as well as separate Compiler-Extensions by Language (Common / CSharp / VisualBasic).

...

I never had matching T-shirts before 👕
I got mine from @updateconference.bsky.social #UpdateConference

I seem to never be too sure whether to ship a "ForAttributeWithMetadataName"-Generator with a Diagnostic+CodeFixer when the annotated type is not modified with `partial`, or to just generate the partial declaration anyway and let tooling offer the Refactoring to make to type partial via error CS0260