fsprojects / fsprojects/Paket

Confusion between referenced dlls when a dependency contains multiple targets

Open
#3,492 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

bug needs triage
Dominant language
F#
Stars
2.1k
Forks
528
Avg merge
1d 12m
Merged PRs (30d)
54

Description

Description

When mixing frameworks in a dependency chain and a mutual 3rd dependency with mixed target dlls, the wrong target dlls get referenced, causing build errors

Repro steps

have a netstandard2.0 project (A)
reference a package (e.g. DotNetZip) which contains a net40 and netstandard2.0 dll
Have another project net472 (B), make it reference A and use DotNetZip
You need to reference DotNetZip from B also
Do this
A references the netstandard2.0 dll
B references the net40 dll
B doesnt build because it doesnt reference the same dll used by A

See repro project:

https://github.com/MyUNiDAYS/paket-bug

Expected behavior

netstandard2.0 dll is used in B

I'd expect this to happen automatically. Using framework: netstandard2.0 in both paket.dependencies and paket.references has no effect

Actual behavior

net40 dll of DotNetZip is referenced by B instead of netstandard2.0

Known workarounds

Manually edit csproj, which gets blown away next time you paket install anything

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the linked paket-bug repro project and reproduce the build using the netstandard2.0 project A, net472 project B, and the DotNetZip references. Inspect paket.dependencies, paket.references, and the generated csproj to trace target selection. Done means B references the same netstandard2.0 DotNetZip DLL as A without manual csproj edits after paket install.

Written by the indexing model from the issue text.

Assessment

Domain
build-system, tooling
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.