Skip to content
This repository has been archived by the owner on Aug 2, 2023. It is now read-only.

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

dotnet-maestro-bot
Copy link
Contributor

@dotnet-maestro-bot dotnet-maestro-bot commented Mar 6, 2018

/cc @dotnet/corefxlab-contrib

@dotnet-maestro-bot dotnet-maestro-bot changed the title Update CoreFx, CoreFx, CoreFx, CoreFx, CoreFx to preview2-26306-04, preview2-26306-04, preview2-26306-04, preview2-26306-04, preview2-26306-04, respectively (master) Update CoreFx, CoreFx, CoreFx, CoreFx, CoreFx to preview2-26307-01, preview2-26307-01, preview2-26307-01, preview2-26307-01, preview2-26307-01, respectively (master) Mar 7, 2018
@dotnet-maestro-bot dotnet-maestro-bot force-pushed the master-UpdateDependencies branch 2 times, most recently from f9cafde to fa9fecc Compare March 7, 2018 02:53
@dotnet-maestro-bot dotnet-maestro-bot changed the title Update CoreFx, CoreFx, CoreFx, CoreFx, CoreFx to preview2-26307-01, preview2-26307-01, preview2-26307-01, preview2-26307-01, preview2-26307-01, respectively (master) Update CoreFx, CoreFx, CoreFx, CoreFx, CoreFx, CoreSetup, CoreSetup to preview2-26307-03, preview2-26307-03, preview2-26307-03, preview2-26307-03, preview2-26307-03, preview2-26307-01, preview2-26307-01, respectively (master) Mar 7, 2018
@dotnet-maestro-bot dotnet-maestro-bot changed the title Update CoreFx, CoreFx, CoreFx, CoreFx, CoreFx, CoreSetup, CoreSetup to preview2-26307-03, preview2-26307-03, preview2-26307-03, preview2-26307-03, preview2-26307-03, preview2-26307-01, preview2-26307-01, respectively (master) Update CoreFx, CoreFx, CoreFx, CoreFx, CoreFx, CoreSetup, CoreSetup to preview2-26307-06, preview2-26307-06, preview2-26307-06, preview2-26307-06, preview2-26307-06, preview2-26307-02, preview2-26307-02, respectively (master) Mar 7, 2018
@dotnet-maestro-bot dotnet-maestro-bot force-pushed the master-UpdateDependencies branch from fa9fecc to 362d5ea Compare March 7, 2018 15:04
@dotnet-maestro-bot dotnet-maestro-bot changed the title Update CoreFx, CoreFx, CoreFx, CoreFx, CoreFx, CoreSetup, CoreSetup to preview2-26307-06, preview2-26307-06, preview2-26307-06, preview2-26307-06, preview2-26307-06, preview2-26307-02, preview2-26307-02, respectively (master) Update CoreFx, CoreFx, CoreFx, CoreFx, CoreFx, CoreSetup, CoreSetup to preview2-26308-01, preview2-26308-01, preview2-26308-01, preview2-26308-01, preview2-26308-01, preview2-26307-02, preview2-26307-02, respectively (master) Mar 8, 2018
@dotnet-maestro-bot dotnet-maestro-bot force-pushed the master-UpdateDependencies branch from 362d5ea to c7b8683 Compare March 8, 2018 02:26
@dotnet-maestro-bot dotnet-maestro-bot changed the title Update CoreFx, CoreFx, CoreFx, CoreFx, CoreFx, CoreSetup, CoreSetup to preview2-26308-01, preview2-26308-01, preview2-26308-01, preview2-26308-01, preview2-26308-01, preview2-26307-02, preview2-26307-02, respectively (master) Update CoreFx, CoreFx, CoreFx, CoreFx, CoreFx, CoreSetup, CoreSetup to preview2-26308-02, preview2-26308-02, preview2-26308-02, preview2-26308-02, preview2-26308-02, preview2-26307-02, preview2-26307-02, respectively (master) Mar 8, 2018
@dotnet-maestro-bot dotnet-maestro-bot force-pushed the master-UpdateDependencies branch from c7b8683 to 28dbc80 Compare March 8, 2018 03:04
…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
@dotnet-maestro-bot dotnet-maestro-bot changed the title Update CoreFx, CoreFx, CoreFx, CoreFx, CoreFx, CoreSetup, CoreSetup to preview2-26308-02, preview2-26308-02, preview2-26308-02, preview2-26308-02, preview2-26308-02, preview2-26307-02, preview2-26307-02, respectively (master) 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) Mar 8, 2018
@dotnet-maestro-bot dotnet-maestro-bot force-pushed the master-UpdateDependencies branch from 28dbc80 to 1380f50 Compare March 8, 2018 04:26
@ahsonkhan
Copy link
Member

