qwertie
commented
3 years ago I wasn't aware of this tool before, but I just downloaded it and gave its interactive mode dotnet script a try. Not surprisingly, I got this result:
> namespace X {}
(1,1): error CS7021: Cannot declare namespace in script codeNext I tried writing a full script with a namespace:
#!/usr/bin/env dotnet-script
namespace X {
public class Y {
public static void Main(string[] a) {
Console.WriteLine("Hello, world!");
}
}
}No luck:
C:\Temp>dotnet-script test.csx
C:\Temp\test.csx(4,24): warning CS7022: The entry point of the program is global script code; ignoring 'Y.Main(string[])' entry point.
C:\Temp\test.csx(2,1): error CS7021: Cannot declare namespace in script code
...There are a couple of key reasons I used interactive mode. One is that the input comes as a series of separate invocations of the compileTime and precompute macros. In particular, precompute might be used dozens/hundreds of times in a single file, and I assumed C# interactive would be more efficient in this scenario than, say, compiling a new assembly for every expression evaluated. In any case, you can define things in one block and use them in a later block (the reverse doesn't work - compileTime { new X(); } compileTime { class X {} } produces an error) which made the interactive mode a good fit for LeMP.
A second reason is that C# interactive allows mixing of instructions and declarations (e.g. Console.WriteLine("Hi"); class X { } is valid in csi and not normal C#), which made it super easy to use because I did not need to write any code to transform code like that into normal non-interactive C#. Perhaps this second factor explains why dotnet-script doesn't support namespaces in csx files.
I doubt I will find the time to do this myself in the immediate future, but if you really need features like namespaces, you could write a macro that would compile a set of source files (.cs and even .ecs) into an assembly using Roslyn or csc or msbuild, and then add that assembly as a reference to the current ecs file. I imagine a macro like
// Line 7 of Example.ecs:
compileTimeReference("SourceFile1.cs", "SourceFile2.ecs",
"Reference1.dll", "Reference2.dll", { namespace X { class Y {} } });This, of course, would allow SourceFile1.cs and SourceFile2.ecs to contain namespaces and extension methods, and it wouldn't be hard to also support inline blocks of code that contain namespaces and extension methods, as shown.
compileTimeReference("Reference.dll"); should probably be equivalent to compileTime { ##reference("Reference.dll"); }, but if you specify source files or source code, it should compile a DLL. For example, the macro could set up a Roslyn CSharpCompilation object, compile a DLL called C:...\Temp\Example.cs.Line7.dll and then replace itself with compileTime { ##reference("C:\...\Temp\Example.cs.Line7.dll"); } to reference the DLL.
dadhi
Knowing that the current
compileTimedirective is based on Roslyn scripting (C# interactive - CSI), I have started to look into other scripting limitations.What I found is a modern scripting alternative -
dotnet-scriptCLI tool https://github.com/filipw/dotnet-script. Here is the detailed article of the C# scripting tools comparison https://itnext.io/hitchhikers-guide-to-the-c-scripting-13e45f753af9As for
dotnet-script, it is cross-platform, works with .NET Core v3.1+, allows referencing of NuGet packages, allows packing, and referencing other scripts from the NuGet.It also seems to support more broad C# sub-set including C# 8, for comparison, CSI even does not support
using static, not talking about extension methods.Additionally, there are goodies to access the script path:
So my question, is it possible to consider dotnet-script for the next version LeMP templating?