When Xamarin.Forms isn't referenced in the head projects, XF build targets aren't imported

[kzu]

Description

(context: NuGet/Home#6091)

Currently, we sort of force users to update their package reference to XF in every project, because otherwise none of the XF build targets are imported. XF could improve this by relying on the new-ish buildTransitive feature mentioned above, which allows transitive importing of those targets. This means we can simplify the project template, but more importantly, ensure customers have a more streamlined experience in updating XF: they would just need to do it on the NS library project(s).

Steps to Reproduce

1. Create new Mobile App from template, notice how all heads have a reference to XF.
2. Add the following target to a head project and run msbuild -t:ShowCapabilities:

  <Target Name="ShowCapabilities">
    <Message Importance="high" Text="ProjectCapability:" />
    <Message Importance="high" Text="  - %(ProjectCapability.Identity)" />
  </Target>

3. Note how the XamarinForms capability is rendered.
4. Now edit the .csproj and remove the Xamarin.Forms PackageReference from the head
5. Run msbuild -r -t:ShowCapabilities (the -r is key to perform a new restore).

Expected Behavior

Step 5 shows XamarinForms capability is still present, since targets should flow transtively.

Actual Behavior

XamarinForms capability is gone, and with it, all of the XF targets.

Basic Information

• Version with issue: 4.3.0.908675
• Last known good version: none, there wasn't a build transitive capability before.

Workaround

Just like today, you need to add the XF dependency on all heads, and keep them in sync with the library.

To verify that the fix/improvement would work, you can just copy the entire build folder from your nuget package cache into buildTransitive folder, delete obj on your solution, and now the capability will properly propagate transitively.

For compatibility reasons (since support for buildTransitive for VS2017/NuGet4.x is still pending) we should
keep the build folder, and add new targets under buildTransitive that just redirect to the current ones.

[PureWeen]

#4126 (comment)

I don't think this is a bug, more the default behavior. The compile asset is transitive, the build is not by default. There's no way in our XF nuget to declare an override for PrivateAssets that'll be included on package reference.
In addition, doing that will have a huge build perf implication as XamlC will run on all assemblies, including the native ones.

Declaring the XF nuget as a development dependency, or setting PrivateAssets="content files;analyzers" is, at the end, the choice of the nuget package consumer, and even if that was our intention, we have no way of being prescriptive on that matter.

thanks @mrward for the explanations

(if you know stuffs I do not, please comment and/or reopen the issue)

[kzu]

Useful for context, but the .. the build is not by default. There's no way in our XF nuget to declare an override for PrivateAssets that'll be included on package reference. would seem to be incorrect in light of the new buildTransitive support.

In addition, doing that will have a huge build perf implication as XamlC will run on all assemblies, including the native ones.

How is it different from today where we effectively have XF (and XF.Essentials) being required in head projects always? (they are even in our templates).

[PureWeen]

@StephaneDelcroix @mrward thoughts?

[StephaneDelcroix]

this buildTransitive property might solve the issue described in #4126. I'm not that worried about the XamlC overhead, but it still need to be investigated

[dotMorten]

this issue is exactly what buildTransitive is there to solve. Sadly the nuget team hasn't been able to backport yet

[kzu]

So @StephaneDelcroix, why would there be a delta in the xamlc behavior? Aren't customers already adding the XF package to every project in their solution already since that's how things "just work" nowadays? I think this will make our projects even less cluttered, and we should take advantage of it.

[PureWeen]

@kzu if we put these files into both \build\ (for VS 2017 compatibility) and \buildTransitive\ is that ok?

I did some binlog tests and it seems like if I have \buildTransitive\ that \build\ gets ignored on VS 2019 and things don't get doubled up

[dotMorten]

@PureWeen That's exactly what happens yes. There's just not really a reason not to do buildTransitive. It just sucks it doesn't work for VS2017 people, but Xamarin has already essentially dropped VS2017 support at this point (not officially but anything Xamarin Android or iOS compiled with VS2019 is most likely not VS2017 compatible)

[samhouts]

closed by #10125