Don't display unnecessary warning if no target framework is defined

[dcorriveau-omniscient]

Related to changes in /issues/1442
The warning seems to display even when it shouldn't, we might need to be more restrictive about it.
X contains libraries, but not for the selected TargetFramework net452 in project Y

For example, I have a solution with projects that target net452, and I don't define any version or framework requirements in the dependencies file. I still get tons of warning for libraries such as Microsoft.CSharp, Microsoft.Net.Http or System.Net.Http.

[forki]

But the message is correct in this case, right?

[dcorriveau-omniscient]

I don't know what's the right solution for this. But I do know that I don't want tons of warnings in the output window as soon as I add a reference like EntityFramework. At the same time we want the warnings when VS is failing to import dependent assemblies when there is a framework mismatch.

[forki]

what happens when you enable http://fsprojects.github.io/Paket/dependencies-file.html#Automatic-framework-detection ?

[dcorriveau-omniscient]

When I paket update I get the error
Could not detect target framework for project x.csproj
and it stops the process

Edit: That x.csproj in actually located in \packages\System.Net.FtpClient\source\System.Net.FtpClient.csproj

[forki]

ouch. that's clearly a bug ;-)

[forki]

please retry

[matthid]

I get a warning when paket update on FSharp.Formatting

Package Microsoft.AspNet.Razor contains libraries, but not for the selected TargetFramework net40 in project C:\PROJ\FSharp.Formatting\tests\FSharp.MetadataFormat.Tests\files\crefLib\crefLib1.fsproj.

The point is that the project is not even referencing the package. I think this is related to the fact that paket chooses the paket.references from the upper directory. Until now we never cared (besides some additional references nothing happened), but now we get several warnings.

Maybe its time to add an empty paket.references file. (This is just to let others know if they stumble over this issue for the same reason)

[forki]

I think non-existing paket.references is same as empty file. So the issue is elsewhere

[matthid]

I'm pretty sure it's not: Paket searches up the directories until it finds a paket.references file and uses that. (If you say this is a bug that would be nice, because I never liked that behavior anyway; but this is a (possibly huge) breaking change). Paket does this for quite some time now.

[forki]

Ah you are right. That was a drunk decision :-)
On Feb 4, 2016 20:46, "Matthias Dittrich" notifications@github.com wrote:

I'm pretty sure it's not: Paket searches up the directories until it finds
a paket.references file and uses that. (If you say this is a bug that
would be nice, because I never liked that behavior anyway; but this is a
(possibly huge) breaking change). Paket does this for quite some time now.

—
Reply to this email directly or view it on GitHub
#1455 (comment).

[dcorriveau-omniscient]

please retry

Same thing :(

[forki]

Yeah. Damn it. I can't reproduce it.
On Feb 4, 2016 21:34, "dcorriveau-omniscient" notifications@github.com
wrote:

please retry

Same thing :(

—
Reply to this email directly or view it on GitHub
#1455 (comment).

[dcorriveau-omniscient]

Did you try with a reference to System.Net.FtpClient ?

[forki]

Yes. But it doesn't pick the csproj up. Need to investigate deeper. Or can
you give me a mini repro?
I know this is far away from the original issue ;-)
On Feb 4, 2016 21:55, "dcorriveau-omniscient" notifications@github.com
wrote:

Did you try with a reference to System.Net.FtpClient ?

—
Reply to this email directly or view it on GitHub
#1455 (comment).