Using ValueTuple with PackageReference on Azure Cloud Services

[jnyrup]

This is the same problem as described in this closed/abandoned issue. That got closed as being reported the wrong place, that's why I'm trying here.
Please let me know if this is also not the right repo.

I'm trying to convert my C# projects from old to new csproj style, but this breaks my Azure Cloud Service at runtime because the ReferenceAssembly of System.ValueTuple.dll is copied instead of the implementing assembly.

My projects are currently targeting .NET 4.6.1, which doesn't come with System.ValueTuple but should be able to get it by consuming the System.ValueTuple NuGet package.

The problem is "solvable" by targeting .NET 4.7+, as that comes with System.ValueTuple included and hence does not need to reference it as a NuGet package.

I would like to avoid upgrading to .NET 4.7+ if possible, as:

This requires an additional deploy step to install .net 4.7+ runtimes on the worker roles, as they come with .net 4.6.2 installed. https://docs.microsoft.com/en-us/azure/cloud-services/cloud-services-guestos-update-matrix#family-5-releases
This seems as "the easy way out", and I would like to know if the problem can be solved otherwise.

Steps to reproduce

I'll use:

• refDLL for: packages\system.valuetuple\4.5.0\ref\net461\System.ValueTuple.dll, and
• libDLL for packages\system.valuetuple\4.5.0\lib\net461\System.ValueTuple.dll.
  They are easily distinguishable, as refDLL is 40 kb and libDLL is 78 kb.

The code and complete build log file is found here:
AzureCloudService1.zip

• WorkerRole1 consumes System.ValueTuple via packages.config
• WorkerRole2 consumes System.ValueTuple via PackageReference

After building the cloud service the

• WorkerRole1\bin\Debug has libDLL.
• WorkerRole2\bin\Debug\net461 has libDLL
• AzureCloudService1\obj\Debug\WorkerRole1 has libDLL
• but AzureCloudService1\obj\Debug\WorkerRole2 has refDLL

Expected behavior

AzureCloudService1\obj\Debug\WorkerRole2 should contain libDLL.

Actual behavior

AzureCloudService1\obj\Debug\WorkerRole2 contains refDLL.

Environment data

msbuild /version output:

Microsoft (R) Build Engine version 15.7.180.61344 for .NET Framework
Copyright (C) Microsoft Corporation. All rights reserved.

15.7.180.61344

Addionational info

From the logs, I noticed the following difference between WorkerRole1 and WorkerRole2.

WorkerRole1:

C:\Users\jonas\source\repos\AzureCloudService1\packages\System.ValueTuple.4.5.0\lib\net461\System.ValueTuple.dll
CopyLocal = true
FusionName = System.ValueTuple, Version=4.0.3.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51
HintPath = ..\packages\System.ValueTuple.4.5.0\lib\net461\System.ValueTuple.dll
ImageRuntime = v4.0.30319
MSBuildSourceProjectFile = C:\Users\jonas\source\repos\AzureCloudService1\WorkerRole1\WorkerRole1.csproj
MSBuildSourceTargetName = BuiltProjectOutputGroupDependencies
OriginalItemSpec = System.ValueTuple, Version=4.0.3.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51, processorArchitecture=MSIL
ReferenceAssembly = C:\Users\jonas\source\repos\AzureCloudService1\packages\System.ValueTuple.4.5.0\lib\net461\System.ValueTuple.dll
ReferenceSourceTarget = ResolveAssemblyReference
ResolvedFrom = {HintPathFromItem}
Version = 4.0.3.0
WorkerRole2:

C:\Users\jonas\.nuget\packages\system.valuetuple\4.5.0\ref\net461\System.ValueTuple.dll
CopyLocal = false
ExternallyResolved = true
FusionName = System.ValueTuple, Version=4.0.3.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51
HintPath = C:\Users\jonas\.nuget\packages\system.valuetuple\4.5.0\ref\net461\System.ValueTuple.dll
ImageRuntime = v4.0.30319
MSBuildSourceProjectFile = C:\Users\jonas\source\repos\AzureCloudService1\WorkerRole2\WorkerRole2.csproj
MSBuildSourceTargetName = BuiltProjectOutputGroupDependencies
NuGetPackageId = System.ValueTuple
NuGetPackageVersion = 4.5.0
NuGetSourceType = Package
OriginalItemSpec = C:\Users\jonas\.nuget\packages\system.valuetuple\4.5.0\ref\net461\System.ValueTuple.dll
Private = false
ReferenceAssembly = C:\Users\jonas\.nuget\packages\system.valuetuple\4.5.0\ref\net461\System.ValueTuple.dll
ReferenceSourceTarget = ResolveAssemblyReference
ResolvedFrom = {HintPathFromItem}
Version = 4.0.3.0

After searching for other related issues on various Microsoft issue trackers, I found this one, which seems related: dotnet/sdk#1738.

[zhaomuzhi]

I got exactly the same issue, but on some other packages like System.Buffers. The dlls under ref folder was copied, instead of lib folder. Is there any workaround except reverting back to Reference? @jnyrup how did you get around it?

[jnyrup]

@zhaomuzhi I got around the problem in my toy project by re-targeting the projects to .net 4.7.2.
probably related to https://twitter.com/terrajobst/status/1031999730320986112?lang=en

To get that to run in the Cloud Services you either need to:
Update to Guest OS Family 6 has recently been released, which includes .NET Framework 4.7.2.
I haven't tried it out yet, as I'm waiting for the Azure DevOps Build Agents to get Azure SDK 3.0.
https://developercommunity.visualstudio.com/content/problem/443790/the-os-family-6-you-are-trying-to-deploy-is-not-su.html

For Guest OS Family 5, you need to install .net 4.7.2 as part of the deployment process.
https://docs.microsoft.com/en-us/azure/cloud-services/cloud-services-dotnet-install-dotnet

[livarcocc]

Well, this seems to be behaving as expected actually. Besides that, this does not seem to be an MSBuild issue either.

4.6.2 does not contain the assembly, therefore it needs to be acquired through nuget and distributed with the app. If you want to avoid that, you need to target a TFM where it is supported, net4.7.2, for instance. The system is doing what it is supposed to do.

[jnyrup]

@livarcocc I've update the issue description to hopefully be more clear.
Short story, I am consuming System.ValueTuple as a nuget package from my 4.6.1 project and it works when using packages.config.
The problem happens when switching from packages.config to <PackageReference> as that causes another dll to be copied to the obj folder of the Cloud Service.

[dejanberic]

I got the same issue, so I upgraded all projects to target 4.7.2.
After upgrading I ran Update-Package -reinstall in Package Manager Console to reinstall all nuget packages in my solution to target 4.7.2.
On Cloud Services I switched to osfamily = "6".
I am still using Azure Authoring Tools 2.9

[livarcocc]

This seems like something that NuGet should/could take a look on. I am going to move this issue to NuGet.

[livarcocc]

This issue was moved to NuGet/Home#8723

[yirkha]

FYI I think neither MSBuild nor NuGet nor the Azure SDK for .NET project is the right place for this bug.
I've provided an update together with a workaround in Azure/azure-sdk-for-net#3699 (comment)