FYI, the pipeline is expected to fail because lack of .NET 9 on running agents.

@DavoudEshtehari Yes, that was expected, but it did not even fail ??

/azp run

@JRahnama Thanks, much better error this time 😄

The current .NET SDK does not support targeting .NET 9.0.

@cheenamalhotra @DavoudEshtehari @JRahnama @David-Engel What do we need to do to move this along?
Our build agents require .Net runtime 9 installed. Is the runtime supposed to be baked into the image itself? Or is there a script which downloads and installs the runtime?

@cheenamalhotra @DavoudEshtehari @JRahnama @David-Engel What do we need to do to move this along? Our build agents require .Net runtime 9 installed. Is the runtime supposed to be baked into the image itself? Or is there a script which downloads and installs the runtime?

1ES images do not have Net9.0 added. You can see included SDK in 1ES at here. What we can do is trying to install them manually, but then comes VS issues. Net9.0 needs another version of VS

@cheenamalhotra @DavoudEshtehari @JRahnama @David-Engel What do we need to do to move this along? Our build agents require .Net runtime 9 installed. Is the runtime supposed to be baked into the image itself? Or is there a script which downloads and installs the runtime?

To streamline the process and follow the pattern, a new artifact should be included in the images to reduce installation time for each run. But the compatible VS would be required though.

Not sure I understand the concerns about VS. I you just install the 9.0 preview SDK via a builtin Azure DevOps task and use dotnet build - but as usual I am probably overlooking something

Not sure I understand the concerns about VS. I you just install the 9.0 preview SDK via a builtin Azure DevOps task and use dotnet build - but as usual I am probably overlooking something

This is because .NET 9.0 is typically still in development or early release stages, and the corresponding tooling support for the latest .NET version is often provided in the preview releases of Visual Studio. For testing you can remove VS preview from your local machine and try running your application in Net9

@JRahnama I just use this setting in VS Options:

@JRahnama I just use this setting in VS Options:

but if you look into VS Installer you probably will see something similar as below.
However, I will try running them with a test pipeline. We may end up getting good results with C# 13 and not having VS 2022-preview.

@ErikEJ , hope you don't mind me pushing the yaml changes into your PR.

@JRahnama no, not at all! I would love to see this build

I think this will need a change in ci-prebuild-step.yml like:

- task: UseDotNet@2
  inputs:
    packageType: 'sdk'
    version: '9.x'
    includePreviewVersions: true

When tested on a local machine having .Net9.0 preview, Code SYSLIB0057 was thrown by the compiler for the following files:

• SNICommon,cs
• VirtualSecureModeEnclaveProviderBase.cs

When tested on a local machine having .Net9.0 preview, Code SYSLIB0057 was thrown by the compiler for the following files:

• SNICommon,cs
• VirtualSecureModeEnclaveProviderBase.cs

Basically you need to change the code to something similar to below:
in SNICommon:

#if !NET9_0_OR_GREATER
                        validationCertificate = new X509Certificate(validationCertFileName);
#else
                        validationCertificate = X509CertificateLoader.LoadCertificateFromFile(validationCertFileName);
#endif

in VirtualSecureModeEnclaveProviderBase.cs:

#if !NET9_0_OR_GREATER
                    certificateCollection.Import(data);
#else
                   _ =  X509CertificateLoader.LoadCertificate(data);
#endif

and in VirtualSecureModeEnclaveProvider.cs:

#if !NET9_0_OR_GREATER
            Certificate = new X509Certificate2(payload);
#else
            _ = X509CertificateLoader.LoadCertificate(payload);
#endif

After that you will get 5 more errors such as below:

SqlClient\artifacts\Project\obj\Debug.AnyCPU\Microsoft.Data.SqlClient\netcore\net9.0\Microsoft.Data.SqlClie
nt.notsupported.cs(798,37): error IL2093: 'DynamicallyAccessedMemberTypes' in 'DynamicallyAccessedMembersAttribute' on
the return value of method 'Microsoft.Data.SqlClient.SqlDataReader.GetFieldType(Int32)' don't match overridden return v
alue of method 'System.Data.IDataRecord.GetFieldType(Int32)'. All overridden members must have the same 'DynamicallyAcc
essedMembersAttribute'

Now we have to address those.

For the new CA2022 error, in addition to #if NET8_0_OR_GREATER for ReadExactly, since the compiler is throwing error for TargetFramework=net6.0, a #pragma warning disable/restore CA2022 was added for the #else block.

@ErikEJ, can I push minor fixes into this branch for issues found when compiling MDS locally?

For the new CA2022 error, in addition to #if NET8_0_OR_GREATER for ReadExactly, since the compiler is throwing error for TargetFramework=net6.0, a #pragma warning disable/restore CA2022 was added for the #else block.

Preferably, add them to the .editorconfig file inside netcore folder.

Per documentation

When to suppress warnings
It is safe to suppress the warning if the locked object is this or Me and the visibility of the self object type is private or internal, and the instance is not accessible using any public reference.
Otherwise, do not suppress a warning from this rule.

Please make sure these do not apply to these cases.

@arellegue go ahead...

A "dotnet_diagnostic.CA2022.severity = error" was added to .editorconfig instead since it is the preferred method.