Several issues when packing a project referencing a multi-target project

[tranb3r]

Describe the Bug

When packing a single-target project that references a multi-target project, I'm facing 3 different issues that I'll try to describe here.
I'm a bit lost and I'd really appreciate some help. Thanks

Steps to Reproduce

TestNugetizer.zip

Open the repro TestNugetizer.zip and extract it. It contains 3 projects: LibA (a single-target project, references LibB) ; LibB (a mutli-target project) ; LibPackaging (a multi-target project, references LibA, and is used to build both LibA and LibB properly).

Go to the build folder, run clean.bat first, then pack.bat. There are 4 steps (clean, restore, build, pack). It should build all dlls and produce a TestNugetizer.1.0.0.nupkg file.

First issue: open the nupkg file ; the lib\monoandroid11.0\ folder should contain both LibA.dll and LibB.dll, but it's missing LibB.dll. The lib\netstandard2.1\ folder contains both libs, which is expected.

Second issue: open the nupkg file, and then the TestNugetizer.nuspec file. The Microsoft.Extensions.Http dependency is missing in the MonoAndroid11.0 targetFramework.

Third issue: the pack.bat produces the following error, which is weird:

NuGetizer.Shared.targets(277,5): error NG0012: Duplicate package source files with distinct content detected. Duplicates are not allowed in the package. Please remove the conflict between these files: 'D:\Dev\Temp\TestNugetizer\LibB\bin\Debug\netstandard2.1\LibB.dll' > 'lib\monoandroid11.0\LibB.dll' [D:\Dev\Temp\TestNugetize
r\LibPackaging\LibPackaging.csproj]
NuGetizer.Shared.targets(277,5): error NG0012: 'D:\Dev\Temp\TestNugetizer\LibB\bin\Debug\monoandroid11.0\LibB.dll' > 'lib\monoandroid11.0\LibB.dll' [D:\Dev\Temp\TestNugetizer\LibPackaging\LibPackaging.csproj]
NuGetizer.Shared.targets(277,5): error NG0012: 'D:\Dev\Temp\TestNugetizer\LibB\bin\Debug\netstandard2.1\LibB.pdb' > 'lib\monoandroid11.0\LibB.pdb' [D:\Dev\Temp\TestNugetizer\LibPackaging\LibPackaging.csproj]
NuGetizer.Shared.targets(277,5): error NG0012: 'D:\Dev\Temp\TestNugetizer\LibB\bin\Debug\monoandroid11.0\LibB.pdb' > 'lib\monoandroid11.0\LibB.pdb' [D:\Dev\Temp\TestNugetizer\LibPackaging\LibPackaging.csproj]

Version Info

Nugetizer 0.7.0

[kzu]

