Investigate running on full desktop CLR

[filipw]

Mono/. NET 4.6

[acormier]

I tried loading the Dotnet.Script.Core lib from a .Net Framework app instead of using Dotnet.Script CLI app.

In ScriptCompiler.cs there's the line: var inheritedAssemblyNames = DependencyContext.Default.GetRuntimeAssemblyNames(runtimeId) but DependencyContext.Default returns null. It seems that that code is to compensate for the lack of AppDomains in .netcore but since the Dotnet.Script.Core assembly targets .Net Standard 2.0 I thought it would just work. What am I missing? Thanks

[acormier]

I just now saw the discussion about DependencyContext.Default returning null here: #224

[filipw]

I think you are on some really old version, because that code doesn't exist for quite a while now.
That said, the current version of Dotnet.Script.Core would not work on desktop framework for at least two reasons:

1. there is code which tries to determine a current runtime identifier and if it's not netcoreapXXX it fails
2. the default references (such as System.dll, System.Core.dll and so on) are not implicitly added. That is because we pick them up from project.assets.json. This works fine on .NET Core, but on Desktop .NET the GAC references would be skipped and would have to be added manually

I am not sure if these are all the roadblocks, but these are definitely there from the top of my head.
There is no reason why these couldn't be fixed though, in fact this should be fairly uncomplicated to do so if this is something you feel like you'd need, then we could fix that.

[acormier]

I had 0.21.0 checked out which is 10 days old. I guess that is really old :-)

Our app hosts the .net framework and supporting C# scripting with dotnet-script is what I'm trying to do. I can imagine that others would benefit from using Dotnet.Script.Core from Desktop apps

[filipw]

I guess that is really old :-)

😄