-
Notifications
You must be signed in to change notification settings - Fork 525
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
Ignore DotNET 5.0 framework? #1066
Comments
Yes ms is starting to ship the framework as nuget packages. What do you
|
I don't know yet. I just don't want all of .NET 5 Framework downloaded if I am not using it. |
did you try to set framework restrictions? http://fsprojects.github.io/Paket/nuget-dependencies.html#Framework-restrictions |
Framework restrictions doesn't work. Have the same problem with
In this case I pinned to the previous |
Yes it seems fluentassertions 4 is dependent on the whole Internet. No sure
|
All the dependencies are in a section of the <dependencies>
<group targetFramework=".NETFramework4.0" />
<group targetFramework="Silverlight5.0" />
<group targetFramework="Windows8.0" />
<group targetFramework="WindowsPhone8.0" />
<group targetFramework="WindowsPhoneApp8.1" />
<group targetFramework="Xamarin.iOS0.0" />
<group targetFramework="MonoTouch0.0" />
<group targetFramework="MonoAndroid0.0" />
<group targetFramework=".NETPortable0.0-net40+sl5+win8+wp8+wpa81" />
<group targetFramework=".NETPlatform5.0">
<dependency id="System.Collections" version="4.0.10" />
<dependency id="System.Diagnostics.Debug" version="4.0.10" />
<dependency id="System.Globalization" version="4.0.10" />
<dependency id="System.Linq" version="4.0.0" />
<dependency id="System.Linq.Expressions" version="4.0.10" />
<dependency id="System.ObjectModel" version="4.0.10" />
<dependency id="System.Reflection" version="4.0.10" />
<dependency id="System.Reflection.Extensions" version="4.0.0" />
<dependency id="System.Reflection.Primitives" version="4.0.0" />
<dependency id="System.Reflection.TypeExtensions" version="4.0.0" />
<dependency id="System.Runtime" version="4.0.20" />
<dependency id="System.Runtime.Extensions" version="4.0.10" />
<dependency id="System.Text.RegularExpressions" version="4.0.10" />
<dependency id="System.Threading" version="4.0.10" />
<dependency id="System.Threading.Tasks" version="4.0.10" />
<dependency id="System.Xml.XDocument" version="4.0.10" />
</group>
</dependencies> It seem like a good feature for paket to not even download the dependencies if it is framework restricted in the dependencies file :
|
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? |
@konste Except if there was a regression, specifying 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) : <Choose>
<When Condition="$(TargetFrameworkIdentifier) == '.NETFramework' And $(TargetFrameworkVersion) == 'v4.0'">
<ItemGroup>
<Reference Include="FluentAssertions.Core">
<HintPath>..\packages\FluentAssertions\lib\net40\FluentAssertions.Core.dll</HintPath>
<Private>True</Private>
<Paket>True</Paket>
</Reference>
<Reference Include="FluentAssertions">
<HintPath>..\packages\FluentAssertions\lib\net40\FluentAssertions.dll</HintPath>
<Private>True</Private>
<Paket>True</Paket>
</Reference>
</ItemGroup>
</When>
<When Condition="$(TargetFrameworkIdentifier) == '.NETFramework' And $(TargetFrameworkVersion) == 'v4.5'">
<ItemGroup>
<Reference Include="FluentAssertions.Core">
<HintPath>..\packages\FluentAssertions\lib\net45\FluentAssertions.Core.dll</HintPath>
<Private>True</Private>
<Paket>True</Paket>
</Reference>
<Reference Include="FluentAssertions">
<HintPath>..\packages\FluentAssertions\lib\net45\FluentAssertions.dll</HintPath>
<Private>True</Private>
<Paket>True</Paket>
</Reference>
</ItemGroup>
</When>
</Choose> 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. <ItemGroup>
<!-- Paket packages added manually to force net40 version -->
<Reference Include="FluentAssertions.Core">
<HintPath>..\packages\FluentAssertions\lib\net40\FluentAssertions.Core.dll</HintPath>
<Private>True</Private>
</Reference>
<Reference Include="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? < sent from mobile device > On Sep 21, 2015, at 11:55 PM, Julien Roncaglia <[email protected]mailto:[email protected]> 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 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 :
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. Reply to this email directly or view it on GitHubhttps://github.com//issues/1066#issuecomment-142196322. |
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 <[email protected]mailto:[email protected]> 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 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 :
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. Reply to this email directly or view it on GitHubhttps://github.com//issues/1066#issuecomment-142196322. |
Paket should now filter out that dnx crap. |
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. |
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 |
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:https://www.nuget.org/packages/xunit.extensibility.execution/2.1.0-rc1-build3168
It would be awesome if I could specify the frameworks that I cared about.
The text was updated successfully, but these errors were encountered: