SyntaxEditor as Roslyn script textbox

SyntaxEditor .NET Languages Add-on for WPF Forum

Posted 1 year ago by Nick Witvrouwen
Version: 19.1.0683
Avatar

I am trying to use the SyntaxEditor + c# addon as a Roslyn script textbox.

To accomplish this, I try to wrap the expression body in a dummy footer/header that is ignored by the Roslyn script compiler

Document.SetHeaderAndFooterText(
@"using System;class _class_{static void _main_(){return ",
@"}}");

This seems to work, but does feel like a nasty hack.

Is there any other better way of getting the same result?

A problem with my approach is that the dummy "_class_" and "_main_" identifiers show up in the intellisense completion box.

Is there a way to ignore these entries?

Comments (7)

Answer - Posted 1 year ago by Actipro Software Support - Cleveland, OH, USA
Avatar

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)]


Actipro Software Support

Posted 1 year ago by Nick Witvrouwen
Avatar

Excellent! 

thanks for the quick response.

The latest build of this product (v2020.1.1) was released 2 months ago, which was before the next post in this thread.
Posted 1 month ago by Matthew Salomon
Avatar

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!

Posted 1 month ago by Actipro Software Support - Cleveland, OH, USA
Avatar

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!


Actipro Software Support

Posted 1 month ago by Matthew Salomon
Avatar
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.

Posted 1 month ago by Actipro Software Support - Cleveland, OH, USA
Avatar

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.


Actipro Software Support

Posted 8 days ago by Govert van Drimmelen
Avatar

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.

Add Comment

Please log in to a validated account to post comments.