ahsonkhan commented Mar 8, 2018

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.

D:\GitHub\Fork\corefxlab\dotnetcli\sdk\2.1.300-preview2-008304\Microsoft.Common.CurrentVersion.targets(2053,5): warning MSB3277: Found conflicts between different versions of "System.Threading.Tasks.Extensions" that could not be resolved.  These reference conflicts are listed in the build log when log verbosity is set to detailed. [D:\GitHub\Fork\corefxlab\tests\System.Buffers.Experimental.Tests\System.Buffers.Experimental.Tests.csproj]
D:\GitHub\Fork\corefxlab\dotnetcli\sdk\2.1.300-preview2-008304\Microsoft.Common.CurrentVersion.targets(2053,5): warning MSB3277: Found conflicts between different versions of "System.Threading.Tasks.Extensions" that could not be resolved.  These reference conflicts are listed in the build log when log verbosity is set to detailed. [D:\GitHub\Fork\corefxlab\tests\Benchmarks\Benchmarks.csproj]
D:\GitHub\Fork\corefxlab\dotnetcli\sdk\2.1.300-preview2-008304\Microsoft.Common.CurrentVersion.targets(2053,5): warning MSB3277: Found conflicts between different versions of "System.Threading.Tasks.Extensions" that could not be resolved.  These reference conflicts are listed in the build log when log verbosity is set to detailed. [D:\GitHub\Fork\corefxlab\tests\System.IO.Pipelines.Extensions.Tests\System.IO.Pipelines.Extensions.Tests.csproj]
D:\GitHub\Fork\corefxlab\dotnetcli\sdk\2.1.300-preview2-008304\Microsoft.Common.CurrentVersion.targets(2053,5): warning MSB3277: Found conflicts between different versions of "System.Threading.Tasks.Extensions" that could not be resolved.  These reference conflicts are listed in the build log when log verbosity is set to detailed. [D:\GitHub\Fork\corefxlab\samples\System.IO.Pipelines.Samples\System.IO.Pipelines.Samples.csproj]

This causes the System.IO.Pipelines.Extensions.Tests to abort:

