In terms of an abstraction over all the APIs that Roslyn provides, a core feature is 'customisation' of code output based on various factors.
For example, we can specify compiler constants in compiler constants, represented by the $(DefineConstants) variable array that is passed to the Roslyn compiler by the MSBuild project system.
We can then use these constants like so:
#ifdef MY_CONSTANT_DEFINED
Console::Write("We have cross-language conditional compilation");
#endifHowever, the abstracted extension of this is resolving actual values defined at compile time in the code.
For example, I could do this:
<ItemGroup>
<Constant Include="MyString">
<String>look at my awesome compiler constant!</String>
</Constant>
<Constant Include="MyInt32">
<Int32>200</Int32>
</Constant>
<Constant Include="MyProperty">
<String>$(TargetFramework)</String>
</ItemGroup>The example above is pretty advanced, but it's a demo of what this compiler feature could be.
This would then generate the static, compiler time constant code:
namespace {{ RootNamespace }};
public static partial class Constants
{
public const string MyString = "look at my awesome compiler constant!";
public const int MyInt32 = 200;
public const string MyProperty = "netstandard2.0";
}That would be significantly useful because then we could define runtime code based on compiler evaluations, and get fully defined, managed MSBuild objects from them, without reflection to get dynamic assembly metadata.
It's the extension of $(DefineConstants) but more than just boolean compilation conditions.
A potential use case for this might be in source generation, because then we could get extra information about the assembly, such as the language, at runtime.
In terms of an abstraction over all the APIs that Roslyn provides, a core feature is 'customisation' of code output based on various factors.
For example, we can specify compiler constants in compiler constants, represented by the
$(DefineConstants)variable array that is passed to the Roslyn compiler by the MSBuild project system.We can then use these constants like so:
However, the abstracted extension of this is resolving actual values defined at compile time in the code.
For example, I could do this:
The example above is pretty advanced, but it's a demo of what this compiler feature could be.
This would then generate the static, compiler time constant code:
That would be significantly useful because then we could define runtime code based on compiler evaluations, and get fully defined, managed MSBuild objects from them, without reflection to get dynamic assembly metadata.
It's the extension of
$(DefineConstants)but more than just boolean compilation conditions.A potential use case for this might be in source generation, because then we could get extra information about the assembly, such as the language, at runtime.