SyntaxEditor as Roslyn script textbox

Hi Nick,

What you are doing is correct since you do need to wrap the "expression" portion being edited with a legitimate C# type/member, or else IntelliPrompt won't work. 

I'd probably suggest adding this attribute on both your "_class_" and "_main_".  We watch for this attribute and prevent types/members with it from showing in the IntelliPrompt completion list:

[System.ComponentModel.EditorBrowsable(System.ComponentModel.EditorBrowsableState.Never)]

Excellent! 

thanks for the quick response.

Hello Actipro!

I am working on a similar project, where I am using Roslyn to execute scripts written in an Actipro syntax editor, and was wondering if there was a way to allow top level function definition in the settings of the language rather than the wrapper main method. I would like my users to be able to define top level functions in one script and reference them freely in another, which Roslyn supports. I am having trouble configuring the SyntaxEditor to work together with this feature. The wrapper class method above does not allow functions or new classes to be defined within the main method, which I would love to have in my product. 

Thanks for the support!

Hi Matthew,

The way SyntaxEditor works is that each document can wrap its content with an optional header/footer text.  All that is merged together when sending the unified code out for parsing.  You can see this in action in the "Code Fragments" QuickStart.

I'm not sure of your setup, but you can put whatever you want in the header.  For instance, you can do namespace imports (usings) there to make other classes/members available.  As long as this document is associated with a particular IProjectAssembly, any other code within that same IProjectAssembly or assembly references from that IProjectAssembly will be accessible to be imported with usings.

If you have any further questions, please post some details and code snippets that show what you're trying to do, and what you currently see not working as intended.  Thanks!

using System.IO;

public string example() {
     return "My string";
}

File.WriteAllText("My path", example());
        

Roslyn uses a version of C# that is loose and does not require methods to be defined within a class, but they can be if the writer chooses to.  All of this code is written, compiled, and executed at runtime. The code snippet above shows an example of the text that I would like the SyntaxEditor to parse correctly. Using the solution described above, of placing the text in a dummy main method, the SyntaxEditor cannot define methods, classes, or add usings within its text field because its parsing code as if it was in a main method. I am wondering if there's a way to configure my C# .NET Language add-in to allow top level definition of functions, classes, and retain the ability to add usings. Sorry for the confusing phrasing earlier and I am now realizing that a new thread might've been a better place for this question.

Hi Matthew,

Ahh, thank you.  I believe that is C# 9.0's top-level statements feature (https://docs.microsoft.com/en-us/dotnet/csharp/whats-new/csharp-9#top-level-statements).  Our .NET Languages Add-on doesn't currently support that and needs updates to support some newer constructs like top-level statements. 

Working towards supporting some of the newer C# features is a higher priority item on the SyntaxEditor TODO list.  I'll log your request with that TODO item.

I would like +1 for the C# scripting style scenario. We seem to have two problems so far:

* top-level statements, as found in C# 9.0.

* extra directives that can appear in .csx script files - the are lines that start with #r, #load or #! , and are understood by VSCode and some other tools like 'dotnet script' as part of the .csx files. At the moment these are indicated as errors by the ActiPro SyntaxEditor.

Three articles with examples and context for this are:

* https://docs.microsoft.com/en-us/archive/msdn-magazine/2016/january/essential-net-csharp-scripting

* https://www.codeproject.com/Articles/5273898/Code-Generation-using-Csharp-Scripts-CSX-Scripts-i

* https://www.hanselman.com/blog/c-and-net-core-scripting-with-the-dotnetscript-global-tool

I understand we'd have to deal at a higher level with the #r directive to figure out which other references or NuGet packages to add to the context. I'm not sure how to think about #load yet - this brings in another file into the context, but is also an extension point in the Roslyn scripting that allows custom loading behaviour. Finally, lines with the shebang #! should just be ignored as a script comment.

As an update to this thread, we expect to launch C# 9.0 support, including top-level statements, in v24.1.