Clarification about the .NET8 runtimes sub-folder (Google.Apis.Gmail.v1)

[ajtruckle]

I have also asked this question on StackOverflow:

https://stackoverflow.com/q/78321715/2287576

I have seen a few questions about this. Eg:

https://stackoverflow.com/q/67920055/2287576

I don't mind these DLL files being there, but I am concerned. This is my runtimes folder structure:

runtimes
    win
        lib
            net7.0
                System.Management.dll
            net8.0
                System.Security.Cryptography.Pkcs.dll

My application is meant for running on a Windows PC, but my concern is this net7.0 reference. In my installer I only check for .NET8 Runtime dependency and not .NET7.

The System.Management.dll is used by Google.Apis.Gmail.v1:

The System.Security.Cryptography.Pkcs.dll is used by Mimekit, but I am not worried about this one:

Concerning the Google.Apis.Gmail.v1 NuGet package it states:

Google APIs Client Library for working with Gmail v1.

  Supported Platforms:
  - .NET Framework 4.6.2+
  - .NET Standard 2.0
  - .NET 6.0+

So, back to my concern ... my installer only checks for .NET8 runtime as that is my target platform. Should I be concerned about this reference to .NET7 runtime in the runtimes sub-folder?

[jskeet]

I'll look at this on Monday - but it would be really helpful if you'd provide more information about your app's targets rather than the targets of the package. Ideally, provide a minimal but complete example so we can reproduce it.

[ajtruckle]

@jskeet

Ideally, provide a minimal but complete example so we can reproduce it.

I don't know how to share it. But it is easily reproducible (at-least for me):

1. Create a new .NET8 C# Console Application.
2. Add the Google.Apis.Gmail.v1 NuGet package.
3. Compile

Navigate using File Explorer to here (relative to your root ofcourse):

...\ConsoleApp1\ConsoleApp1\bin\Debug\net8.0\runtimes\win\lib\net7.0

[jskeet]

Right, if that's all required, I should be able to reproduce that tomorrow.

[ajtruckle]

@jskeet Thank you.

[jskeet]

Okay, I've reproduced it. I would say that you should use dotnet publish - and then copy everything under the publish directory.

I believe it's showing up as net7.0 because we're currently depending on version 7.0.2 of System.Management, and that only targeted as far as net7.0 - but as net8.0 is compatible with net7.0, it will still load that at execution time.

If you want to move to the net8.0-targeted version, you can manually add a dependency on System.Management 8.0 yourself - then System.Management.dll will be in runtimes/win/lib/net8.0/System.Management.dll. If that makes your installer simpler, it'll do no harm.

(Separately, I'll file an internal bug to update our dependency to 8.0.0.)

[jskeet]

I'll close this now as hopefully this has addressed everything for you - if you have further questions, add a comment and I can reopen if necessary.

[ajtruckle]

@jskeet
Thanks for confirming. I have not used dotnet publish before. This console tool in a part of my bigger application. So all I do at the moment is add all the top level files on the build output folder to my installer.

I would like to keep my compiling process as simple as possible for my installer and not add anything else that I don’t need to add.

Will you be able to update this ticket once the bug is resolved? Will it take long?

[jskeet]

So all I do at the moment is add all the top level files on the build output folder to my installer.

I would encourage you to use dotnet publish for this instead. The whole point of dotnet publish is to prepare the application for publication, which is what your installer is presumably there for. I can't speak to precise differences (unless you're doing AOT trimming and the like) but I would personally say that the published version is the most appropriate one to install.

Will you be able to update this ticket once the bug is resolved? Will it take long?

There's no bug here to resolve. There's a dependency which we can update, but the fact that it's a slightly old dependency isn't a bug - it's not like we know of a security problem within the older version.

I don't know when we'll get to updating the dependency - we don't release new versions of the support library very often (there's about to be another one which won't include this change) and I wouldn't want to create a minor release just for an unnecessary dependency update.

As I said before, if you really want the latest dependency, you can add it yourself directly to your own project. I'd also note that even with that change, the file will be under runtimes/win/lib/net8.0 - so if your installer is only copying top-level files, you'll still have an issue.

(This dependency is used for BIOS detection when running on Windows as part of Default Application Credentials detection, by the way. It's possible that if you're always specifying credentials via an environment variable or explicitly loading them, that the dependency being missing wouldn't be an issue anyway - but I wouldn't personally take that risk.)

[ajtruckle]

@jskeet

I would encourage you to use dotnet publish for this instead. The whole point of dotnet publish is to prepare the application for
publication, which is what your installer is presumably there for.

Thank you for the explanation and advice. 😊