There is no need to store relative path today. But some part of the system does not accept relative path and there is no indication if it is storing full path or not. This is the root cause of https://github.com/dotnet/cli/issues/9319
“someplace” means different full path for Path class on unix and Windows. And the mock file system uses real Path class. Change tests' setup to use essentially “TEMPATH/someplace” instead of “someplace”
* release/2.1.3xx:
Disable NewProjectRestoresCorrectPackageVersion "console" test for now.
Update the version for 'microsoft.netcore.app' to "2.1.1*"
Pass "PB_AssetRootUrl" explictly on the MSBuild call; we are looking for Microsoft.NETCore.App "2.1.0" or "2.1.1*"
Fix alpine file ownership issues with newer docker Upgrades to a newer docker version (18.03.1-ce) caused files created inside to be owned by root on alpine. It appears that the logic to set up the user in the container so that this doesn't happen was missing from alpine. While it's not clear why it worked before at all, the logic has been duplicated (tweaked for the alpine base image).
Remove -upgrade suffix from installer inputs
Ensure default aspnetcore metapackage versions doesn't jump when/if we ever get to version `2.1.10`
Add retry when Directory.Move (#9313)
Fix mismatch of dotnet-watch with package variable name
Set package versions for bundled aspnet tools separately from the metapackage version
Split the version of Microsoft.AspNetCore.DeveloperCertificates.XPlat into a separate variable
Fixup myget feed for aspnetcore
Upgrade to aspnetcore 2.1.1-rtm-30818 and react to file name change
Set Default aspnetcore metapackage versions
* release/2.1.2xx:
Updating netci.groovy to archive test results on failure.
Fix version number
Consume 15.7.2 compiler
Updating the CLI branding to 201.
MSBuild 15.7.179
Fix alpine file ownership issues with newer docker
Upgrades to a newer docker version (18.03.1-ce) caused files created inside to be owned by root on alpine. It appears that the logic to set up the user in the container so that this doesn't happen was missing from alpine. While it's not clear why it worked before at all, the logic has been duplicated (tweaked for the alpine base image).
Upgrades to a newer docker version (18.03.1-ce) caused files created inside to be owned by root on alpine. It appears that the logic to set up the user in the container so that this doesn't happen was missing from alpine. While it's not clear why it worked before at all, the logic has been duplicated (tweaked for the alpine base image).
