-
Notifications
You must be signed in to change notification settings - Fork 344
Update Cli, CoreFx, CoreFx, CoreFx, CoreFx, CoreFx, CoreSetup, CoreSetup to preview2-008311, preview2-26308-02, preview2-26308-02, preview2-26308-02, preview2-26308-02, preview2-26308-02, preview2-26307-02, preview2-26307-02, respectively (master) #2150
Update Cli, CoreFx, CoreFx, CoreFx, CoreFx, CoreFx, CoreSetup, CoreSetup to preview2-008311, preview2-26308-02, preview2-26308-02, preview2-26308-02, preview2-26308-02, preview2-26308-02, preview2-26307-02, preview2-26307-02, respectively (master) #2150
Conversation
f9cafde
to
fa9fecc
Compare
fa9fecc
to
362d5ea
Compare
362d5ea
to
c7b8683
Compare
c7b8683
to
28dbc80
Compare
…tup to preview2-008311, preview2-26308-02, preview2-26308-02, preview2-26308-02, preview2-26308-02, preview2-26308-02, preview2-26307-02, preview2-26307-02, respectively
28dbc80
to
1380f50
Compare
I am trying to react to the recent lifetime semantic changes to OwnedMemory from dotnet/corefx#27615 which is resulting in failing tests. However, I am seeing package version conflict warnings for System.Threading.Tasks.Extensions now.
This causes the System.IO.Pipelines.Extensions.Tests to abort:
Any ideas how to resolve this versioning conflict? It looks like us modifying the dependencies in System.Memory and System.IO.Pipelines may be causing this issue: We do not directly reference System.Threading.Tasks.Extensions anywhere in the corefxlab.sln. Currently failing tests (based on OwnedMemory lifetime semantics changes). Investigation pending:
|
Couldn't update this pull request: Head commit author 'Ahson Khan' is not 'dotnet-maestro-bot' |
Couldn't update this pull request: Head commit author 'Ahson Khan' is not 'dotnet-maestro-bot' |
1 similar comment
Couldn't update this pull request: Head commit author 'Ahson Khan' is not 'dotnet-maestro-bot' |
Couldn't update this pull request: Head commit author 'Ahson Khan' is not 'dotnet-maestro-bot' |
With this package update, I can't open the corefxlab solution in Visual Studio (VS crashes). This doesn't occur on master. It seems like something related to recent dependency changes (from this PR) is causing critical failures in VS (https://developercommunity.visualstudio.com/content/problem/210330/opening-a-large-solution-in-vs-causes-it-to-crash.html). This makes debugging the test failures a bit more difficult. Referencing 4.5.0-preview2-26308-02 (or higher) versions of the System.IO.Pipelines package that is causing the VS issue. If we revert that back down to 4.5.0-preview2-26305-02 while keeping all the other changes from this PR, Visual Studio doesn't crash. I am going to close this PR and wait for new updates. |
4.5.0-preview2-26305-02 is the last "working" System.IO.Pipelines package. I see VS crashes starting from https://dotnet.myget.org/feed/dotnet-core/package/nuget/System.IO.Pipelines/4.5.0-preview2-26306-04 (Tue, 06 Mar 2018 20:35:20 GMT). The only change that was checked in during this timeframe was dotnet/corefx#27615 |
What crashes? |
Opening the corefxlab solution file in Visual Studio causes it to hang and crash (if we reference the newer System.IO.Pipelines package). |
uhhhh what.. |
Yes, I know, it doesn't make much sense to me. I filed an issue to VS. Try it yourself - open corefxlab, it all works fine. I isolated it to the pipelines package. It isn't unique to my machine (I tried on a VM, uninstall/re-install VS, update it, etc.). |
I have a simplified repro of the crash:
Observe that VS will hang and eventually crash with stackoverflow error. Could there be a circular dependency for netstandard1.3? cc @davidfowl, @pakrym <Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>netstandard2.0</TargetFramework>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="System.IO.Pipelines" Version="4.5.0-preview2-26312-02" />
</ItemGroup>
</Project> See issue dotnet/project-system#3374 |
@davkean pointed me to a potential circular dependency in S.R.CS.U that is causing VS to crash (exposed by referencing System.IO.Pipelines): From the nuspec: <dependencies>
<group targetFramework=".NETFramework4.5" />
<group targetFramework=".NETStandard1.0">
<dependency id="NETStandard.Library" version="1.6.1" />
</group>
<group targetFramework=".NETStandard2.0" />
<group targetFramework=".NETPortable4.5-Profile259" />
<group targetFramework="Windows8.0" />
<group targetFramework="WindowsPhone8.0" />
<group targetFramework="WindowsPhoneApp8.1" />
</dependencies> cc @jkotas, @ericstj, @joperezr - can you please assist with the packaging fix here? Is there a circular dependency? |
However, I can't repro the crash with referencing S.R.CS.U. nuspec of System.IO.Pipelines: <group targetFramework=".NETStandard1.3">
<dependency id="NETStandard.Library" version="1.6.1" />
<dependency id="System.Buffers" version="4.5.0-preview2-26312-02" exclude="Compile" />
<dependency id="System.Memory" version="4.5.0-preview2-26312-02" />
<dependency id="System.Threading.Tasks.Extensions" version="4.5.0-preview2-26312-02" />
</group> |
Referencing System.Threading.Tasks.Extensions causes the hang: <group targetFramework=".NETStandard1.0">
<dependency id="System.Collections" version="4.3.0" exclude="Compile" />
<dependency id="System.Runtime" version="4.3.0" />
<dependency id="System.Runtime.CompilerServices.Unsafe" version="4.5.0-preview2-26313-01" exclude="Compile" />
<dependency id="System.Threading.Tasks" version="4.3.0" />
</group> cc @stephentoub |
A hang in what? |
Visual Studio hangs and then crashes with stack overflow error (when it tries to do the package restore). |
There's some sort of circular dependency in the graph that is causing us to stack overflow in VS. |
Actually I think this is graph that is circular:
|
@stephentoub - we added a reference to System.Runtime.CompilerServices.Unsafe from System.Threading.Tasks.Extensions here - https://github.com/dotnet/corefx/pull/27602/files#diff-e5a7b08a11c5aadf6854a1a64b865b9bR53 Should this be under the IsPartialFadaceAssembly condition? <ItemGroup Condition="'$(IsPartialFacadeAssembly)' != 'true'"> |
@ahsonkhan It is under |
Oops. You are right. I misread the csproj. |
cc @weshaggard
Observe that VS will hang and eventually crash with stackoverflow error. This will be fixed on the VS side, but we still need to address the issue on the packaging side. How can we resolve the potential circular dependency for netstandard1.3? <Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>netstandard2.0</TargetFramework>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="System.Threading.Tasks.Extensions" Version="4.5.0-preview2-26312-02" />
</ItemGroup>
</Project> |
@ahsonkhan this works fine from the command line. I do see one cycle but nuget handled it correctly: System.Threading.Tasks.Extensions -> System.Runtime.CompilerServices.Unsafe -> NETStandard.Library (1.6.1) -> System.Xml.ReaderWriter -> System.Threading.Tasks.Extensions @ericstj is this a cycle we should worry about? |
If it turns out it's a problem, we can remove the Unsafe reference from Extensions; it'll just mean the portable build isn't as efficient. That said, isn't System.Xml.ReaderWriter part of the netstandard implementation? Now that ValueTask exposed from System.Runtime, we can just drop the System.Threading.Tasks.Extensions reference from it, no? |
This is the older netstandard1.3 targets so those binaries are fixed and we aren't building them live and in netstandard1.3 System.Runtime didn't have ValueTask. |
Yes, we typically avoid these using SuppressMetaPackage. We should add that to Unsafe. I have validation that will catch this sort of thing but it doesn't run during the build: https://github.com/dotnet/corefx/tree/master/pkg/test. /CC @joperezr |
Fixed in dotnet/corefx#28042 |
/cc @dotnet/corefxlab-contrib