Use Roslyn apis to generate Platform Not Supported Assemblies

[Anipik]

Fixes #33631

[Dotnet-GitSync-Bot]

Note regarding the new-api-needs-documentation label:

This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, to please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.

[ViktorHofer]

Would you mind adding comments to code paths which aren't self-explanory like the string replacement, the rooted check, etc. Also would it make sense to move the added infra code to a separate file instead, ie notsupported.targets?

[Anipik]

System.IO.Filesystem tests are being shown as failures on wasm, but the log doesnt show any failing tests. @lewing and @steveisok are u aware of such issues ?
This Pr doesnt affect system.IO.Filesystem. so this should not fail

[ghost]

Tagging subscribers to this area: @safern, @ViktorHofer
See info in area-owners.md if you want to be subscribed.

[Anipik]

@akoeplinger @marek-safar can you help with this failure ?

[06:33:11] dbug: test[0]
      WASM-ERR: 
      
[06:33:11] dbug: test[0]
      WASM-ERR: Unhandled Exception:
      
[06:33:11] dbug: test[0]
      WASM-ERR: System.PlatformNotSupportedException: System.Diagnostics.Process is not supported on this platform.
      
[06:33:11] dbug: test[0]
      WASM-ERR:    at System.Diagnostics.Process.Dispose(Boolean disposing)
      
[06:33:11] dbug: test[0]
      WASM-ERR:    at System.ComponentModel.Component.Finalize()
      
[06:33:11] dbug: test[0]
      WASM-ERR: [ERROR] FATAL UNHANDLED EXCEPTION: System.PlatformNotSupportedException: System.Diagnostics.Process is not supported on this platform.
      
[06:33:11] dbug: test[0]
      WASM-ERR:    at System.Diagnostics.Process.Dispose(Boolean disposing)
      
[06:33:11] dbug: test[0]
      WASM-ERR:    at System.ComponentModel.Component.Finalize()
      
[06:33:11] info: test[0]
      06:33:11.3507301 Process exited with 255
      
XHarness exit code: 1001
XHarness artifacts: ./xharness-output

[akoeplinger]

@Anipik it looks like the finalizer is throwing PNSE which shouldn't happen. Did something change with the PNSE assembly generator? GenAPI has code to omit the destructor when generating PNSE: https://github.com/dotnet/arcade/blob/89b5ce0df8958006752f50264eab47f6e4866081/src/Microsoft.Cci.Extensions/Writers/CSharp/CSDeclarationWriter.Methods.cs#L28-L35

[Anipik]

yes we are adding the platform not supported exception to the destructor as well.

[Anipik]

dotnet/arcade@6069731#diff-0b23f22024280d202b940989d8657b16R121

[akoeplinger]

that's a problem then since finalizers aren't supposed to throw exceptions.

[Anipik]

that's a problem then since finalizers aren't supposed to throw exceptions.

is there a specific reason behind everything throwing the exception beside destructor. The fix should be in tooling or in implementation ?

[akoeplinger]

the problem with throwing from the destructor is that you can't catch that exception, e.g. the following code would still crash the process once the object is finalized:

try {
   var p = new ClassThatThrowsPNSE();
} catch (PlatformNotSupportedException) {
  // alternate logic
}

so yeah the PNSE generation tooling needs to ensure not to generate an exception for the destructor.

[safern]

@Anipik I merged my change yesterday to mode the Drawing Converters down to System.Drawing.Common and that's using the old exclude api list argument, so that we don't forget to update it here as well.

[Anipik]

@Anipik I merged my change yesterday to mode the Drawing Converters down to System.Drawing.Common and that's using the old exclude api list argument, so that we don't forget to update it here as well.

yeah i already added that.

[Anipik]

Thanks @akoeplinger for the example. the ask seems reasonable, i can add this to the tooling.

[ericstj]

Yep, just for reference: https://docs.microsoft.com/en-us/visualstudio/code-quality/ca1065?view=vs-2019#finalizers

That said, how do you even get an instance of these types constructed (and thus run their finalizer) if all the constructors throw? N/M I see that we always run the finalizer even on partially constructed object. Interesting fact to file away.

[ericstj]

Actually, I take that back. It looks like .NETFramework will run the finalizer on a partially constructed object but .NETCore will not. Perhaps mono should be changed to match .NETCore? Still this argues for making our behavior support the running of finalizers since some of these assemblies need to work on .NETFramework, but I will correct that fact filed away to remember that this is actually something a little more subtle than it seems.

[marek-safar]

Made tracking issue for the finalizer behaviour on MonoVM -- #41272