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.

Could you confirm whether top-level statements was added to 24.1 or later. I'm trying to use the SyntaxEditor (25.1) with this style of code but the intelliprompt doesn't list the available items & i see red underline errors.

I'm testing with the same sample code posted above using the samples project:

using System.IO;

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

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

Is there a property that needs to be enabled to support this? I couldn't find anything specific in the documentation.

Hi Rob,

Yes, top-level statements are supported. However note that a public modifier is not valid in that context.  If you remove the "public" keyword, it should show without errors.  Without the "public" keyword, the method declaration becomes a valid local function declaration.

Thank you for clarifying this.

I've found that the order of the methods in the script is important too. The completion list does not show methods or fields that are defined after the point where they are called, e.g. the call to MethodA() shows in the list, but the call to MethodB() doesn't.

string MethodA()
{
	return "MethodA" + MethodB();
}

string MethodB()
{
	return "MethodB";
}

Console.WriteLine(MethodA());

Also, definition of auto-properties doesn't really work, neither does readonly fields:

readonly int Field2;
int Property1 {get; set;}

Is there a way to adjust the code completion & error highlighting components to support this?

Hi Rob,

C# top-level statements can effectively hold whatever is in a normal method body.  What happens behind the scenes is that a stub "Program" class and "Main" method declaration are generated to hold the top-level statements.  You can see this in the AST in our Document Outline when editing a document that has top-level statements.

Since top-level statements are just statements, things like public methods, readonly fields, property declarations, etc. are not valid.  Those kinds of constructs are only valid at the class level. 

If you are wanting to support those kinds of things, then you do not want top-level statements.  You could use our header/footer text features of the document to have a wrapper class declaration if that's what you need.  Then the contents of the editor that are editable would be at a class level.

For the local function order of declaration (MethodA and MethodB in your snippet are local functions, not methods), that does appear to be an issue in our resolver where it should search forward to try and locate the names.  Thanks for reporting it.  We will look into resolving that for the next release.