Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Package ... contains libraries, but not for the selected TargetFramework net452 in project ... #1693
When I run paket.exe install, I got these warnings:
We're getting this issue as well and it's causing a bit of confusion.
It's a weird situation really. I've made a reproduction here:
It's a very simple repro.
We had a secondary issue which was warned correctly and we could resolve it, but was harder to see since the initial reaction is always, oh there's a hundred pointless warnings, ignore all.
Adding in framework: >= 4.0 does quiet the warnings. I'm really not sure if that's the thing to do or if it's just hiding the problem in paket.
There is and it works, but doing so means that now my .net core packages have been removed.
If I then switched to .netcore as a build target, we would have to re-run paket install, or maybe just restore.
But paket has this wonderful structure of conditionals everywhere so that we've not had to do that before - all packages were available and we could just build for different targets without having to recalculate packages in between.
The framework is fine as a workaround, I'm just not sure it's a solution.
I think this is an underlying issue that's causing other bugs, I've got 2 further build problems based on the same dependency issues:
The paket.update.cmd I would expect to complete without warnings. It does the right thing to the files as far as I can tell, but the warnings are spurious, unnecessary.
The build.cmd - there's no reason for that to fail.
Ah, ok, no problem.
The message is a warning based on the currently selected framework.
That's fine as stands - but there's a problem.
The direct dependency is AutoMapper.
Now AutoMapper can depend on System.Collections, if the framework is .netCore.
Paket has had this behaviour since day 1 and I love it. It's really powerful and correct to not have to re-install your nuget packages every time you switch frameworks.
So all that works.
But then paket looks at System.Collections, sees it only has assemblies for .netcore and not .net452 as currently selected, and prints the warning.
I come down hard on warnings in general, warning fatigue hides real problems. So I don't want spurious warnings.
But System.Collections isn't even going to be brought in as a dependency when we're building for .net452.
So the build would work - because we don't need System.Collections with this configuration, but the warning implies it won't.
So that's the warning issue. If that makes sense. I can try to explain another way if you like.
Paket now creates an "AfterBuild" build step that copies dependencies to the output. This step is copying System.Collections to the output folder even tho it's not required in the current build.
More than that, if you then specify the output folder using /p:OutDir on the msbuild commandline, it fails to copy System.Collections. It looks like the build step builds the path of where it expects the output to be, but because we specify it directly, the build step gets the wrong path and can't find what it's after.
Which is messing our builds up :P
Now there is a workaround of sorts. Putting in Framework: >4.0
This helps for now.
There's another workaround:
The commandline version works normally because of the wonderful conditionals that paket adds to the csproj file that ensures that the right assemblies are referenced in the right situations.
But if you use
So if you change the framework, suddenly there's no assemblies being referenced.
There is an additional problem with the .wixproj files which I'm trying to pin down with a reproduction. Effectively it's looking like there are some conditionals being used that are always false, but right now I'm not sure.
To sum up.
(I've just noticed the latest version of paket doesn't fail the build as I discuss here, it successfully copies the unnecessary dependent assemblies into the wrong folder).