unlock LangVersion latest for all c# snippets

[SimonCropp]

so that we can modernize samples

i made a change to one sample to prove the approach works

[BillWagner]

Hi @SimonCropp

I like the direction here to make it easier for more of our code snippets to use the latest language features. Our team has been updating snippets as we make changes to them.

However, we had a couple concerns:

1. This pulls all the snippets toward an unsupported scenario: using a higher C# language with a lower TFM. Users could accidentally fall into an unsupported scenario. Or, if they copied a single project rather than clone the repo, the samples might not build.
2. Some snippets are set to an older version by design. This is either because it's the starting point for a migration or a snippet that targets .NET Framework (WebForms, for example). It feels odd to add back the default setting.

So, we wonder about a different way to achieve the same goal. Suppose the Directory.build.props file set the TFM. Something like:

<?xml version="1.0" encoding="utf-8"?>
<Project>
  <PropertyGroup>
    <TargetFramework Condition="$(MSBuildProjectExtension) == '.csproj'">net10.0</TargetFramework>
  </PropertyGroup>
</Project>

(Or start with net9.0 for now).

Then, as we make any updates, we remove the TargetFramework node for the project. In time, the only projects with a TFM either need some extensions, are designed to be an older framework and version, or are using the current preview version.

What are your thoughts?

[SimonCropp]

@BillWagner

just to clarify some things

This pulls all the snippets toward an unsupported scenario: using a higher C# language with a lower TFM

this is a supported scenario via a global.json with an sdk and <LangVersion>. but i take the point that getting a sample that wont easily compile ot not ideal

if they copied a single project rather than clone the repo

AFAIK this is very dificiult to do in github. ie downloading a subdirectory of multiple files

Some snippets are set to an older version by design.

Having a newler langversion does not force us to use newer language features. although for those edge cases, where we want older version, i would argue for those projects an explicit older <LangVersion> should be set at the project/sln level

<TargetFramework Condition="$(MSBuildProjectExtension) == '.csproj'">net10.0</TargetFramework>

(Or start with net9.0 for now).

happy with that, although note people can still copy snippets that wont compile in there local choice of langversion and sdk

Then, as we make any updates, we remove the TargetFramework node for the project. In time, the only projects with a TFM either need some extensions, are designed to be an older framework and version, or are using the current preview version.

given <TargetFramework> is required, doesnt that land us with the probken project situration above. ie if someone gets a subdirectory for a project, with no <TargetFramework> it will not compile.

When i build this https://docs.particular.net/ the way i solved it was progromatically building solution/project zips for convenience. that way u get full control over what people download. so eg see the sample here https://docs.particular.net/samples/encryption/message-body-encryption/ u can download a zip that targets specific runtimes

docs for how the Smaple conventions https://github.com/Particular/docs.particular.net?tab=readme-ov-file#samples

overall, i dont mind what the solution is. my desired outcome is that all docs, unless there is a reason otherwise, target the current stable of c# (or their target language), consume the current sdk, and target the current stable runtime.

i can see there is potentially extra work (petenailly in the docs engine) and education for consumers to be done. I am happy to be involved in that

let me know if u want to jump on a call to discuss in person