Closed henk-van-der-vaart closed 2 months ago
7.0.2 is the version of the NuGet package. If you download that package and look in the lib/netstandard2.0 folder, you'll see that the assembly there has a strong name of version 4.0.0. There isn't a package version of 4.0.0 at all. I can't talk to the details of how the System.Management package is laid out internally - it's possible that the empty lib/net462 directory means "use the version from the framework" or that it actually uses the version from lib/netstandard2.0 (given that .NET 4.6.2 supports .NET Standard 2.0).
It's possible that we could use a FrameworkReference rather than a package reference for the net462 target, but I'd be reluctant to make changes here without a concrete reason to do so.
Is this issue a matter of curiosity, or are you encountering an actual problem?
Basically my "problem" is that when I NuGet reference Google.Api2.Auth 1.68.0 in my .NET 4.8 project then it indicates Installing: Google.Apis.1.68.0 Google.Apis.Auth.1.68.0 Google.Apis.Core.1.68.0 System.CodeDom.7.0.0 System.Management.7.0.2 Building my project results in DLLs for each of above except for System.Management So it did not "get" or "use" the System.Management DLL (version 4.0.0) from lib/netstandard20 from System.Management.7.0.2 I need a complete set for deployment? How do I enforce get the the System.Management DLL (version 4.0.0) from lib/netstandard20 from System.Management.7.0.2 into my release build output folder. My assumption was this was caused by empty lib\net462 in System.Management.7.0.2
Before anything else: you keep referring to Google.Api2.Auth
- there's no such package as far as I'm aware. Is that actually a typo that you've somehow made three times for Google.Apis.Auth
, or do you have some other package repository?
Building my project results in DLLs for each of above except for System.Management
What sort of project is this (SDK-style or old-style)? How are you building? What are you doing with the output? Have you tried deploying with what you've got? (Maybe the DLL really isn't needed, and the package is just enough to add a reference to the right assembly version, which is then resolved from the framework.)
If you could provide a concrete set of steps which leads to some actual error (as opposed to just a human surprise in terms of the contents of a directory) that would make it much easier to help you.
Indeed typo - sorry - it should / is Google.Apis.Auth It is an old style C# project that NuGet reference in .NET Framework 4.8 targeted project. I use PackageReference in C# project file I deploy output DLLs and want to be sure DLL is yes or no needed. So I will not fall into runtime problems when functionality is called. So far it looks the DLL is not needed But since >=System.Management.7.0.2 was indicated I was mislead I think that 462 lib folder is empty indicating the regular .NET Framework 4.0.0.0 is OK. For lib/netstandard20 this same 4.0.0.0 DLL was included and for other .NETs other DLL versions are applicable. So my conclusion for now is that for deployment I could stick to the 3 Google.Apis.* DLLs (in case of .NET Framework)
Okay. I've created https://github.com/googleapis/google-api-dotnet-client/pull/2821 to convert this into a .NET Framework reference, so that the next version won't depend on the NuGet package. It's entirely possible that @amanda-tarafa had a good reason to use the package directly though, so it's not guaranteed that we'll ship this. (Note that @amanda-tarafa is currently on vacation, so it's unlikely that there'll be any updates imminently.)
Environment details
Steps to reproduce
The issue is basically in the mentioned dependencies for Google.Api2.Auth 1.68.0 In case of target .NET Framework 4.8 it will DLL from Google.Api2.Auth 1.68.0 lib\net462 folder.
So I think NuGet Gallery should indicate System.Management 4.0.0 for target net462 (or maybe even remove because I think this version is part of the .NET Framework itself Further it seems strange that there is an empty lib\net462 folder - or can this be explained