Can package references suppress grouping by target framework when packing?

[bording]

When packing via csproj, is there a way to have the project's package references not be grouped by the target frameworks of the project?

I have a package that is a development dependency, and it only has props and targets files in it. It also references a couple other packages that I want any consuming project to include transitively. You can see the csproj here: https://github.com/Particular/Particular.Packaging/blob/master/src/Particular.Packaging/Particular.Packaging.csproj

None of the these packages have any sort of framework dependencies, but because package references are turned into framework-specific dependencies in the nuspec, I currently have to multi-target my csproj to cover all the TFMs we use in consuming projects.

This results in the following section in the nuspec:

  <dependencies>
      <group targetFramework=".NETFramework4.5.2">
        <dependency id="GitVersionTask" version="4.0.0-beta0012" include="All" />
        <dependency id="Microsoft.SourceLink.GitHub" version="1.0.0-beta-63102-01" include="All" />
      </group>
      <group targetFramework=".NETStandard2.0">
        <dependency id="GitVersionTask" version="4.0.0-beta0012" include="All" />
        <dependency id="Microsoft.SourceLink.GitHub" version="1.0.0-beta-63102-01" include="All" />
      </group>
    </dependencies>

While this works okay for us in most cases, recently it's been causing some problems where the package has been referenced in projects that have a TargetFramework other than net452 or netstandard2.0. I don't want to have to keep updating this package as another TFM edge case is discovered.

What I'd really like to see instead is:

    <dependencies>
      <dependency id="GitVersionTask" version="4.0.0-beta0012" include="All" />
      <dependency id="Microsoft.SourceLink.GitHub" version="1.0.0-beta-63102-01" include="All" />
    </dependencies>

@rohit21agrawal Is there any way to make this happen without having to fall back to a manually-created nuspec file?

[jainaashish]

I don't think you can achieve it through project file, but I'll let Rohit answer it when he's back.

But I'd recommend to have the target framework specific groups without making it generic.

[bording]

But I'd recommend to have the target framework specific groups without making it generic.

@jainaashish Unless I'm misunderstanding you, you seem to be suggesting I do the exact thing I'm trying to avoid, and opened this issue about!

For the package in question, none of the dependencies have any framework requirements, so the fact that the package gets built with the dependency groups is an artificial limitation.

The dependency groups are actively causing me problems, because if someone adds a reference to my package but they are targeting a TFM that I haven't included, then they don't get the transitive references, and that leads to silent build failures. In this specific case, it means that the project doesn't generate the correct version, and the binaries are missing SourceLink information. It's not immediately obvious what the problem is either.

[rohit21agrawal]

@bording unfortunately there is no way to do this, and while I agree that this maybe a problem for some of the packages, i am not sure the right solution here is to avoid grouping dependencies into framework.

what if you targeted the lowest possible framework so it becomes compatible with most of them?

[bording]

@bording unfortunately there is no way to do this, and while I agree that this maybe a problem for some of the packages, i am not sure the right solution here is to avoid grouping dependencies into framework.

In general, grouping dependencies is definitely the right thing to do, it's just this sort of build tools/dev dependency style of package where it would be nice to turn the grouping off.

what if you targeted the lowest possible framework so it becomes compatible with most of them?

That might at least address the difficulty of needing to keep the TFMs I'm targeting updated.

[rohit21agrawal]

I will let this issue remain open, but i can't promise by when this would get resolved. (I would gladly accept a PR for this though). The solution I would come up with would probably involve introducing a property like "GroupDependenciesByFrameworkInPackage" , which defaults to true but can be set to false, and that would cause dotnet pack to output all dependencies in the package independent of TFM.

[bording]

I will let this issue remain open, but i can't promise by when this would get resolved. (I would gladly accept a PR for this though). The solution I would come up with would probably involve introducing a property like "GroupDependenciesByFrameworkInPackage" , which defaults to true but can be set to false, and that would cause dotnet pack to output all dependencies in the package independent of TFM.

Sounds good. I might try and work on a PR for this.

[jainaashish]

I will let this issue remain open, but i can't promise by when this would get resolved. (I would gladly accept a PR for this though). The solution I would come up with would probably involve introducing a property like "GroupDependenciesByFrameworkInPackage" , which defaults to true but can be set to false, and that would cause dotnet pack to output all dependencies in the package independent of TFM.

@rohit21agrawal I'm not sure if that's the right thing to do, when we want packages to be TFM specific (not allowing package assemblies directly under /lib etc...) then why not their dependencies as well? We can't just have packages which are just applicable for all the tfms in the world...

This may seems like a reasonable ask for @bording scenario since he just have a development dependency which only includes some msbuild assets but having GroupDependenciesByFrameworkInPackage will not just be restricted with that and will open lot of room for other scenarios which won't work as expected.

I'd rather discuss it before committing that we're fine with such a feature and willing to take a PR for that.

cc @rrelyea

[rohit21agrawal]

@jainaashish the point here is that we don't decide on behalf of authors what is the right way to author a package, at least not force it on them - which is why we have the all powerful nuspec in the first place. What we do for dotnet pack is pick the right defaults for the author, but that doesn't mean we don't give them the flexibility to create packages for corner cases that we didn't think of.