Consider using #line directives in RoslynCodeTaskFactory

[rainersigwald]

The CodeTaskFactory implementations can work by being given a snippet of C#, which is assembled into a full class definition and fed to the compiler. But errors in C# syntax are reported in a convoluted way. Given:

<Project>
  <UsingTask
    TaskName="HelloWorld"
    TaskFactory="RoslynCodeTaskFactory"
    AssemblyFile="$(MSBuildToolsPath)\Microsoft.Build.Tasks.Core.dll" >
    <ParameterGroup />
    <Task>
      <Code Type="Fragment" Language="cs">
<![CDATA[
C# syntax error
]]>
      </Code>
    </Task>
  </UsingTask>

  <Target Name="Go">
    <HelloWorld />
  </Target>
</Project>

you get

❯ msbuild .\foo.proj
MSBuild version 17.8.0-preview-23423-02+1d8146d3d for .NET Framework
  foo failed with errors (0.1s)
    C:\Users\raines\AppData\Local\Temp\MSBuildTempraines\tmp36947aa3db784f3b87b3ca8bfd166d69.tmp(37,2): error CS1040: Preprocessor directives must appear as the first non-whitespace character on a line
    C:\Users\raines\AppData\Local\Temp\MSBuildTempraines\tmp36947aa3db784f3b87b3ca8bfd166d69.tmp(37,2): error CS1002: ; expected
    S:\play\codetaskfactory-errors\foo.proj(17,5): error : The source file for this compilation can be found at: "C:\Users\raines\AppData\Local\Temp\MSBuildTempraines\tmp36947aa3db784f3b87b3ca8bfd166d69.tmp"
    S:\play\codetaskfactory-errors\foo.proj(17,5): error MSB4036: The "HelloWorld" task was not found. Check the following: 1.) The name of the task in the project file is the same as the name of the task class. 2.) The task class is "public" and implements the Microsoft.Build.Framework.ITask interface. 3.) The task is correctly declared with <UsingTask> in the project file, or in the *.tasks files located in the "C:\Program Files\Microsoft Visual Studio\2022\Preview\MSBuild\Current\Bin\amd64" directory.

Build failed with errors in 0.2s

This makes sense given the details of the system, but is hard to chase back to the original error.

By using the #line directive we could change the line reported by the compilation to be the line in the project file (or included .cs fragment) instead, which would be clearer.

[rainersigwald]

(this arose from a conversation with @MichalPavlik about the inline-task UX)

[KalleOlaviNiemitalo]

But consider this kind of mistake (using Type="Method" when Type="Class" is needed):

<Project>
  <UsingTask
    TaskName="HelloWorld"
    TaskFactory="RoslynCodeTaskFactory"
    AssemblyFile="$(MSBuildToolsPath)\Microsoft.Build.Tasks.Core.dll" >
    <ParameterGroup />
    <Task>
      <Code Type="Method" Language="cs">
<![CDATA[
public class HelloWorld : Microsoft.Build.Framework.ITask
{
    public Microsoft.Build.Framework.IBuildEngine BuildEngine { get; set; }
    public Microsoft.Build.Framework.ITaskHost HostObject { get; set; }
    public bool Execute() => true;
}
]]>
      </Code>
    </Task>
  </UsingTask>

  <Target Name="Go">
    <HelloWorld />
  </Target>
</Project>

Here, "error CS0542: 'HelloWorld': member names cannot be the same as their enclosing type" becomes more difficult to understand if the user cannot see the context in the generated C# file.
I hope "The source file for this compilation can be found at" would still be shown.

[danmoseley]

Just curious, why do we need to write the code to a temp file for RoslynCodeTaskFactory? I know that was inevitable as part of how Code DOM worked ,but Roslyn can accept memory streams surely.