Stefan (FlashOver) Pölz

YouTube video by FlashOWare 2code ^ !2code [S2025E14] C# 14 & .NET 10

It is a #2codeOrNot2code tradition to host @stu.dev diving deep into the latest #CSharp language features, as well as discussing what's new in #dotnet. Join us for some sweet syntactic sugar of C# 14 and .NET 10.

Date: 2025-11-18 (Tuesday)
Time: 18:00 (UTC±00:00)

www.youtube.com/watch?v=61kj...

YouTube video by FlashOWare 2code ^ !2code [S2025E13] Multi-targeting Roslyn Components - Part 3

It's time for the multi-targeting finale, dear dedicated #dotnet developers.
We're concluding our journey of packing #MSBuild .props and .targets for versioning of #Roslyn components like #CSharp analyzers.

Date: 2025-11-10 (Monday)
Time: 18:00 (UTC)
#2codeOrNot2code
www.youtube.com/watch?v=RuOl...

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.

YouTube video by FlashOWare 2code ^ !2code [S2025E12] Multi-targeting Roslyn Components - Part 2

Again, it's multi-targeting Wednesday, dear dedicated #dotnet developers.
We're back with packing #MSBuild .props and .targets for versioning of #Roslyn components like #CSharp analyzers.

Date: 2025-09-17 (Wednesday)
Time: 17:00 (UTC)

#2codeOrNot2code

www.youtube.com/watch?v=wxUQ...

YouTube video by FlashOWare 2code ^ !2code [S2025E11] Multi-targeting Roslyn Components - Part 1

It's multi-targeting Wednesday, dear dedicated #dotnet developers,
where we pack some .props and .targets for versioning of Roslyn components like #CSharp source generators.

Date: 2025-08-27 (Wednesday)
Time: 17:00 (UTC)

#2codeOrNot2code

www.youtube.com/watch?v=ipoG...

YouTube video by FlashOWare 2code ^ !2code [S2025E10] Benchmarking Compiler Extensions - Part 3

Even more Performance Measurement and Profiling of Roslyn Source-Generators included in Part 3 of Benchmarking Compiler Extensions.

- Wednesday, 2025-08-13
- 17:00 UTC

#dotnet #CSharp #Roslyn
#2codeOrNot2code

www.youtube.com/watch?v=8kpl...

YouTube video by FlashOWare 2code ^ !2code [S2025E09] Benchmarking Compiler Extensions - Part 2

More Performance Measurement and Profiling of Roslyn Source-Generators upcoming in Part 2 of Benchmarking Compiler Extensions.

We moved the live-stream by one day,
to: Thursday, 2025-08-07
at the same time: 17:00 UTC

#dotnet #CSharp #Roslyn
#2codeOrNot2code

www.youtube.com/watch?v=pRLR...

‪@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...

YouTube video by FlashOWare 2code ^ !2code [S2025E08] Benchmarking Compiler Extensions - Part 1

The (run)time has come!
We allocate this series to build a library that supports Benchmarking of #Roslyn Compiler Extensions, like #dotnet Analyzers and #CSharp Source-Generators.

2025-07-23 Wednesday
17:00 UTC

#2codeOrNot2code

www.youtube.com/watch?v=Rbu8...

Can't wait till Saturday.

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.

YouTube video by FlashOWare 2code ^ !2code [S2025E07] .NET Method-ologies

Let's inspect "The hidden life of method calls" in #dotnet via #CSharp with @kevingosse.net.

Date: 2025-07-09 Wednesday
Time: 17:00 UTC

#2codeOrNot2code

www.youtube.com/watch?v=JhBI...

YouTube video by FlashOWare 2code ^ !2code [S2025E06] The .NET Dispose Pattern

We're back! After our "Tour de Talk", we continue our theme of #dotnet Memory Management and combine it with our session about Patterns from both #NDCOslo and #TechoramaBE 2025:
Let's dive deep into the #CSharp Dispose Pattern.

on Tuesday, 2025-06-24
at 17:00 UTC

www.youtube.com/watch?v=qRuG...

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

YouTube video by FlashOWare 2code ^ !2code [S2025E05] Pro .NET Memory Shenanigans

Pro .NET Memory Shenanigans:
In this April Fools' Day episode, @merelyeva.bsky.social and @flash0ver.bsky.social unveil some Memory-related inner workings of #dotnet with unsafe and unexpected #CSharp shenanigans.

2025-04-01 | 17:00 UTC (5 PM)
#2codeOrNot2code

www.youtube.com/watch?v=Xqdk...

YouTube video by FlashOWare 2code ^ !2code [S2025E04] Pro .NET Memory Management

Pro .NET Memory Management

The co-authors of the 2nd edition - Konrad Kokosa, @chrisnas.bsky.social, @kevingosse.net - talk about the content and the book per se.
Join with your curiosity and your questions to the trio.

2025-03-25
18:00 UTC

#dotnet #CSharp #Memory

www.youtube.com/watch?v=DboS...

Good news for Late Birds:
Apply a 20 % discount for your @futuretechnl.bsky.social ticket, just in time.

- Future Tech 2025
@ Jaarbeurs Utrecht (the Netherlands)
on Thursday, March 13

Code: FutureTech_SDN20
Link: www.eventbrite.nl/e/938191274357/?discount=FutureTech_SDN20
until Monday, March 10

YouTube video by FlashOWare 2code ^ !2code [S2025E03] Roslyn Diagnostics & CodeActions

Computer, run Diagnostics!
We build an Analyzer (reports Warnings) and a corresponding CodeFixer (provides CodeActions via Ctrl+. or Alt+Enter) for #CSharp code in #dotnet projects with #Roslyn.

2025-03-06 (Thursday)
18:00 (UTC)

www.youtube.com/watch?v=bRub...

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

YouTube video by FlashOWare 2code ^ !2code [S2025E02] Roslyn Code Analysis

Thursday I'm doing a live stream with @flash0ver.bsky.social and @merelyeva.bsky.social on all things Roslyn. Hope to see you there!

#dotnet #csharp

www.youtube.com/watch?v=t9PN...

I like the idea.
But the devil is in the detail: this only works for reference types that have the default constructor or a parameterless .ctor.

But I guess that's something a Diagnostic Analyzer on Attribute-annotated reference types + a CodeFix Provider could alleviate.

One thought I'd like to add is that if Thing, or the [ReferenceDefault]-annotated type, is not immutable, there now is a shared mutable instance, like the deprecated System.IO.Path.InvalidPathChars. Perhaps there could be an analyzer flagging non-readonly types, or generate a factory member instead.

Not that I can think of.
Such semantics could get quite tricky in a generic context, especially when unconstrained.
Off the top of my head, you may perhaps introduce an `I(Default)Creatable<T>` interface to your app or domain, and implement a `static abstract T Create(Default)` method on your types.