Skip to content

feature/netcoreapp2.1 #261

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

Merged
merged 16 commits into from
Apr 21, 2018
Merged

feature/netcoreapp2.1 #261

merged 16 commits into from
Apr 21, 2018

Conversation

seesharper
Copy link
Collaborator

This PR adds support for cross compiling dotnet-script using netcoreapp2.0 and netcoreapp2.1
The motivation for this is to fix #258 that requires global tools to be compiled for at least netcoreapp2.1.

Please refer to this issue for form information https://github.com/dotnet/cli/issues/9073

In the process of adding support for netcoreapp2.1, it was important that existing scripts that contained the #! "netcoreapp2.0" pragma should continue to work.

This resulted in a deep dive into how we add assemblies (metadatareferences) for a given script.

We used to add a couple of "inherited" assembly references from the host (dotnet-script) and then load the rest from the dependency context inferred from the script.

The initial hypothesis was that we needed to get rid of all inherited assembly references since there would be a possible mismatch between the host running as netcoreapp2.1 and the script dependencies being resolved in the context of a netcoreapp2.0 application.

As it turns out when compiling and executing a script , the script does not at all run in 100% isolation from the host. For instance it shares the same AssemblyLoadContext so that means we can't really ignore the assemblies already loaded into the host AppDomain/AssemblyLoadContext.

So the approach taken is that we now inherit "on demand" meaning that when we load a assembly reference from the script dependency context, we will now check if the assembly is already loaded by the host. If its already loaded we skip the reference from the script dependency context, otherwise we load it. This should also fix the scenario when we run as netcoreapp2.0 where we only have the ``` netcoreapp2.1 sdk installed.

This change actually made all tests pass without suppressing CS1705.

In this PR we still suppress certain diagnostics, but they are now logged when running in debug mode -d

When it comes to the packages we produce nothing much has changed.

The tool package is compiled for netcoreapp2.1 while the rest of the packages are netcoreapp2.0 as before

@seesharper seesharper requested a review from filipw April 21, 2018 10:39
Copy link
Member

@filipw filipw left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

great!
there are a few small things that i'd like to revisit later (i.e. we should use AssemblyLoadContext instead?of AppDomain.CurrentDomain) but I don't want to block on this PR any longer 👍

@@ -1,28 +1,48 @@
#! "netcoreapp2.0"
#load "nuget:Dotnet.Build, 0.2.9"
#load "nuget:Dotnet.Build, 0.3.1"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what changed here?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Had to add the possibility to specify the target framework when doing DotNet.Publish since we now have multiple target frameworks. Otherwise nothing much to write home about 👍

}


[Fact(Skip = "This also failes when run a standard netcoreapp2.1 console app")]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we could still run this at least on netcoreapp2.0? Something like this should do:

    public class OnlyOnNetCore20FactAttribute : FactAttribute
    {
        public OnlyOnNetCore20FactAttribute()
        {
                Skip = RuntimeHelper.TargetFramework != "netcoreapp2.0";
        }
    }

{
// Always prefer the resolved runtime dependency rather than the inherited assembly.
if(!dependencyMap.ContainsKey(inheritedAssemblyName.Name))
loadedAssembliesMap.TryGetValue(runtimeAssembly.Name.Name, out var loadedAssembly);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

runtimeAssembly.Name.Name 😀

@@ -26,13 +24,7 @@ public class ScriptCompiler
// Note: Windows only, Mac and Linux needs something else?
[DllImport("Kernel32.dll")]
private static extern IntPtr LoadLibrary(string path);

protected virtual IEnumerable<Assembly> ReferencedAssemblies => new[]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍👍👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Dotnet Global Tool Install - FileNotFoundException
2 participants
pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy