Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

.NET Core support #18

Closed
arruw opened this issue Nov 6, 2016 · 54 comments
Closed

.NET Core support #18

arruw opened this issue Nov 6, 2016 · 54 comments
Labels
done enhancement question

Comments

@arruw
Copy link

arruw commented Nov 6, 2016

Will .NET core will be supported?
@oleg-shilo
Copy link
Owner

The short answer is 'Yes it will'.

However, it's not a CS-Script challenge but a framework one. Right now CS-Script is supported on Linux out of box. This is not because it has some Linux specific functionality but simply because Linux's default .NET implementation MONO has implemented ICodeCompiler interface. And as far as I am aware .NET Core is not there yet.

Saying that CS-Script allows pluggable compilers for the cases when the host system doesn't offer ICodeCompiler. Thus CS-Script is using this approach to bring C#6.0 functionality on Windows. Amazingly .NET 4.6, which supports C#6 syntax doesn't implement C# 6 flavor of ICodeCompiler so CS-Script is distributed with an alternative compiler (Roslyn) for this. What is even more amazing is that MONO v4.6 in fact does implement C# 6 ICodeCompiler out of box. :) Meaning that right now if you are to use cs-script on .NET Core you will need to do an additional configuration step in order to use and additional codeprovider module. Read about it here https://github.com/oleg-shilo/cs-script/wiki/C%236.0-support.

Anyway I am just waiting for Visual Studio 15 and C#7 to be out because there is a chance that MS team will finally bring the all compilers into the .NET and .NET Core distributions. Then no adjustments will be needed to run CS-Script on .NET Core and no extra user steps will be required.

If it doesn't happen I will need to prepare and start distributing a new version (C#7) of codeprovider.

@codecat
Copy link

codecat commented Dec 8, 2016

I'm also interested in .Net Core support, as I am currently in the process of porting an application using CS Script. 👍

@oleg-shilo
Copy link
Owner

I just have finished support for the issue #21

The indirect outcome of the effort is a confirmation that CS-Script works out of box on ASP.NET Core with Roslyn compiler. Though on Windows the back engine is .NET.

This is rather an encouraging sign that the engine should work on all Core runtimes. Particularly because the indirect signs (like absence of CodeDom interface ICodeCompiler) indicate that ASP.NET Core imposes it's own Core interface regardless of the back engine.

I am stressed right now with other CS-Script offsprings so it's unlikely I will be able too look at it before VS15 release. But if you don't want to wait you can give it a try. Just use CS-Script.lib NuGet package and Roslyn as a compiling engine. The details are in the issue #21

@matthiasburger
Copy link

great library for .net framework. i wanted to use it together with my web-application on .net core.
do you have any results so far? else, I'm going to test it for you on .net core this evening and send you some feedback. + if it succeeds I'm going to test it with my web-application, using entity framework and all that stuff.

@oleg-shilo
Copy link
Owner

OK, I have tested the current build against .NET Core (on Mint17). These are the findings:

  • The current NuGet package cs-script.lib v1.8.1 cannot be integrated into a .Net Core project:

Package CS-Script.lib 3.18.1 is not compatible with netcoreapp1.1 (.NETCoreApp,Version=v1.1). Package CS-Script.lib 3.18.1 supports: net (.NETFramework,Version=v0.0)

Though this can be fixed as long as CSScriptLibrary.dll is recompiled under .NET Core. In order to accomplish this the CSScriptLibrary.csproj will need to be converted into .NET Core project.json equivalent. Not sure how complicated this can be but should be possible. May be after the Christmas break :)

  • .NET Core is not ready for C# scripting yet. System.CodeDom.Compiler not implemented at all. Meaning no native scripting (CodeDom) engine. Mono scripting engine is unlikely due to the Mono team abandoning the effort long time ago. This leaves only Roslyn engine in the picture.

While .NET Core apps can host Roslyn scripting packages after some additional work around (see this post ) it is not fully supported yet. This is what is the state of this according Roslyn team less than 2 months ago from the same post:

