You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
All my projects are currently targeting .NET Framework 4.x. The number of transitive dependencies more than doubles in my projects if I begin references an updated library that supports DotNET 5.0.
Yes ms is starting to ship the framework as nuget packages. What do you
propose?
On Sep 15, 2015 10:55 PM, "Cameron Taggart" notifications@github.com
wrote:
All my projects are currently targeting .NET Framework 4.x. The number of
transitive dependencies more than doubles in my projects if I begin
references an updated library that supports DotNET 5.0.
For example, trying out a newer FsCheck, pulls in
xunit.extensibility.execution, which pulls in the .NET 5.x world:
Yes it seems fluentassertions 4 is dependent on the whole Internet. No sure
what we can do about it. Maybe send pr to the lib with more restrictions.
On Sep 17, 2015 1:46 PM, "Eugen Richter" notifications@github.com wrote:
Framework restrictions doesn't work. Have the same problem with FluentAssertions
4.x library.
This issue causes me lots of trouble- indeed framework restrictions don't seem to do anything. Not clear why they even exist and what actually changes when you specify any.
The biggest problem is not even Paket downloading binaries for all exotic platforms we could not care less about. Real problem is that all those binaries get referenced from the projects. Conditionally referenced, I understand, but still their presence is not benign. I'm yet to figure out how exactly they get in he way, but we end up with the ton of warnings about inability to resolve assembly version conflict during the build.
Is it possible not to add excluded platforms to projects during "Paket install" process?
Also they can't affect the build at all as MSBuild completly ignore them.
Warnings about assembly version conflicts are most often due to a .Net 4.5 project referencing a .Net 4.0 project, both of them referencing the same Dll.
The problem is that you end up with a reference graph like that :
+ ProjectA net45
| - Lib in ...\Lib\lib\net45\Lib.dll
| + Project B net40
| | - Lib in ...\Lib\lib\net40\Lib.dll
And msbuild doesn't like it. It's exactly the same problem in nuget BTW, it's not specific to paket.
The solution is to edit the net45 project file by hand to make it reference the net40 dll.
To do it, take the nodes generated by paket and remove both the Choose, When and Paket elements. Paket will recognize that you added the package references manually and won't try to add his own again :
<ItemGroup>
<!-- Paket packages added manually to force net40 version -->
<ReferenceInclude="FluentAssertions.Core">
<HintPath>..\packages\FluentAssertions\lib\net40\FluentAssertions.Core.dll</HintPath>
<Private>True</Private>
</Reference>
<ReferenceInclude="FluentAssertions">
<HintPath>..\packages\FluentAssertions\lib\net40\FluentAssertions.dll</HintPath>
<Private>True</Private>
</Reference>
</ItemGroup>
I will definitely experiment more tomorrow, but I would like to clarify one detail documentation is not clear about:
What is the relationship between framework restriction specified at the top of Paket.dependencies file and the one specified directly on the particular package? Is one of them overriding another or they get combined somehow?
As far as I understand framework restriction at the top supposed to specify framework(s) the solution is actually targeting. But what is the point to restrict framework for particular package without applying the same restriction to other packages?
@konstehttps://github.com/konste Except if there was a regression, specifying framework on an element should add only the referenced framework in the .*proj files.
Also they can't affect the build at all as MSBuild completly ignore them.
Warnings about assembly version conflicts are most often due to a .Net 4.5 project referencing a .Net 4.0 project, both of them referencing the same Dll.
The problem is that you end up with a reference graph like that :
ProjectA net45
| - Lib in ...\Lib\lib\net45\Lib.dll
| + Project B net40
| | - Lib in ...\Lib\lib\net40\Lib.dll
And msbuild doesn't like it. It's exactly the same problem in nuget BTW, it's not specific to paket.
The solution is to edit the net45 project file by hand to make it reference the net40 dll.
To do it, take the nodes generated by paket and remove both the Choose, When and Paket elements. Paket will recognize that you added the package references manually and won't try to add his own again :
Another question is how framework restriction specified for directly referenced package is propagated (?) to transitive dependencies not specified in Packet.dependencies, but resolved in Paket.lock. I was under impression that three BCL packages brought in as indirect dependencies are all referenced with all their supported platforms.
@konstehttps://github.com/konste Except if there was a regression, specifying framework on an element should add only the referenced framework in the .*proj files.
Also they can't affect the build at all as MSBuild completly ignore them.
Warnings about assembly version conflicts are most often due to a .Net 4.5 project referencing a .Net 4.0 project, both of them referencing the same Dll.
The problem is that you end up with a reference graph like that :
ProjectA net45
| - Lib in ...\Lib\lib\net45\Lib.dll
| + Project B net40
| | - Lib in ...\Lib\lib\net40\Lib.dll
And msbuild doesn't like it. It's exactly the same problem in nuget BTW, it's not specific to paket.
The solution is to edit the net45 project file by hand to make it reference the net40 dll.
To do it, take the nodes generated by paket and remove both the Choose, When and Paket elements. Paket will recognize that you added the package references manually and won't try to add his own again :
This is great (and timely!), but while we are at it could you please answer my two questions I asked above? To save time I repeat them here:
What is the relationship between framework restriction specified at the top of Paket.dependencies file and the one specified directly on the particular package? Is one of them overriding another or they get combined somehow? As far as I understand framework restriction at the top supposed to specify framework(s) the solution is actually targeting. But what is the point to restrict framework for particular package without applying the same restriction to other packages?
Another question is how framework restriction specified for directly referenced package is propagated (?) to transitive dependencies not specified in Packet.dependencies, but resolved in Paket.lock. I was under impression that three BCL packages brought in as indirect dependencies are all referenced with all their supported platforms.
What is the relationship between framework restriction specified at the top of Paket.dependencies file and the one specified directly on the particular package?
Is one of them overriding another or they get combined somehow?
yes they are combined.
But what is the point to restrict framework for particular package without applying the same restriction to other packages?
sometimes only a single package makes trouble.
how framework restriction specified for directly referenced package is propagated
yes they should propagate to transisitv dependencies. I also fixed a little bit of these settings
Activity
forki commentedon Sep 15, 2015
Yes ms is starting to ship the framework as nuget packages. What do you
propose?
On Sep 15, 2015 10:55 PM, "Cameron Taggart" notifications@github.com
wrote:
ctaggart commentedon Sep 15, 2015
I don't know yet. I just don't want all of .NET 5 Framework downloaded if I am not using it.
forki commentedon Sep 16, 2015
did you try to set framework restrictions? http://fsprojects.github.io/Paket/nuget-dependencies.html#Framework-restrictions
WebDucer commentedon Sep 17, 2015
Framework restrictions doesn't work. Have the same problem with
FluentAssertions 4.xlibrary.nuget FluentAssertions framework: net40, net45In this case I pinned to the previous
3.5version, to prevent this.forki commentedon Sep 17, 2015
Yes it seems fluentassertions 4 is dependent on the whole Internet. No sure
what we can do about it. Maybe send pr to the lib with more restrictions.
On Sep 17, 2015 1:46 PM, "Eugen Richter" notifications@github.com wrote:
vbfox commentedon Sep 21, 2015
All the dependencies are in a section of the
.nuspecthat specifies the framework :It seem like a good feature for paket to not even download the dependencies if it is framework restricted in the dependencies file :
konste commentedon Sep 22, 2015
This issue causes me lots of trouble- indeed framework restrictions don't seem to do anything. Not clear why they even exist and what actually changes when you specify any.
The biggest problem is not even Paket downloading binaries for all exotic platforms we could not care less about. Real problem is that all those binaries get referenced from the projects. Conditionally referenced, I understand, but still their presence is not benign. I'm yet to figure out how exactly they get in he way, but we end up with the ton of warnings about inability to resolve assembly version conflict during the build.
Is it possible not to add excluded platforms to projects during "Paket install" process?
vbfox commentedon Sep 22, 2015
@konste Except if there was a regression, specifying
frameworkon an element should add only the referenced framework in the.*projfiles.For me with a paket.dependencies of :
I only get 2 conditional blocks, one for each platform (Removing the framework limitation generates a lot more) :
Also they can't affect the build at all as MSBuild completly ignore them.
Warnings about assembly version conflicts are most often due to a .Net 4.5 project referencing a .Net 4.0 project, both of them referencing the same Dll.
The problem is that you end up with a reference graph like that :
And msbuild doesn't like it. It's exactly the same problem in nuget BTW, it's not specific to paket.
The solution is to edit the net45 project file by hand to make it reference the net40 dll.
To do it, take the nodes generated by paket and remove both the
Choose,WhenandPaketelements. Paket will recognize that you added the package references manually and won't try to add his own again :konste commentedon Sep 22, 2015
I will definitely experiment more tomorrow, but I would like to clarify one detail documentation is not clear about:
What is the relationship between framework restriction specified at the top of Paket.dependencies file and the one specified directly on the particular package? Is one of them overriding another or they get combined somehow?
As far as I understand framework restriction at the top supposed to specify framework(s) the solution is actually targeting. But what is the point to restrict framework for particular package without applying the same restriction to other packages?
< sent from mobile device >
On Sep 21, 2015, at 11:55 PM, Julien Roncaglia <notifications@github.commailto:notifications@github.com> wrote:
@konstehttps://github.com/konste Except if there was a regression, specifying framework on an element should add only the referenced framework in the .*proj files.
For me with a paket.dependencies of :
source https://nuget.org/api/v2
nuget FluentAssertions framework: net40, net45
I only get 2 conditional blocks, one for each platform :
..\packages\FluentAssertions\lib\net40\FluentAssertions.Core.dll True True ..\packages\FluentAssertions\lib\net40\FluentAssertions.dll True True ..\packages\FluentAssertions\lib\net45\FluentAssertions.Core.dll True True ..\packages\FluentAssertions\lib\net45\FluentAssertions.dll True TrueAlso they can't affect the build at all as MSBuild completly ignore them.
Warnings about assembly version conflicts are most often due to a .Net 4.5 project referencing a .Net 4.0 project, both of them referencing the same Dll.
The problem is that you end up with a reference graph like that :
| - Lib in ...\Lib\lib\net45\Lib.dll
| + Project B net40
| | - Lib in ...\Lib\lib\net40\Lib.dll
And msbuild doesn't like it. It's exactly the same problem in nuget BTW, it's not specific to paket.
The solution is to edit the net45 project file by hand to make it reference the net40 dll.
..\packages\FluentAssertions\lib\net40\FluentAssertions.Core.dll True ..\packages\FluentAssertions\lib\net40\FluentAssertions.dll TrueTo do it, take the nodes generated by paket and remove both the Choose, When and Paket elements. Paket will recognize that you added the package references manually and won't try to add his own again :
Reply to this email directly or view it on GitHubhttps://github.com//issues/1066#issuecomment-142196322.
konste commentedon Sep 22, 2015
Another question is how framework restriction specified for directly referenced package is propagated (?) to transitive dependencies not specified in Packet.dependencies, but resolved in Paket.lock. I was under impression that three BCL packages brought in as indirect dependencies are all referenced with all their supported platforms.
< sent from mobile device >
On Sep 21, 2015, at 11:55 PM, Julien Roncaglia <notifications@github.commailto:notifications@github.com> wrote:
@konstehttps://github.com/konste Except if there was a regression, specifying framework on an element should add only the referenced framework in the .*proj files.
For me with a paket.dependencies of :
source https://nuget.org/api/v2
nuget FluentAssertions framework: net40, net45
I only get 2 conditional blocks, one for each platform :
..\packages\FluentAssertions\lib\net40\FluentAssertions.Core.dll True True ..\packages\FluentAssertions\lib\net40\FluentAssertions.dll True True ..\packages\FluentAssertions\lib\net45\FluentAssertions.Core.dll True True ..\packages\FluentAssertions\lib\net45\FluentAssertions.dll True TrueAlso they can't affect the build at all as MSBuild completly ignore them.
Warnings about assembly version conflicts are most often due to a .Net 4.5 project referencing a .Net 4.0 project, both of them referencing the same Dll.
The problem is that you end up with a reference graph like that :
| - Lib in ...\Lib\lib\net45\Lib.dll
| + Project B net40
| | - Lib in ...\Lib\lib\net40\Lib.dll
And msbuild doesn't like it. It's exactly the same problem in nuget BTW, it's not specific to paket.
The solution is to edit the net45 project file by hand to make it reference the net40 dll.
..\packages\FluentAssertions\lib\net40\FluentAssertions.Core.dll True ..\packages\FluentAssertions\lib\net40\FluentAssertions.dll TrueTo do it, take the nodes generated by paket and remove both the Choose, When and Paket elements. Paket will recognize that you added the package references manually and won't try to add his own again :
Reply to this email directly or view it on GitHubhttps://github.com//issues/1066#issuecomment-142196322.
forki commentedon Sep 22, 2015
Paket should now filter out that dnx crap.
konste commentedon Sep 22, 2015
This is great (and timely!), but while we are at it could you please answer my two questions I asked above? To save time I repeat them here:
What is the relationship between framework restriction specified at the top of Paket.dependencies file and the one specified directly on the particular package? Is one of them overriding another or they get combined somehow? As far as I understand framework restriction at the top supposed to specify framework(s) the solution is actually targeting. But what is the point to restrict framework for particular package without applying the same restriction to other packages?
Another question is how framework restriction specified for directly referenced package is propagated (?) to transitive dependencies not specified in Packet.dependencies, but resolved in Paket.lock. I was under impression that three BCL packages brought in as indirect dependencies are all referenced with all their supported platforms.
forki commentedon Sep 22, 2015
yes they are combined.
sometimes only a single package makes trouble.
yes they should propagate to transisitv dependencies. I also fixed a little bit of these settings