MonoAndroid11.0 TF fails for me. Seems it doesn't come built-in VS (stable or preview)? Could you try including a solution file and TFMs that don't require me to install additional components plz? Thanks! (ideally, anyone should be able to come up to a .sln, do dotnet build && dotnet pack and have it Just Work. No need for batch files or anything.

1. First issue, likely trivially solved by adding a LibB.csproj reference to the "packaging" project.
2. Second issue: the "packaging" project is the multi-targeting one. It does not declare a dependency on the Microsoft.Extensions.Http. Just add it there if you need it at the top-level.

[tranb3r]

MonoAndroid11.0 TF fails for me. Seems it doesn't come built-in VS (stable or preview)? Could you try including a solution file and TFMs that don't require me to install additional components plz? Thanks! (ideally, anyone should be able to come up to a .sln, do dotnet build && dotnet pack and have it Just Work. No need for batch files or anything.

Here is a new repro, with netstandard TFMs only, and with a solution file.
TestNugetizer.zip

1. First issue, likely trivially solved by adding a LibB.csproj reference to the "packaging" project.

Unfortunately, the result is the same when adding this reference. Not so trivial...

2. Second issue: the "packaging" project is the multi-targeting one. It does not declare a dependency on the Microsoft.Extensions.Http. Just add it there if you need it at the top-level.

The Microsoft.Extensions.Http is a package reference in LibA. The dependency is correctly added (at the top level) for one TFM, but not for the other one, which is not what we're expecting, right ?
My goal is to remove a nuspec file that I need to manually synchronize with all csproj for dependencies. If I really need to manually synchronize the packaging csproj with the other csproj for dependencies, then nugetizer does not have a great value-add in this scenario.

Don't you think those 3 issues could be fixed ?

[kzu]

The packaging project is using an SDK that's not a "standard" one. I changed it to Microsoft.NET.Sdk and things started working much better. I removed the reference from the packaging project (not really needed, as you pointed out), and just made the LibB project reference PrivateAssets="all" (that tells nugetizer not to carry it over transitively, and consider it instead as part of the output of that particular project, which is wat you want in this case).

The result is:

Which is quite close.

That said, I think you have a somewhat unusual scenario there, not sure I understand what's the "real" scenario behind it:

LibPackaging (NS2+NS2.1) => LibA (NS2) => LibB (NS2+NS2.1)

I'm not sure why someone would go to a multi-targeting dependency passing through a single-targeting one (LibA). I don't think that's a common scenario, which is likely why this is the first time someone reports it. I may be missing something there, so plz let me know what the concrete scenario is, perhaps it's a missed feature in NuGetizer.

If the scenario where the more common (I'd say):

LibPackaging (NS2+NS2.1) => LibA (NS2+NS2.1) => LibB (NS2)

Then things look exactly as you'd expect:

Attached is the patched solution.
TestNugetizer.zip

[tranb3r]

I'm not sure why someone would go to a multi-targeting dependency passing through a single-targeting one (LibA).

The scenario is very common when developing with xamarin:
App (android or ios or .net) -> LibA (NS) -> LibB (Android + iOS + NS)

LibB has platform specific implementations (for android, ios, or .net), so it needs multi-targeting.
LibA has no platform specific code, it's pure NS, so it's single-targeting.
Of course it works because all apps (either android or ios or .net) can reference NS libs.

[kzu]

I see. I still don't see it as a super common that someone would package the App as a nuget 🤔 . Neither the app logic (the NS). For the LibB author, nugetizer works like a charm for sure.

Perhaps the LibA is some sort of reusable UI/app layer... Dunno.

The scenario itself is not high priority for me in particular, but I'd gladly take a PR if you want to take a shot at it. NuGetizer has lots of tests that help exercise targets and tasks, which you can use as a guideline.

If this is a really really important scenario for you, perhaps you'd consider sponsoring me to look into it more deeply?

Thanks!

[tranb3r]

I still don't see it as a super common that someone would package the App as a nuget 🤔 . Neither the app logic (the NS). Perhaps the LibA is some sort of reusable UI/app layer... Dunno.

Of course it's not about nugetizing an app. It's not even about app logic, and it's not necessarily about UI. It's probably more about low-level reusable components.
The mobile SDKs are rich, here are more concrete exemples of what this nuget could be:

• an http client library, with platform specific implementation for requests, certificate pinning, cookie handling.
• an image processing library, with platform specific code for opening and transforming images.
• a sensors toolkit, with platform specific code for providing data about geolocation, device orientation, speed.

For all these exemples, LibA would contain the common logic, and LibB would contain low-level stuff that requires platform specific implementation (accessing to the platform SDK).

For the LibB author, nugetizer works like a charm for sure.

Not sure I understand what you mean. The idea is to package LibA+LibB.

The scenario itself is not high priority for me in particular, but I'd gladly take a PR if you want to take a shot at it. NuGetizer has lots of tests that help exercise targets and tasks, which you can use as a guideline.
If this is a really really important scenario for you, perhaps you'd consider sponsoring me to look into it more deeply?

Ok, I understand. I'll think about it. Thanks!

[kzu]

You don't need LibA for sharing common logic. You can have a single project, multi-targeting, that contains both the reference assembly for the API surface you want to expose, as well as the xplat/native code. Something like novotnyllc/MSBuildSdkExtras#47, say.

That's where things are going with Maui too and the upcoming SDKs for XA/XI being integrated with .NET6, IIRC.

[tranb3r]

You don't need LibA for sharing common logic.

Of course. But I think there is a misunderstanding.

The split between LibA and LibB does not exist because of platform specific code in LibB. Both LibA and LibB have different purposes (separation of functionality, dependencies, release process, team, whatever the reason...), and it just happens that LibB has platform specific code, and LibA is pure NS. It could be the contrary, but practically LibA is higher level than LibB so there is less chance of having platform specific code in LibA than in LibB.

[tranb3r]

That's where things are going with Maui too and the upcoming SDKs for XA/XI being integrated with .NET6, IIRC.

My understanding is that with Maui, there is one single application project (with platform specific code), instead of one application project per platform.
But for Libs, Maui will still use multi-targeting, same as today, right ? With new TFMs (for .net6) and the move from Franken-proj to SDK-style csproj.

[kzu]

They are all multi-targeting projects. There is no way to have any native app with a single project unless you multi-target.

[tranb3r]

They are all multi-targeting projects. There is no way to have any native app with a single project unless you multi-target.

Again, not sure I understand what you mean.
If we're now talking about apps instead of libs (which is not the topic but well...):

• with xamarin, a single-platform app uses a single project that is single-targeting.
• with xamarin, a multi-platform app uses multiple projects, but each project is also single-targeting.
• with maui, a multi-platform app uses a single project that is multi-targeting.

Or maybe I've missed something ?

[kzu]

I was talking Maui, of course. I did the original multi-targeting internal spike for that at Xamarin ;)