Note however that .NET Core is not currently supported (see https://github.com/dotnet/roslyn/wiki/Scripting-API-Samples#supported-platforms) hence the experience hasn't been optimized yet. We plan to make it better once we support targeting .NET Core.

The bottom line is. CS-Script will need to be adjusted to be ready for the .NET Core. But the actual support can only happen when .NET Core team finalises the effort for Roslyn scripting.

I tagged this issue as an enhancement request. I will also keep it open so anyone who has anything to contribute to the matter can do so.

@oleg-shilo oleg-shilo mentioned this issue Dec 22, 2016
Closed
@matthiasburger
Copy link

after forking your repository yesterday, I think I got it to run (but was late yesterday) on .net core. I'll do a few more tests after workday and check it in as soon as it works. Hopefully I don't get more errors ;)

@oleg-shilo
Copy link
Owner

I am curious, did you test it against .NET Full or .NET Core?

@matthiasburger
Copy link

only against .net core. I had to change a lot of things, like you wrote e.g. project.json. I'm not sure whether it'll really work, but I'm on to it.

@oleg-shilo
Copy link
Owner

Great. Keep me posted.

I also had a quick look and one thing is for sure that all CodeDom.Native, CodeDom.Evaluator and Mono .Evaluator will need to be removed. All reflection based support as well.
I only tested .NET Core 1.0.1 and it seems to have plenty of API not implemented yet. But one definitely positive outcome is that Roslyn.scripting can be hosted successfully. Despite the Roslyn team not claiming that.

I see here an opportunity to make a CS-Script.Core preview. Not a release - neither .NET Core nor Roslyn is ready for that, only a preview. But..... Christmas is more important.

Merry Christmas to everyone.

@oleg-shilo
Copy link
Owner

I have managed to have a single complete vertical slice of Roslyn.Evaluator for .NET Core. Had to do plenty of tricks, which may or may not work with the future evolutions of .NET Core.

Started pushing the code to codebase.

We will see how it goes. If porting the rest of functionality is reasonably smooth then I cannot exclude releasing it as a technology preview effort even before .NET Core stabilizes.

@danielohirsch
Copy link

Thanks for the work Oleg. I got that code and tried to use it.. but it doesn't seem to want to automatically reference the assemblies
... Any ideas on how I can make that work?

@oleg-shilo
Copy link
Owner

Grab the latest code. I just did the commit.

The latest codebase contains the test class that covers currently implemented use cases. It will reference assemblies from the //css_ref directives placed in the script code.

Though... do not expect much from this solution. I would rather call it a technology preview effort.

The .NET Core is still in its infant state when it comes to Reflection. They implemented very little so far. There is no way to discover AppDomain assemblies and auto-reference them. There is no way to resolve name space into assembly name for further and auto-referencing. There is no way to unload already loaded assembly even by the cost of unloading AppDomain. There is no way to emit dynamic delegates. .NET Core just doesn't have these features. May be just yet...

Though while so far there are more gaps than achievements, the most useful/common scripting scenarios are already done. Have a look at Test.cs file.

@oleg-shilo
Copy link
Owner

Done: CTP Release v3.25.3.0

@oleg-shilo oleg-shilo mentioned this issue Jul 26, 2017
Closed
@graceleecat
Copy link

Hi oleg-shilo，i have read this issue from beginning to the end.
and now it's the end of 2017, does CS-Script have any new change with .NET Core 2.0? I'm very interested in it :)

@oleg-shilo
Copy link
Owner

Hy there,

I am planing to do another wave update for CTP but to be honest I did not plan to do this until the next year. I am just drowning in the work for CS-Script and WixSharp. Currently the CS-Script for Notepad++ x64 is the highest priority. And WixSharp constant PRs do add extra pressure.

Though I would thing that the CTP should work right away. Do you have some Core 2.0 specific features in mind that you would want to see in CS-Script.Code?

@graceleecat
Copy link

maybe CodeDom interface ICodeCompiler has been offered in .net core.
NuGet search: System.CodeDom, which is not included in default .net core nuget package.

@oleg-shilo
Copy link
Owner

After packaging recently the latest Rolsyn binaries for CS-Script Notepad++ plugin I noticed a package that indeed looks like CodeDom for Core. I will have a look when I have an opportunity.

Though, I am curious, what would be the advantage to have CodeDom engine integrated for .NET Core. I see why core application needs to host Roslyn-based scripting interface (CS-Script.Core CTP) but I am not so sure about CodeDom.

