Recommended way to handle WriteCodeFragment task for Custom Language

[RobertvanderHulst]

The default WriteCodeFragment task inside Microsoft.Build.Tasks.Core tries to retrieve the CodeDomProvider through the System.CodeDom.Compiler.CodeDomProvider.CreateProvider method.
That method, inside System.CodeDom only supports the Microsoft Languages C# and VB.
We have registered our custom language inside Machine.Config, in the right location.

 <system.codedom>
    <compilers>
      <compiler language="XSharp" extension=".prg" type="XSharp.CodeDom.XSharpCodeDomProvider,XSharpCodeDomProvider, Version=2.13.2.2, Culture=neutral, PublicKeyToken=ed555a0467764586, ProcessorArchitecture=MSIL" />
    </compilers>
  </system.codedom>

This location works for the WPF code generation, but somehow it does not work for the WriteCodeFragment task.
I checked the System.Codedom class

What is the recommended way to get WriteCodeFragment to generate the source code for a custom language:

• Write our own WriteCodeFragment task (I think FSharp does that) ?
• Another method ?

[rainersigwald]

I don't know the details of CodeDOM, but expect that writing your own task would probably be the fastest, most reliable approach.

[KalleOlaviNiemitalo]

The .NET Framework implementation of CodeDOMProvider uses configuration but the .NET implementation doesn't, so the behavior depends on the runtime that runs the WriteCodeFragment task.

For WPF, do you use MSBuild.exe or dotnet.exe?

[RobertvanderHulst]

For WPF, do you use MSBuild.exe or dotnet.exe?
At this moment we are running it with MsBuild.exe for .Net Framework.

[RobertvanderHulst]

Did nobody think of Custom Languages when creating this?
How difficult would it be to add some properties to the WriteCodeFragment task, like the AssemblyName and Classname (just like in the configuration) so we could provide this information in the targets file and would not have to create our own task?

[KalleOlaviNiemitalo]

Are you trying to write X# code when the WriteCodeFragment task is called by an existing language-agnostic target, or when it is called by an X#-specific target?

Because .NET Runtime has no GAC, the property would have to be AssemblyFile rather than AssemblyName. Then how to resolve the dependencies of the assembly…

[RobertvanderHulst]

We have our own targets file. We install a small props file in the Current\Imports\Microsoft.Common.props\ImportBefore folder that sets the LanguageTargets property so our own targets file gets included for project files that end with our extension and imports a props file from our MsBuild support folder. This props file is similar code as the C# props file and chooses for CrossTargeting.targets or CurrentVersion.targets depending on the IsCrossTargetingBuild property.
Is is not a real problem to add a WriteCodeFragment target to our own targets file and create our own implementation,.
But it feels a bit strange to duplicate the code that is already there, simply because that code is not designed to work with other languages.

I understand that it has to be an Assemblyfile.
The CodeGenerator part of our CodeDomProvider depends on System.CodeDom.Compiler.CodeGenerator namespace (ICodeGenerator,and the various types in the System.CodeDom namespace