Try running stub msquic on CI

[jkotalik]

Need to check a few things before merging, like whether it's okay to have a package reference like this in a test project.

[jkotalik]

@ViktorHofer maybe you can help with this (or direct me to someone who would know more). I'm a bit confused why there was a test failure here. The goal is to have a native dll that the test project brings in that will be found when having a DllImport. msquic.dll is located in System.Net.Quic.Tests\netcoreapp5.0-Windows_NT-Debug. When I'm running this locally, I see that the msquic.dll is found and the test passes. However, when this is running on CI, the dll isn't found.

I downloaded the same test assets that were downloaded by the helix test run. I then ran RunTests.cmd with a local build of the testhost. This also succeeded. So I'm not sure why the native dll isn't being found. I can do some more verification to make sure the dll is present on the helix machine, but from what I can tell it's present.

[ViktorHofer]

I'm starting to wonder if this might be a deps.json issue. I'll take a look now.

[ViktorHofer]

@jkotalik are you sure the package is authored correctly?

Maybe that's the reason why the assembly isn't loadable as it isn't recognized and not added to the test's deps.json file.

cc @ericstj

[jkotalik]

So the native dll is being included via contentFiles and specifies CopyToOutputDirectory on it. Therefore, I don't believe it would be added to the deps file. However, my expectations were that if the msquic.dll is present next to System.Net.Quic.Tests.dll, when DllImport resolves, it would be able to find msquic.dll.

Also, if there is a better way to do what I'm trying to do, I'm all ears. Internal configuration for creating this package is here: https://dev.azure.com/dnceng/internal/_git/dotnet-msquic-build?path=%2FMsQuicPackage

[ViktorHofer]

So instead of being inside "content" or "contentFiles", the assembly should be put into the "lib" folder (or runtimes, if it's agnostic). Example for System.Drawing.Common:

In your case you want the following structure:

runtimes -> win-x64 -> lib -> netcoreapp2.1

[ViktorHofer]

Otherwise the host could refuse to load the assembly even if it's present. The folder structure inside the nuget package defines which is being written into the deps.json file which is the input for the host and its assembly loading decisions.

[jkotalik]

runtimes -> win-x64 -> lib -> netcoreapp2.1

Right now, I'm doing content include to bring in these native dlls. Should I just do a none include with a link to get it into the runtime/*/lib/netcoreapp2.1 folder?

Another thing is; I don't really care about the netcoreapp2.1 aspect. I think I should be doing: \runtimes\win-x64\native\msquic.dll.

[jkotalik]

Anyways, I think I know what I need to do at this point. Will update this PR once the package is authored correctly.

Appreciate the help as well 😄

[ViktorHofer]

You also need to set the property CopyLocalLockFileAssemblies in the test project to true..

[ViktorHofer]

Right now, I'm doing content include to bring in these native dlls. Should I just do a none include with a link to get it into the runtime/*/lib/netcoreapp2.1 folder?

Can you please point me to the source code / project file?

Another thing is; I don't really care about the netcoreapp2.1 aspect. I think I should be doing: \runtimes\win-x64\native\msquic.dll.

I think you need to have the netcoreappx.x in it, otherwise it won't be resolved as a usable asset by the host.

[ViktorHofer]

Ok I was wrong about this:

I think you need to have the netcoreappx.x in it, otherwise it won't be resolved as a usable asset by the host.

I would mimic the Microsoft.DiaSymReader.Native package:

[jkotalik]

I went ahead and did that with my change. However, I'm still seeing issues with the test failing on CI, but passing locally. Here is the folder structure of the test project:

And I have the msquic.dll in the correct folder:

But, I'm still hitting an error with finding the native dll:

System.TypeInitializationException : The type initializer for 'System.Net.Quic.Implementations.MsQuic.Internal.MsQuicApi' threw an exception.\r\n---- System.DllNotFoundException : Unable to load DLL 'msquic.dll' or one of its dependencies: The specified module could not be found. (0x8007007E)

Unless I'm mistaken, when RunTests.cmd starts, it should automatically have runtimes\RID\native\ as a search directory when looking for native dlls via DllImport. I see this behavior locally when running RunTest.cmd via the test artifacts.

[ericstj]

Can you share the deps file? /cc @vitek-karas

Is msquic.dll a native DLL? Does it statically link its depdencies (like C-runtime, etc)?

[jkotalik]

If you want the entire deps file, I can post separately, but here is the relevant section in the deps file itself.

"targets": {
    ".NETCoreApp,Version=v5.0": {
      "MsQuicPackage.win-x64/1.0.9": {
        "runtimeTargets": {
          "runtimes/win-x64/native/msquic.dll": {
            "rid": "win-x64",
            "assetType": "native",
            "fileVersion": "10.0.10011.16384"
          },
          "runtimes/win-x64/native/msquic.pdb": {
            "rid": "win-x64",
            "assetType": "native",
            "fileVersion": "0.0.0.0"
          }
        }
      },
   }
}

msquic is a native dll. I think the c-runtime is dynamically linked, but I'll need to confirm that.

[vitek-karas]

The .deps.json looks reasonable (the pdb record is useless, but it should break anything either).
Can you modify the test to print out the value of AppContext.GetData("NATIVE_DLL_SEARCH_DIRECTORIES") so that we can look at it when it fails in the CI. That contains all the paths the runtime will use to look for native dlls (aside from the app directory itself).

[jkotalik]

FYI I have found the root cause of the issue. msquic isn't dynamically linking against the UCRT yet, so I statically build msquic for now to use for testing.