-
Notifications
You must be signed in to change notification settings - Fork 520
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
don't not add duplicated references #3107
Conversation
HACK: workaround for fsprojects#2811 * DO remove FW-References which are already referenced by the user * DO NOT remove package references, where the user already has a reference Example where this is relevant: 1) Pre-existing reference to the FW-Assembly System.IO.Compression 2) user adds nuget package https://www.nuget.org/packages/System.IO.Compression/ Before: * the old reference is kept, the new one not added * no feedback during compile, assembly mismatch at runtime After: * new reference is added * duplicated reference, warning at compile time * msbuild automatically takes the higher version, everything is good * user can manually remove old reference to silence warning
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For my part I'd say this change (if we want to do it) needs to go to a different place.
Edit: TO clarify the "different" place is probably ProjectFile.fs
// Example where this is relevant: | ||
// 1) Pre-existing reference to the FW-Assembly System.IO.Compression | ||
// 2) user adds nuget package https://www.nuget.org/packages/System.IO.Compression/ | ||
//|> mapCompileLibReferences (Set.filter (fun reference -> Set.contains reference.Name references |> not)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure this is the place to do it. InstallModel is / or should be independent from msbuild/project file quirks
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
2 and 3 are fine by me. Basically it's less about where it is used but that the InstallModel-API speaks for itself and is consistent in its naming (it is already hard to understand as it is)
Just some notes on this:
|
Yeah, I don't like this "solution" either.
|
I'm ok either way (removing or always adding). The only thing here is that the logic needs to be moved to |
|
done? |
@matthid ? |
@0x53A Thanks :) |
HACK: workaround for #2811
Example where this is relevant:
Before:
After: