Add System.Text.Json and System.Memory as builtin implicit references

[am11]

To use (even a simplest) JSON serialization in inline tasks (UsingTask), today we are expected to specify two additional references:

  <UsingTask
    TaskName="JsonShenanigans"
    TaskFactory="RoslynCodeTaskFactory"
    AssemblyName="Microsoft.Build.Tasks.Core">
    <Task>
      <Reference Include="System.Text.Json"/>
      <Reference Include="System.Memory"/>
      <Using ...

It would be nice to not require specifying these two references by promoting S.T.J assembly as a first-class citizen of RoslynCodeTaskFactory-based UsingTask.

ps - perhaps the entire set of current Microsoft.NETCore.App / Shared Framework references can be available implicitly in this scope if it does not violate any design principle? Requiring user to only specify <Using Namespace=".." /> to use anything out of SFX.

[rainersigwald]

It would be nice to not require specifying these two references by promoting S.T.J assembly as a first-class citizen of RoslynCodeTaskFactory-based UsingTask.

It makes sense to me that we could provide "all the stuff we ourselves depend on" as easy references in inline tasks, which would include these.

ps - perhaps the entire set of current Microsoft.NETCore.App / Shared Framework references can be available implicitly in this scope if it does not violate any design principle? Requiring user to only specify <Using Namespace=".." /> to use anything out of SFX.

This I'm less sure of, because it would mismatch between the .NET SDK MSBuild (on .NET 8+) and the VS MSBuild (on .NET 4.8), making it harder to ship cross-platform works-everywhere inline tasks (they'd need explicit references on Framework but not on Core).

[am11]

This I'm less sure of, because it would mismatch between the .NET SDK MSBuild (on .NET 8+) and the VS MSBuild (on .NET 4.8), making it harder to ship cross-platform works-everywhere inline tasks (they'd need explicit references on Framework but not on Core).

If we have the ability to restrict it for NETCoreApp, that might be good enough and future-proof. i.e. whichever NETCoreApp is being used by current SDK process running the MSBuild, inline-tasks can access its assemblies. I am not familiar with the internals of RoslynCodeTaskFactory, and thought it to be only compatible with .NET Core. :)

[rainersigwald]

Team triage: we'd be willing to add STJ and S.Memory to the default list, but we haven't seen much demand for this so we're not planning to do the work in the near term.

[newmasterSG]

@rainersigwald Hi, can take this task?

[newmasterSG]

Hi, while I was working on resolving this issue, I faced with problem of building project. I had added STJ and Memory to defaultNamespaces, but I got error which means need to add STJ assembly to compiler process, also I changed Microsoft.Build.Utilities.Core.dll at folder dotnet/sdk but got another problem, which is not related to this issue. After I researched at google and at code, I understood that when you tried to run dotnet build or msbuild it caused failure at building task because the assembly or library must also be present at netstandart for cross-platform.

[newmasterSG]

Can you tell me what would be the best thing to do here?