D
D
Dmitry Petrov2018-05-20 17:41:29
.NET
Dmitry Petrov, 2018-05-20 17:41:29

How does dependency hooking work with NetCore and NetStandard?

Stage 1.
There is a NetStandardLibrary project on NetStandard 2.0. It includes the "System.IO.FileSystem.AccessControl" package as a dependency and declares the only class with the Test method:

using System;

namespace NetStandardLibrary
{
    public class Class1
    {
        public static bool Test(string folder)
        {
            try
            {
                var ds = new System.Security.AccessControl.DirectorySecurity(folder, System.Security.AccessControl.AccessControlSections.All);
                return true;
            }
            catch
            {
                return false;
            }
        }
    }
}

We compile the project, we get NetStandardLibrary.dll/NetStandardLibrary.pdb/NetStandardLibrary.deps.json as the output.
Stage 2.
There is a TestNetFullApp project (console application). We connect NetStandardLibrary to it as a simple link from the solution, the application code looks like this:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;

namespace TestNetFullApp
{
    class Program
    {
        static void Main(string[] args)
        {
            try
            {
                var d = NetStandardLibrary.Class1.Test(Environment.CurrentDirectory);
                Console.WriteLine("Hello World!");
            }
            catch (Exception ex)
            {
                Console.WriteLine(ex.ToString());
            }
            Console.ReadLine();
        }
    }
}

Run and get exception (1). As you can see, among the loaded assemblies (2) there is no System.IO.FileSystem.AccessControl included in NetStandardLibrary. Actually, it is not in the output directory of the application either.
5b01839eaaff4945565952.png
OK. In NetStandardLibrary, check the "Create a Nuget package on build" checkbox, configure the folder of this project as a package source in Visual Studio, and include the package in TestNetFullApp. We start - voila, there is no error, the file appeared in the TestNetFullApp output directory, because System.IO.FileSystem.AccessControl has been pulled in as a dependency for the NetStandardLibrary package.
Okay, let's see what kind of file it is. System.IO.FileSystem.AccessControl.dll weighs 27.1kb.
We look into the folder of the local user, then ".nuget / packages", where now all downloaded packages are stored by the PackageReference mechanism. Hmm, what a wonder? Why does the library weigh 29.1kb?
5b0185cb9e9af135553254.png
We are looking in neighboring folders and yes! The searched file is found in the adjacent "\lib\net461". Inspection through ILSpy confirms that they are identical libraries with TypeForwardedTo attributes inside. But the copy in "\lib\netstandard2.0" does not have these attributes. What, in fact, is confirmed by experiment - if you push the assembly from "\lib\netstandard2.0" to the TestNetFullApp application, then a PlatformNotSupportedException exception will be thrown.
Stage 3.
We create a console application TestNetCoreApp and connect NetStandardLibrary as a project from the solution.
We start - everything works. Moreover, the System.IO.FileSystem.AccessControl.dll assembly was included from the ".nuget/packages" folder.
5b018756e58d8524360076.png-------------------------------------------------- ---------------------
In general, in connection with this, a number of questions arose about the operation of the mechanism for connecting dependencies in NetStandard and .Net Core.
1) Where can I read more about how it works?
2) Why is TestNetFullApp referring to the assembly from "\lib\net461" folder instead of "\lib\netstandard2.0"? Does NetStandard work as an interface and look for exactly the assembly on the platform on which the application is running?
3) If the answer to the question in the previous paragraph is "yes", then how to create an assembly independent of Nuget under NetStandard with all variants of dependent assemblies (the same System.IO.FileSystem.AccessControl.dll) so that it works without problems on NetFramework, NetCore, NetStandard by simply including NetStandardLibrary as a reference.
3.1) Clarification to the question. The fact is that in one of the projects an assembly is formed that is installed in the GAC, it is connected at Design-time in Visual Studio to work with Razor. If you translate it to NetStandard, then it becomes necessary to either have all the assemblies on which it depends in the GAC, or use Costura.Fody (inclusion of dependent assemblies in the body of the main assembly in the form of embedded resources). The second option is very convenient, all dependencies are loaded automatically when the main assembly is loaded. But this does not work with NetStandard - the file from "\lib\netstandard2.0" is attached as a dependency, and the application does not need it.
4) What happens if I run TestNetCoreApp in the profile of another user who does not have downloaded packages in ".nuget/packages"? Will they pull up automatically? If yes,

Answer the question

In order to leave comments, you need to log in

1 answer(s)
S
Stanislav Makarov, 2018-05-23
@Sellec

You have come across a library that has different versions for different operating systems (in nuget this is called runtimes). This can be stated by the presence of the runtimes folder in the root of the nuget package. The assembly that you see in lib\netstandard2.0 (weights 29 kb) redirects the types to the assembly for a specific runtime (EMNIP).
Start here: https://natemcmaster.com/blog/2016/05/19/nuget3-ri...
Yes.
What does NuGet independent mean? Where do you see addiction?
https://docs.microsoft.com/en-us/dotnet/core/tools... :

Starting with .NET Core 2.0, you don't have to run dotnet restore because it's run implicitly by all commands, such as dotnet build and dotnet run, that require a restore to occur.

Didn't find what you were looking for?

Ask your question

Ask a Question

731 491 924 answers to any question