[xUnit.net 00:00:00.7504685]   Starting:    System.IO.Pipelines.Extensions.Tests
The active test run was aborted. Reason: Unhandled Exception: System.IO.FileNotFoundException: Could not load file or assembly 'System.Threading.Tasks.Extensions, Version=4.2.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'. The system cannot find the file specified.
   at System.IO.Pipelines.Networking.Libuv.UvTcpConnection.ProcessWrites()
   at System.IO.Pipelines.Networking.Libuv.UvTcpConnection..ctor(UvThread thread, UvTcpHandle handle) in D:\GitHub\Fork\corefxlab\src\System.IO.Pipelines.Networking.Libuv\UvTcpConnection.cs:line 40
   at System.IO.Pipelines.Networking.Libuv.UvTcpListener.OnConnectionCallback(UvStreamHandle listenSocket, Int32 status, Exception error, Object state) in D:\GitHub\Fork\corefxlab\src\System.IO.Pipelines.Networking.Libuv\UvTcpListener.cs:line 78
   at System.IO.Pipelines.Networking.Libuv.Interop.UvStreamHandle.UvConnectionCb(IntPtr handle, Int32 status) in D:\GitHub\Fork\corefxlab\src\System.IO.Pipelines.Networking.Libuv\Interop\UvStreamHandle.cs:line 125
   at System.IO.Pipelines.Networking.Libuv.Interop.UvStreamHandle.<>c.<.cctor>b__20_0(IntPtr handle, Int32 status) in D:\GitHub\Fork\corefxlab\src\System.IO.Pipelines.Networking.Libuv\Interop\UvStreamHandle.cs:line 10
   at System.IO.Pipelines.Networking.Libuv.Interop.Uv.NativeMethods.uv_run(UvLoopHandle handle, Int32 mode)
   at System.IO.Pipelines.Networking.Libuv.Interop.Uv.run(UvLoopHandle handle, Int32 mode) in D:\GitHub\Fork\corefxlab\src\System.IO.Pipelines.Networking.Libuv\Interop\Uv.cs:line 115
   at System.IO.Pipelines.Networking.Libuv.UvThread.RunLoop() in D:\GitHub\Fork\corefxlab\src\System.IO.Pipelines.Networking.Libuv\UvThread.cs:line 79
   at System.IO.Pipelines.Networking.Libuv.UvThread.OnStart(Object state) in D:\GitHub\Fork\corefxlab\src\System.IO.Pipelines.Networking.Libuv\UvThread.cs:line 64
   at System.Threading.Thread.ThreadMain_ParameterizedThreadStart(Object parameter)
   at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state)
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()


Test Run Aborted.
D:\GitHub\Fork\corefxlab\scripts\build.ps1 : Some tests failed in project D:\GitHub\Fork\corefxlab\scripts\..\tests\System.IO.Pipelines.Extensions.Tests\System.IO.Pipelines.Extensions.Tests.csproj

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:
https://github.com/dotnet/corefx/pull/27615/files#diff-a9d5364f37b334f095a4dc80aa3a5c1dR150
https://github.com/dotnet/corefx/pull/27651/files#diff-70dbe05f71c9cdb96d923da8593b1f49R21

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:

Failed   System.Buffers.Tests.BufferReferenceUnitTests.AutoPooledBufferReferenceTests
Error Message:
 System.InvalidOperationException : Operation is not valid due to the current state of the object.
