This project has moved and is read-only. For the latest updates, please go here.
1

Closed

Identify Referenced Flavors as Dependencies

description

Project references to projects that aren't packaged themselves but are instead flavors of some other project aren't detected as dependencies. Instead, they are included into the referencing project's package just like other project references.

Example Scenario:
<!-- A -->
<Project>
<TargetFrameworkBlahBlah>.NET 4.5.1</TargetFrameworkBlahBlah>
<NuGetFlavor Include="B" />
</Project>

<!-- B -->
<Project>
<TargetFrameworkBlahBlah>Portable .NET 4.0, SL5, Blah Blah</TargetFrameworkBlahBlah>
</Project>

<!-- C -->
<Project>
<TargetFrameworkBlahBlah>.NET 4.5.1</TargetFrameworkBlahBlah>
<ProjectReference Include="A" />
<NuGetFlavor Include="D" />
</Project>

<!-- D -->
<Project>
<TargetFrameworkBlahBlah>.NET 4.0 Client Profile</TargetFrameworkBlahBlah>
<ProjectReference Include="B" />
</Project>
After building, project C's NuGet package will contain a dependency to project A, because White Tie detects that A builds a package. Project D is correctly included as a flavor in project C's NuGet package; however, the NET40 folder will also contain project B's assembly (embedded) just like a typical project reference, because project B does not build a package so White Tie doesn't know that it should be a dependency.

Enabling White Tie for project B won't help because then project D will reference the wrong package - it will reference the unwanted package for project B rather than the primary package for project A, which includes project B as a flavor.

It may be possible to detect this situation automatically (under a few assumptions):
  1. Define a NuGetFlavorReferences target. (Injection not required.)
  2. When building the primary project (C in the previous example), for each project reference that is determined to be a package dependency (A in the previous example), gather its flavors (B in the previous example) via the NuGetFlavorReferences target (in A) and compare them to all of the flavor projects' (D) references (B). All matches must be treated as dependencies rather than as regular references for their corresponding flavors. In the previous example, B=B, thus flavor project D must include a dependency to package A rather than embedding assembly B.
Assumptions:
This only works if the primary project (C) references the project (A) that references the flavor (B) referenced by its flavor (D).
Furthermore, it only works when the referenced project (A) references White Tie to build its NuGet package, though that's a given if it's building a flavor (B).
These seem like fair assumptions that are probably true most of the time anyway.
Closed Sep 18, 2014 at 1:37 PM by davedev
Fixed in v1.3.12

comments

davedev wrote Sep 18, 2014 at 11:59 AM

Somewhat related work item: https://whitetie.codeplex.com/workitem/15

davedev wrote Sep 18, 2014 at 1:30 PM

Fixed in changeset 29c6263019d4faadf32c8781d10c2a8ab7c19d0c