-
Notifications
You must be signed in to change notification settings - Fork 235
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.
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
.NET Core support #18
Comments
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 Saying that CS-Script allows pluggable compilers for the cases when the host system doesn't offer 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. |
I'm also interested in .Net Core support, as I am currently in the process of porting an application using CS Script. 👍 |
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 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 |
great library for .net framework. i wanted to use it together with my web-application on .net core. |
OK, I have tested the current build against .NET Core (on Mint17). These are the findings:
Though this can be fixed as long as CSScriptLibrary.dll is recompiled under .NET Core. In order to accomplish this the
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:
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. |
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 ;) |
I am curious, did you test it against .NET Full or .NET Core? |
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. |
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 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. |
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. |
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 |
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 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 |
Done: CTP Release v3.25.3.0 |
Hi oleg-shilo,i have read this issue from beginning to the end. |
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? |
maybe CodeDom interface ICodeCompiler has been offered in .net core. |
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. |
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 |
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. |
More than happy to test once i know where to find it. It will take a few
days as i am in the middle of converting 20 projects and this is just
affects 3 of them.
…On 4 Jan. 2018 10:41 am, "Oleg Shilo" ***@***.***> wrote:
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 (S-Script.Core CTP assembly and can confirm that it
works in your environment I will happily publish the pre-release NuGet
package.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#18 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAYecZHx76_op0MoMSe6vsqzraozUXi0ks5tHBAMgaJpZM4KqoI1>
.
|
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. Thank you. |
Oh i thought it was already a nuget just different source like myget or
different name. That will take a bit longer. Will try if i get a chance
after current work.
…On 4 Jan. 2018 10:58 am, "Oleg Shilo" ***@***.***> wrote:
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.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#18 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAYecTipdH2_EoZkEkctepfc8-nEvrEDks5tHBQqgaJpZM4KqoI1>
.
|
I've been following and waiting for this also. 👍 Is this package now available on NuGet? |
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. |
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? |
Bingo!!! Yes this is exactly what the very latest RC does in 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 |
I´ve done it using Reflection:
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?! |
Hmm, strange. 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 " |
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.
tried both |
Also on the loading of Assemblies i tried the line below since it is part of netstandard2.0 Sadly it errors when adding them. |
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;
} |
Issues i mentioned above are resolved in pull request #106 |
@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). |
If you turn on preview releases then there is 1.0.3-hotfix release that had
the changes I mentioned plus a few others I found I needed for supporting
netstandard 2 versio on dotnet 4.6.1. be interested to know if that fixes
your issues as well.
…On 9 Mar. 2018 5:00 pm, "Austin Salgat" ***@***.***> wrote:
@seertenedos <https://github.com/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).
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#18 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAYecUNRcdOwU_Gk8O8EQpF6Jea0Fd-aks5tchp0gaJpZM4KqoI1>
.
|
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. |
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. |
The latest stable build version |
I have checked and indeed support for resolving However your post prompted me to look for an alternative approach. Thus I have updated the solution with the resolving 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. |
My fix in pre-release also had a fix to load all DLL from app domain on
dotnet core that came with netstandard 2. That could be what was being
referred to as well.
The pre release has not made it to our production environment but has being
running stable in our other enviroments so far.
…On Fri, 27 Apr. 2018, 1:26 pm Oleg Shilo, ***@***.***> wrote:
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.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#18 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAYecYqg566fjnIDIp5d5BBHn9mGZydtks5tso_igaJpZM4KqoI1>
.
|
@seertenedos That is indeed to what I was referring. |
Done. Or you can download it as NuGet packages. |
@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 |
Can you use cscs with dotnetcore? If so...how? |
The latest CS-Script.Core class library for hosting the script engine is available at NuGet: 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 ( Though only time will tell :) |
Thanks for the update...although 2019 doesn't feel too imminent :) |
:) I know, 'inevitable' would be a better choice. |
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 ..."; Can I do something different to avoid the delay, e.g. load from a file ? |
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. |
Correct. |
I would orecompile your scripts when the app loads and keep them in a keyed
library to call and execute when you want/need.
…On 2019. Jan 31., Thu at PM 12:23, Oleg Shilo ***@***.***> wrote:
Correct.
The overhead is not even functional from CS-Script point of view. Simply
it takes time for CLR for the Roslyn assemblies to load and then to
initialize all Roslyn static members. After that it is actually pretty fast.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#18 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AbKpwLVX4w_LBOUClWsvSVk-zuaFZGx7ks5vItJOgaJpZM4KqoI1>
.
|
*precompile
On 2019. Jan 31., Thu at PM 4:14, Dan Hirsch <daniel.hirsch@gmail.com>
wrote:
… I would orecompile your scripts when the app loads and keep them in a
keyed library to call and execute when you want/need.
On 2019. Jan 31., Thu at PM 12:23, Oleg Shilo ***@***.***>
wrote:
> Correct.
> The overhead is not even functional from CS-Script point of view. Simply
> it takes time for CLR for the Roslyn assemblies to load and then to
> initialize all Roslyn static members. After that it is actually pretty fast.
>
> —
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub
> <#18 (comment)>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AbKpwLVX4w_LBOUClWsvSVk-zuaFZGx7ks5vItJOgaJpZM4KqoI1>
> .
>
|
@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. |
Will .NET core will be supported?
The text was updated successfully, but these errors were encountered: