Update dnx version to latest.

[mmitche]

Should solve the dnx deadlock issues seen now and again in corefx. This is also required to be able to float packages to the newest versions.

/cc @ericstj @stephentoub

[ericstj]

It's required to consume the latest packages since I started using the "DotNET" identifier instead of "any". It's not directly related to floating, only that floating causes folks to pick up these new packages which require the new version. Change looks fine to me, we should double check that all the fixes going into beta5 have been integrated into beta6 as well. Once we do that and the build completes, 👍

[akoeplinger]

Can we upgrade the Unix DNX version as well? See https://github.com/dotnet/corefx/issues/2002

[ericstj]

@mmitche you might be able to pick the latest beta5 build instead of beta6 since it looks like not all fixes have been ported to beta6 yet. You can see the specific beta5 versions of packages available by doing:
nuget list -source https://www.myget.org/F/aspnetrelease -pre -allversions dnx-coreclr-win-x86

[mmitche]

@ericstj I'll try that, thanks

[mmitche]

@jasonwilliams200OK this change may fix your issue.

[mmitche]

@ericstj We may be in trouble here, since I got another concurrency issue with this beta5 verison of dnx.

[ericstj]

Where can we see a full log?

[ghost]

@mmitche, I compiled buildtools with my changes and copied content of this directory:

buildtools\bin\Windows_NT.AnyCPU.Debug\Microsoft.DotNet.Build.Tasks

over:

corefx\packages\Microsoft.DotNet.BuildTools.1.0.25-prerelease-00053\lib

After that when i built corefx, it fails and msbuild.log shows:

1>Building with tools version "14.0".
Project file contains ToolsVersion="12.0". This toolset may be unknown or missing, in which case you may be able to resolve this by installing the appropriate version of MSBuild, or the build may have been forced to a particular ToolsVersion for policy reasons. Treating the project as if it had ToolsVersion="14.0". For more information, please see http://go.microsoft.com/fwlink/?LinkId=293424.
Target "CheckRoslyn" skipped, due to false condition; ('$(UseRoslynCompiler)'=='true' and '$(MSBuildProjectFile)'!='build.proj') was evaluated as (''=='true' and 'build.proj'!='build.proj').

Note that I used dotnet-ci command to build the buildtools: dotnet/buildtools#180 (comment) (which also failed to produce xunit test). Please let me know if you want me to test anything specific?

[mmitche]

@dotnet-bot test this please

Altered the jobs to archive a full log

[mmitche]

@jasonwilliams200OK Actually I don't think that will test it properly anyway...The issue being that the netcore project is build from this repo, but published as a separate package from the targets portion of buildtools. Let me look into the right way to test this. I hope this doesn't end up being dependent on the dnx update.

[mmitche]

@dotnet-bot test this please

[mmitche]

@ericstj http://dotnet-ci.cloudapp.net/job/dotnet_corefx_mac_release_prtest/1178/Azure/processDownloadRequest/1178/msbuild.log

Is dnx attempting to open the lock file for write always? Doesn't it have internal locking mechanisms to avoid multiple processes attempting to muck with the same files at the same time?

System.IO.IOException: The process cannot access the file 'd:\j\workspace\dotnet_corefx_mac_release_prtest\packages\Microsoft.DotNet.BuildTools.1.0.25-prerelease-00053\lib\test-runtime\project.lock.json' because it is being used by another process. (TaskId:1625)
at System.IO.Win32FileStream.Init(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs) (TaskId:1625)
at System.IO.Win32FileSystem.Open(String fullPath, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, FileOptions options, FileStream parent) (TaskId:1625)
at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, FileOptions options) (TaskId:1625)
at Microsoft.Framework.PackageManager.LockFileFormat.Write(String filePath, LockFile lockFile) (TaskId:1625)
at Microsoft.Framework.PackageManager.RestoreCommand.WriteLockFile(LockFile previousLockFile, String projectLockFilePath, Project project, List1 graphItems, PackageRepository repository, IEnumerable1 contexts) (TaskId:1625)
at Microsoft.Framework.PackageManager.RestoreCommand.d__77.MoveNext() (TaskId:1625)
--- End of stack trace from previous location where exception was thrown --- (TaskId:1625)
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) (TaskId:1625)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) (TaskId:1625)
at Microsoft.Framework.PackageManager.RestoreCommand.<>c__DisplayClass76_0.<b__1>d.MoveNext() (TaskId:1625)
--- End of stack trace from previous location where exception was thrown --- (TaskId:1625)
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) (TaskId:1625)
at Microsoft.Framework.PackageManager.RestoreCommand.d__76.MoveNext() (TaskId:1625)

[ericstj]

Previously we had a mutex around this to workaround this bug: aspnet/dnx#1682. Now we don't and we expect DNX to never update the lock files since they are locked. Can you diff old and new to see what it is changing? We might need to just update the lock file in the buildtools package. 😦 I don't want to bring back the mutex.

We could bail on concurrent restore and just do it in a batch up front. This is what DNX team recommends. I've been intentionally ignoring that recommendation in order to uncover stress bugs.

[ericstj]

https://github.com/dotnet/corefx/issues/2073 actually helped me understand why DNX is regenerating the lock files. I'll fix this all in one go.

[stephentoub]

Replaced by #2111