@seertenedos
Copy link

Any chance of posting a dotnet core version of the nugets even if tagged as pre releases? We are in the process of trying to make all our systems compatible with netstandard 2.0 especially all our libs and a number of them rely on the scripting from CS-script

@oleg-shilo
Copy link
Owner

oleg-shilo commented Jan 3, 2018 •
edited

Publishing on NuGet is simple and does not require much time to accomplish. But I am reluctant to do so until I know that what I am publishing works.

If you can test the (CS-Script.Core CTP assembly and can confirm that it works in your environment I will happily publish the pre-release NuGet package.

@seertenedos
Copy link

seertenedos commented Jan 3, 2018 via email

@oleg-shilo
Copy link
Owner

The CPT is available since May 2016: https://github.com/oleg-shilo/cs-script/tree/master/Source/.NET%20Core/CSScriptLib

You may also upgrade it and test it for netstandard 2.0. In fact you will be doing me a favor if you do so.
Once you are happy with the result I will release the package straight away.

Thank you.

@seertenedos
Copy link

seertenedos commented Jan 4, 2018 via email

@gpaluk
Copy link

gpaluk commented Jan 20, 2018

I've been following and waiting for this also. 👍 Is this package now available on NuGet?

@oleg-shilo
Copy link
Owner

No this package is only available from GitHub: https://github.com/oleg-shilo/cs-script/tree/master/Source/.NET%20Core/CSScriptLib.

Though the good news is that I finally finished development of the the long overdue Notepad++ CS-Script plugin, which was holding me lately. Thus I will be back on the main CS-Script project in just a few days and... getting .NET Core support out of Beta is the very next dev task to do.

@ghost
Copy link

ghost commented Jan 30, 2018

As you already posted some releases for .NET Core. I am currently about to implement that. Actually it works, unfortunately Remote Loading is not supported (yet?), but I got another problem. I want to be able to provide Newtonsoft.Json library to the scripts but I cant figure out how to do that. Could you help me?

@oleg-shilo
Copy link
Owner

Bingo!!!

Yes this is exactly what the very latest RC does in ReferenceDomainAssemblies:

class RoslynEvaluator
{
    public IEvaluator ReferenceDomainAssemblies(DomainAssemblies assemblies = DomainAssemblies.AllStaticNonGAC)
    {
        foreach (var name in Assembly.GetCallingAssembly().GetReferencedAssemblies())
        {
            var asm = Assembly.Load(name); // the asm is already loaded by the host anyway
            this.ReferenceAssembly(asm);
        }
    }
...

Though GetReferencedAssemblies doe not return NuGet packages :(

Too bad .NET Core does not have AssemblyLoadContext.Default.GetAssemblies(). Please share your solution if it is better than the one above.

@ghost
Copy link

ghost commented Jan 31, 2018 •
edited by ghost

I´ve done it using Reflection:

IEvaluator ReferenceDomainAssemblies()
        {
            IEvaluator evaluator = CSScript.Evaluator;
            foreach(var asm in Assembly.GetExecutingAssembly().GetTypes().Select(t => t.Assembly).Distinct())
            {
                evaluator = evaluator.ReferenceAssembly(asm);
            }
            return evaluator;
        }

That's how it worked for me. I actually didnt use the Distinct() before so that part is pseudocode because I am currently not at my desktop, but it should work.

Edit: No this is not a solution! I just tested a little around and printed the GetTypes() it is not doing what expected. The reason it worked for my script is because of nested Types. But GetTypes() will fail when there are no nested types.

Edit²: I actually just tested GetReferencedAssemblies() when calling from this from GetExecutingAssembly() and it printed Newtonsoft.Json which I got from NuGet. So it is working?!

@oleg-shilo
Copy link
Owner

Hmm, strange.
First of all I am not sure about your take on getting domain assemblies. Just looking at your solution and I see that it will always return a single assembly:

var asms = Assembly.GetExecutingAssembly().GetTypes().Select(t => t.Assembly).Distinct().ToArray();

You are getting an assembly (executing assembly), getting all the types implemented in this single assembly and after that you are collecting from every type its parent assembly. Which is the very same assembly you have started with.

I tested your code and the test confirmed - it is always a single assembly.

As for "Newtonsoft.Json from NuGet" I checked my code again and indeed it returns Newtonsoft.Json but only if it is already loaded (referenced statically) but not if the host app loads it dynamically (as in my case). Thus it doesn't do the same job as the old AppDoman.Current.GetAssemblies(). Ehich is unfortunate...

@seertenedos
Copy link

seertenedos commented Feb 28, 2018 •
edited

Guys has anyone got CS-Script.Core V1.0.0.2 to work in dotnet 4.6.1? It is netstandard2.0 so it should work but i am getting the below error. We need this as we are trying to slowly port our apps from 4.6.1 to Core2 but are aiming to have them run in both short term plus we have a common lib to do all our scripting stuff used in multi apps.

System.TypeLoadException: Could not load type 'System.Runtime.Loader.AssemblyLoadContext' from assembly 'System.Runtime.Loader, Version=4.0.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'.
   at CSScriptLib.RoslynEvaluator.<>c.<GetReferencedAssemblies>b__19_0(PortableExecutableReference r)
   at System.Linq.Enumerable.WhereSelectEnumerableIterator`2.MoveNext()
   at System.Linq.Buffer`1..ctor(IEnumerable`1 source)
   at System.Linq.Enumerable.ToArray[TSource](IEnumerable`1 source)
   at CSScriptLib.RoslynEvaluator.GetReferencedAssemblies()
   at CSScriptLib.RoslynEvaluator.Clone(Boolean copyRefAssemblies)
   at CSScriptLib.CSScript.get_RoslynEvaluator()
   at CSScriptLib.CSScript.get_Evaluator()
   at xxxxx.GetBusinessClassScript[TInstance](String classAsString, Object[] constructorArgs) in xxxxx\OpalScriptManager.cs:line 180
   at xxxxx.GetBusinessFunction[TInstance](String functionScriptBody, String template) in xxxxx\OpalScriptManager.cs:line 327
   at xxxxxTest.Comments_Should_Do_Nothing() in xxxxx\BusinessContentFunctionTest.cs:line 46

tried both
TInstance instance = CSScript.Evaluator.ReferenceDomainAssemblies()
.LoadCode(classAsString, constructorArgs);
and
CSScript.Evaluator.CreateDelegate( xxx from the given sample

@seertenedos
Copy link

Also on the loading of Assemblies i tried the line below since it is part of netstandard2.0
System.AppDomain.CurrentDomain.GetAssemblies()

Sadly it errors when adding them.
System.Exception: Current version of Microsoft.CodeAnalysis.Scripting.dll doesn't support referencing assemblies which are not loaded from the file location.
at CSScriptLib.RoslynEvaluator.ReferenceAssembly(Assembly assembly)

@seertenedos
Copy link

seertenedos commented Feb 28, 2018 •
edited by oleg-shilo

Further update for loading all assembly's in netstandard2.0 on coreapp2 the following works for me

        private IEvaluator ReferenceAppDomainAssemblies()
        {
            IEvaluator evaluator = CSScript.Evaluator;
            foreach (var asm in System.AppDomain.CurrentDomain.GetAssemblies().Distinct())
            {
                if (string.IsNullOrEmpty(asm.Location()))
                {
                    continue;//we need a location
                }
                evaluator = evaluator.ReferenceAssembly(asm);
            }
            return evaluator;
        }

@seertenedos
Copy link

Issues i mentioned above are resolved in pull request #106

@Salgat
Copy link

Salgat commented Mar 9, 2018

@seertenedos Your suggestion worked great! The only thing I had to change was also add a check for asm.IsDynamic == false (it would throw an exception for me on dynamic assemblies).

@seertenedos
Copy link

seertenedos commented Mar 9, 2018 via email

@Methuselah96
Copy link

Is the latest pre-release going to be released as a stable build soon? There are bugs in the latest build that are fixed in the latest pre-release that would be helpful to have in the latest stable build.

@oleg-shilo
Copy link
Owner

Yes it is going to be released withing a few days. To make it in sync with then new VSCode extension release.

Though if I am not mistaken the pre-release changes did not affect .NET Core edition. Can you please name the fixes you are referring to so i can verify if they are already or coming into the next stable release.

@Methuselah96
Copy link

The latest stable build version 1.0.0.2 was not working with using statements in the code being loaded.

@oleg-shilo
Copy link
Owner

I have checked and indeed support for resolving using is not in there. Even for the pre-release. This is simply because the usings were resolved into GAC assemblies and .NET Core simply does not have GAC.

However your post prompted me to look for an alternative approach. Thus I have updated the solution with the resolving using against assemblies in the donet\shared directory, which is in many ways plays the same role as GAC except it one cannot add custom assemblies ther. Any custom assemblies needs to be added and resolved as NuGet packeges (already supported by cs-script.core).

This is the solution:

public static string[] FindGlobalAssembly(string namespaceStr)
{
    // .NET Core does not offer any asm discovery mechanism
    // Thus just check for the candidates in the "global shared" folder

    string shared_dir = Path.GetDirectoryName("".GetType().Assembly.Location);
    return FindLocalAssembly(namespaceStr, shared_dir);
}

The stable release is a couple days away.

@seertenedos
Copy link

seertenedos commented Apr 27, 2018 via email

@Methuselah96
Copy link

@seertenedos That is indeed to what I was referring.

@oleg-shilo
Copy link
Owner

Done.
The latest release can be found here: https://github.com/oleg-shilo/cs-script/releases/tag/v3.28.4.0

Or you can download it as NuGet packages.

@Methuselah96
Copy link

Methuselah96 commented Apr 28, 2018 •
edited

@oleg-shilo I don't see the latest CS-Script.Core (v1.0.1.0) released as a NuGet package. https://www.nuget.org/packages/CS-Script.Core

@rconde01
Copy link

Can you use cscs with dotnetcore? If so...how?

@oleg-shilo
Copy link
Owner

The latest CS-Script.Core class library for hosting the script engine is available at NuGet:
https://www.nuget.org/packages/CS-Script.Core

However the standalone engine executable (cscs.exe) for .NET Core is currently under active development.

The recent MS announcement of the imminent arrival of .NET Core 3 with the support for desktop applications has shifted the intensity of the cscs.exe rework one gear up. The working "almost-aplha" is already in codebase. And the preview release is a matter of a few weeks.

Though there is a one less exciting news... Early tests reviled that MS has not ported Roslyn compiler server (VBCSCompiler.exe) to .NET Core. Meaning that the initial script compilation/execution all attract a significant startup delay (1-3 seconds). However I expect it to be fixed when .NET Core 3 is released.

Though only time will tell :)

@rconde01
Copy link

Thanks for the update...although 2019 doesn't feel too imminent :)

@oleg-shilo
Copy link
Owner

:) I know, 'inevitable' would be a better choice.
I just couldn't resit. Wishful thinking...

@agilmore30
Copy link

Hi

Microsoft announced .NET Core 3 Preview 1 on December 4.

You mentioned that there is currently a 1-3 second overhead with the Roslyn compiler. I'm experiencing that, which is a bit of a killer.

I'm wondering if this time delay issue will go away with .NET Core 3 ?

I'm loading code from a string. I appear to get the delay for every invocation.

var code = @"a class ...";
var script = CSScript.Evaluator.LoadCode< ICScript>(code);

Can I do something different to avoid the delay, e.g. load from a file ?

@agilmore30
Copy link

Actually my assertion that the 3 second overhead occurs on every invocation was wrong. My method for timing was invalid. I only get the overhead the first time I call a CSScript.Evaluator.LoadCode method, even across different instances of the Evaluator.

@oleg-shilo
Copy link
Owner

oleg-shilo commented Jan 31, 2019 •
edited

Correct.
The overhead is not even functional from CS-Script point of view. Simply it takes time for CLR to load Roslyn assemblies and then to initialize all their static members. After that it is actually pretty fast.

@danielohirsch
Copy link

danielohirsch commented Jan 31, 2019 via email

@danielohirsch
Copy link

danielohirsch commented Jan 31, 2019 via email

@agilmore30
Copy link

@oleg-shilo @danielohirsch Thanks for your help guys. Yep, I've found its pretty fast after first execution. Precompiling is a good idea, I'll consider that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
done enhancement question
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests