Added DevelopmentDependency=true to Equals.Fody project

[HavenDV]

This change automatically installs private assets after the package is installed.
Will be:

<PackageReference Include="Equals.Fody" Version="4.0.1">
   <PrivateAssets>all</PrivateAssets>
   <IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
</PackageReference>

Instead:

<PackageReference Include="Equals.Fody" Version="4.0.1" />

[SimonCropp]

did u smoke test this?

[HavenDV]

I see the following warning after this change, but I find it more clearly emphasizes the nature of the package and makes it easier for the user to remove IncludeAssets after this warning.
MSBUILD : warning FodyPackageReference: Fody: The package reference for Equals.Fody is missing the 'compile' part in the IncludeAssets setting; it's recommended to completely remove IncludeAssets

[HavenDV]

https://github.com/NuGet/Home/wiki/DevelopmentDependency-support-for-PackageReference
This property is officially supported, and is often used in new code generators. I have also used it and I guarantee it works.

[ltrzesniewski]

This will by default remove the reference to the Equals assembly (which will prevent the usage of the [Equals] attribute for instance). So it's not a good change IMO.

That's why Fody weavers don't set the DevelopmentDependency to true. I'd like to have a way to only set PrivateAssets="all", but it doesn't exist ATM.

[tom-englert]

Also this should be the same for all weavers, not just this one!

[HavenDV]

NuGet/Home#10746
Yes, I think it is worth waiting for the solution to this problem and then applying it to all Weavers.
Voting for this will probably raise the priority.

[SimonCropp]

could we use dev dependency, but re add the ref in an msbuild imort?

[ltrzesniewski]

The main problem I see with that is that we'd need to pick the correct TFM for the Reference item. I'm not sure if plugging into the SDK for this would be easy.

I thought about updating the package's IncludeAssets metadata item to an empty string in the package's targets file, but that doesn't strike me as a great idea either. On the other hand, that's pretty easy to try...