Stack Trace:
   at System.BuffersExperimentalThrowHelper.ThrowInvalidOperationException() in D:\GitHub\Fork\corefxlab\src\System.Buffers.Experimental\System\Runtime\BuffersExperimentalThrowHelper.cs:line 39
   at System.Buffers.Native.ReferenceCountedMemory`1.Release() in D:\GitHub\Fork\corefxlab\src\System.Buffers.Experimental\System\Buffers\Native\ReferenceCountedMemory.cs:line 23
   at System.Buffers.Tests.BufferReferenceTests.BufferLifetimeBasics(OwnedMemory`1 buffer) in D:\GitHub\Fork\corefxlab\tests\System.Buffers.Primitives.Tests\BufferReferenceTesting.cs:line 183
   at System.Buffers.Tests.BufferReferenceTests.RunTest(Action`1 test, Func`1 create, Action`1 dispose) in D:\GitHub\Fork\corefxlab\tests\System.Buffers.Primitives.Tests\BufferReferenceTesting.cs:line 29
   at System.Buffers.Tests.BufferReferenceTests.TestOwnedBuffer(Func`1 create, Action`1 dispose) in D:\GitHub\Fork\corefxlab\tests\System.Buffers.Primitives.Tests\BufferReferenceTesting.cs:line 13
   at System.Buffers.Tests.BufferReferenceUnitTests.AutoPooledBufferReferenceTests() in D:\GitHub\Fork\corefxlab\tests\System.Buffers.Experimental.Tests\BufferReferenceTests.cs:line 20
Failed   System.Buffers.Tests.BufferReferenceUnitTests.CustomBufferReferenceTests
Error Message:
 System.InvalidOperationException : Operation is not valid due to the current state of the object.
Stack Trace:
   at System.Buffers.Tests.CustomBuffer`1.Release() in D:\GitHub\Fork\corefxlab\tests\System.Buffers.Experimental.Tests\MemoryTests.cs:line 255
   at System.Buffers.Tests.BufferReferenceTests.BufferLifetimeBasics(OwnedMemory`1 buffer) in D:\GitHub\Fork\corefxlab\tests\System.Buffers.Primitives.Tests\BufferReferenceTesting.cs:line 183
   at System.Buffers.Tests.BufferReferenceTests.RunTest(Action`1 test, Func`1 create, Action`1 dispose) in D:\GitHub\Fork\corefxlab\tests\System.Buffers.Primitives.Tests\BufferReferenceTesting.cs:line 29
   at System.Buffers.Tests.BufferReferenceTests.TestOwnedBuffer(Func`1 create, Action`1 dispose) in D:\GitHub\Fork\corefxlab\tests\System.Buffers.Primitives.Tests\BufferReferenceTesting.cs:line 13
   at System.Buffers.Tests.BufferReferenceUnitTests.CustomBufferReferenceTests() in D:\GitHub\Fork\corefxlab\tests\System.Buffers.Experimental.Tests\BufferReferenceTests.cs:line 28
Failed   System.Buffers.Tests.BufferReferenceUnitTests.AutoDisposeBufferReferenceTests
Error Message:
 System.InvalidOperationException : Operation is not valid due to the current state of the object.
Stack Trace:
   at System.BuffersExperimentalThrowHelper.ThrowInvalidOperationException() in D:\GitHub\Fork\corefxlab\src\System.Buffers.Experimental\System\Runtime\BuffersExperimentalThrowHelper.cs:line 39
   at System.Buffers.Native.ReferenceCountedMemory`1.Release() in D:\GitHub\Fork\corefxlab\src\System.Buffers.Experimental\System\Buffers\Native\ReferenceCountedMemory.cs:line 23
   at System.Buffers.Tests.BufferReferenceTests.BufferLifetimeBasics(OwnedMemory`1 buffer) in D:\GitHub\Fork\corefxlab\tests\System.Buffers.Primitives.Tests\BufferReferenceTesting.cs:line 183
   at System.Buffers.Tests.BufferReferenceTests.RunTest(Action`1 test, Func`1 create, Action`1 dispose) in D:\GitHub\Fork\corefxlab\tests\System.Buffers.Primitives.Tests\BufferReferenceTesting.cs:line 29
   at System.Buffers.Tests.BufferReferenceTests.TestOwnedBuffer(Func`1 create, Action`1 dispose) in D:\GitHub\Fork\corefxlab\tests\System.Buffers.Primitives.Tests\BufferReferenceTesting.cs:line 13
   at System.Buffers.Tests.BufferReferenceUnitTests.AutoDisposeBufferReferenceTests() in D:\GitHub\Fork\corefxlab\tests\System.Buffers.Experimental.Tests\BufferReferenceTests.cs:line 12
[xUnit.net 00:00:27.8454332]     System.Buffers.Tests.BufferReferenceUnitTests.PooledBufferReferenceTests [FAIL]
[xUnit.net 00:00:27.8456052]       System.InvalidOperationException : Release all references before disposing this instance.
[xUnit.net 00:00:27.8457179]       Stack Trace:
[xUnit.net 00:00:27.8457975]            at System.Buffers.OwnedMemory`1.Dispose()
[xUnit.net 00:00:27.8458921]         D:\GitHub\Fork\corefxlab\tests\System.Buffers.Primitives.Tests\BufferReferenceTesting.cs(123,0): at System.Buffers.Tests.BufferReferenceTests.Dispose(OwnedMemory`1 buffer)
[xUnit.net 00:00:27.8460818]         D:\GitHub\Fork\corefxlab\tests\System.Buffers.Primitives.Tests\BufferReferenceTesting.cs(29,0): at System.Buffers.Tests.BufferReferenceTests.RunTest(Action`1 test, Func`1 create, Action`1 dispose)
[xUnit.net 00:00:27.8462871]         D:\GitHub\Fork\corefxlab\tests\System.Buffers.Primitives.Tests\BufferReferenceTesting.cs(18,0): at System.Buffers.Tests.BufferReferenceTests.TestOwnedBuffer(Func`1 create, Action`1 dispose)
[xUnit.net 00:00:27.8464924]         D:\GitHub\Fork\corefxlab\tests\System.Buffers.Primitives.Tests\BufferReferenceTests.cs(20,0): at System.Buffers.Tests.BufferReferenceUnitTests.PooledBufferReferenceTests()
Failed   System.Text.Json.Tests.JsonObjectTests.ParseSimpleObject
Error Message:
 System.InvalidOperationException : Release all references before disposing this instance.
Stack Trace:
   at System.Buffers.OwnedMemory`1.Dispose()
   at System.Text.Json.JsonObject.Dispose() in D:\GitHub\Fork\corefxlab\src\System.Text.Json\System\Text\Json\JsonParseObject.cs:line 362
   at System.Text.Json.Tests.JsonObjectTests.ParseSimpleObject() in D:\GitHub\Fork\corefxlab\tests\System.Text.Json.Tests\JsonObjectTests.cs:line 64
Failed   System.Text.Json.Tests.JsonObjectTests.ParseArra

cc @KrzysztofCwalina, @davidfowl, @pakrym

@dotnet-maestro-bot
Copy link
Contributor Author

Couldn't update this pull request: Head commit author 'Ahson Khan' is not 'dotnet-maestro-bot'
Would have applied 'Update Cli, CoreFx, CoreFx, CoreFx, CoreFx, CoreFx, CoreSetup, CoreSetup to preview2-008315, preview2-26308-02, preview2-26308-02, preview2-26308-02, preview2-26308-02, preview2-26308-02, preview2-26307-02, preview2-26307-02, respectively'

@dotnet-maestro-bot
Copy link
Contributor Author

Couldn't update this pull request: Head commit author 'Ahson Khan' is not 'dotnet-maestro-bot'
Would have applied 'Update Cli, CoreFx, CoreFx, CoreFx, CoreFx, CoreFx, CoreSetup, CoreSetup to preview2-008315, preview2-26308-06, preview2-26308-06, preview2-26308-06, preview2-26308-06, preview2-26308-06, preview2-26308-01, preview2-26308-01, respectively'

1 similar comment
@dotnet-maestro-bot
Copy link
Contributor Author

Couldn't update this pull request: Head commit author 'Ahson Khan' is not 'dotnet-maestro-bot'
Would have applied 'Update Cli, CoreFx, CoreFx, CoreFx, CoreFx, CoreFx, CoreSetup, CoreSetup to preview2-008315, preview2-26308-06, preview2-26308-06, preview2-26308-06, preview2-26308-06, preview2-26308-06, preview2-26308-01, preview2-26308-01, respectively'

@dotnet-maestro-bot
Copy link
Contributor Author

Couldn't update this pull request: Head commit author 'Ahson Khan' is not 'dotnet-maestro-bot'
Would have applied 'Update Cli, CoreFx, CoreFx, CoreFx, CoreFx, CoreFx, CoreSetup, CoreSetup to preview2-008315, preview2-26308-09, preview2-26308-09, preview2-26308-09, preview2-26308-09, preview2-26308-09, preview2-26308-01, preview2-26308-01, respectively'

@ahsonkhan
Copy link
Member

ahsonkhan commented Mar 9, 2018

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.

@ahsonkhan ahsonkhan closed this Mar 9, 2018
@ahsonkhan
Copy link
Member

ahsonkhan commented Mar 9, 2018

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

@davidfowl
Copy link
Member

What crashes?

@ahsonkhan
Copy link
Member

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).

@davidfowl
Copy link
Member

uhhhh what..

@ahsonkhan
Copy link
Member

ahsonkhan commented Mar 9, 2018

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.
Run .\scripts\update-dependencies.ps1 -Update (to update packages locally). Wait for VS to do the package restore and see it hang.

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.).

@ahsonkhan
Copy link
Member

I have a simplified repro of the crash:

  1. Open VS and create a new class library (.NET Standard)
  2. Add a reference to System.IO.Pipelines (https://dotnet.myget.org/feed/dotnet-core/package/nuget/System.IO.Pipelines)
  3. Change the TFM in the csproj from netstandard2.0 to netstandard1.3

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

@ahsonkhan
Copy link
Member

ahsonkhan commented Mar 13, 2018

@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):
"System.Runtime.CompilerServices.Unsafe (4.5.0-preview2-26312-02) (.NETStandard,Version=v1.3/System.Runtime.CompilerServices.Unsafe/4.5.0-preview2-26312-02)"

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?

@ahsonkhan
Copy link
Member

ahsonkhan commented Mar 13, 2018

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>

@ahsonkhan
Copy link
Member

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

@stephentoub
Copy link
Member

stephentoub commented Mar 13, 2018

Referencing System.Threading.Tasks.Extensions causes the hang

A hang in what?

@ahsonkhan
Copy link
Member

ahsonkhan commented Mar 13, 2018

A hang in that?

Visual Studio hangs and then crashes with stack overflow error (when it tries to do the package restore).

@davkean
Copy link
Member

davkean commented Mar 13, 2018

There's some sort of circular dependency in the graph that is causing us to stack overflow in VS.

@davkean
Copy link
Member

davkean commented Mar 13, 2018

Actually I think this is graph that is circular:

"NETStandard.Library (1.6.1) (NETStandard.Library)" -> 
"System.Xml.ReaderWriter (4.3.0) (.NETStandard,Version=v1.3/System.Xml.ReaderWriter/4.3.0)" ->
"System.Threading.Tasks.Extensions (4.5.0-preview2-26312-02) (.NETStandard,Version=v1.3/System.Threading.Tasks.Extensions/4.5.0-preview2-26312-02)" -> 
"System.Runtime.CompilerServices.Unsafe (4.5.0-preview2-26312-02) (.NETStandard,Version=v1.3/System.Runtime.CompilerServices.Unsafe/4.5.0-preview2-26312-02)" ->
"NETStandard.Library (1.6.1) (NETStandard.Library)" 

@ahsonkhan
Copy link
Member

ahsonkhan commented Mar 13, 2018

@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'">

@jkotas
Copy link
Member

jkotas commented Mar 13, 2018

@ahsonkhan It is under <ItemGroup Condition="'$(IsPartialFacadeAssembly)' != 'true'">

@ahsonkhan
Copy link
Member

It is under

Oops. You are right. I misread the csproj.

@ahsonkhan
Copy link
Member

cc @weshaggard
Can you help me figure out what is causing this circular dependency resulting in stackoverflow in VS?

  1. Open VS and create a new class library (.NET Standard)
  2. Add a reference to System.Threading.Tasks.Extensions (https://dotnet.myget.org/feed/dotnet-core/package/nuget/System.Threading.Tasks.Extensions)
  3. Change the TFM in the csproj from netstandard2.0 to netstandard1.3

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>

@weshaggard
Copy link
Member

@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?

@stephentoub
Copy link
Member

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?

@weshaggard
Copy link
Member

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.

@ericstj
Copy link
Member

ericstj commented Mar 13, 2018

@ericstj is this a cycle we should worry about?

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

@ahsonkhan
Copy link
Member

We should add that to Unsafe.

Fixed in dotnet/corefx#28042

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants