-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Update RepoToolset to 1.0.0-beta2-62804-01 #2178
Conversation
@tannergooding can you review this please? |
@mmitche to give the clear on when this can be merged. |
@@ -0,0 +1,7 @@ | |||
<?xml version="1.0" encoding="utf-8"?> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This can potentially impact tests as nuget.config are automatically imported.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You mean the test projects in src\Assets pull in nuget.config? Should we add an empty nuget.config to that directory then? Alternatively, I think that setting RestoreSources
property causes restore to ignore nuget.config, so perhaps the test projects should set that property?
In reply to: 184184799 [](ancestors = 184184799)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we are already creating a nuget.config, but we should make sure that is the case, so that we don't start taking an accidental dependency on the root nuget.config getting auto-imported.
@dsplaisted, do you know if we are creating one for all tests, or just for the perf tests?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As of #2157 a NuGet.config is generated for all tests (it goes in the root test execution folder)
src/Directory.Build.props
Outdated
@@ -3,11 +3,10 @@ | |||
<Project> | |||
|
|||
<PropertyGroup> | |||
<MSBuildAllProjects>$(MSBuildAllProjects);$(MSBuildThisFileDirectory)..\Directory.Build.props</MSBuildAllProjects> | |||
<MSBuildAllProjects>$(MSBuildAllProjects);$(MSBuildThisFileFullPath)</MSBuildAllProjects> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is incorrect, Directory.Build.props are added to MSBuildAllProjects by the file that imports them, they do not add themselves. #Resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure I follow why that would be the case. Shouldn't every file be adding itself?
In reply to: 184184946 [](ancestors = 184184946)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Normally, yes. However, MSBuild does something "smart" with Directory.Build.props/targets
since they are auto-imported...
<!--
Determine the path to the directory build props file if the user did not disable $(ImportDirectoryBuildProps) and
they did not already specify an absolute path to use via $(DirectoryBuildPropsPath)
-->
<PropertyGroup Condition="'$(ImportDirectoryBuildProps)' == 'true' and '$(DirectoryBuildPropsPath)' == ''">
<_DirectoryBuildPropsFile Condition="'$(_DirectoryBuildPropsFile)' == ''">Directory.Build.props</_DirectoryBuildPropsFile>
<_DirectoryBuildPropsBasePath Condition="'$(_DirectoryBuildPropsBasePath)' == ''">$([MSBuild]::GetDirectoryNameOfFileAbove($(MSBuildProjectDirectory), '$(_DirectoryBuildPropsFile)'))</_DirectoryBuildPropsBasePath>
<DirectoryBuildPropsPath Condition="'$(_DirectoryBuildPropsBasePath)' != '' and '$(_DirectoryBuildPropsFile)' != ''">$([System.IO.Path]::Combine('$(_DirectoryBuildPropsBasePath)', '$(_DirectoryBuildPropsFile)'))</DirectoryBuildPropsPath>
</PropertyGroup>
<PropertyGroup Condition="'$(ImportDirectoryBuildProps)' == 'true' and exists('$(DirectoryBuildPropsPath)')">
<MSBuildAllProjects>$(MSBuildAllProjects);$(DirectoryBuildPropsPath)</MSBuildAllProjects>
</PropertyGroup>
Because of this, Directory.Build.props/targets
shouldn't add themselves, they instead add any additional Directory.Build.props/targets
that they import, from further up in the chain (hence why this was $(MSBuildThisFileDirectory)..\Directory.Build.props
). #Resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@@ -9,6 +9,9 @@ obj/ | |||
# Visual Studio | |||
############################################################################### | |||
.vs/ | |||
.dotnet/ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why? We had them under artifacts, explicitly, in order to help prevent pollution of the root directory... #WontFix
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Because it's are not under artifacts anymore. Artifacts are meant for artifacts produced by the build, not by tools the build uses.
In reply to: 184185423 [](ancestors = 184185423)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These are artifacts produced by the build. They may not be artifacts produced directly by our own source code, but they are artifacts that exist solely to support the build and that are not checked into the source tree. Having it under a single folder makes it very convenient to manage and clean up things, as you have a single location to track, rather than 4-5.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
git clean -xfd
cleans everything if that's what you want to do.
Cleaning up the dotnet installation is not common. Deleting artifacts without deleting dotnet is more common. Downloading and installing dotnet takes long time and is only needed when the version changes.
In reply to: 184195237 [](ancestors = 184195237)
Directory.Build.props
Outdated
@@ -3,31 +3,11 @@ | |||
<Project> | |||
|
|||
<PropertyGroup> | |||
<Configuration Condition="'$(Configuration)' == ''">Debug</Configuration> | |||
<MSBuildAllProjects>$(MSBuildAllProjects);$(MSBuildThisFileFullPath)</MSBuildAllProjects> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is incorrect, Directory.Build.props are added to MSBuildAllProjects by the importing file, they do not add themselves. #Resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@tannergooding I think all .props and .targets should add themselves to MSBuildAllProjects. It doesn't hurt to have the same file added twice, and it's much simpler to always do it rather than have to reason about whether the importer is doing it for you.
|
||
<PropertyGroup> | ||
<ArtifactsDir>$(DOTNET_SDK_ARTIFACTS_DIR)</ArtifactsDir> | ||
<ArtifactsDir Condition="'$(ArtifactsDir)' == ''">$(RepoRoot)artifacts\</ArtifactsDir> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this set by RepoToolset now? #Resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do you mean, it is still used by our tests for dogfooding.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That still needs to be cleaned up (I'll follow up on that later). It's used as an optional override of the artifacts directory path here:
sdk/src/Tests/Microsoft.NET.TestFramework/TestContext.cs
Lines 100 to 104 in 9cf7788
string artifactsDir = Environment.GetEnvironmentVariable("DOTNET_SDK_ARTIFACTS_DIR"); | |
if (string.IsNullOrEmpty(artifactsDir)) | |
{ | |
artifactsDir = Path.Combine(repoRoot, "artifacts"); | |
} |
Based on discussion with @dsplaisted the scenario this was needed for was to switch to a different version of dotnet SDK. This can be done by setting DOTNET_INSTALL_DIR
instead. So DOTNET_SDK_ARTIFACTS_DIR
is not needed anymore.
In reply to: 184195832 [](ancestors = 184195832)
<ArtifactsDir>$(DOTNET_SDK_ARTIFACTS_DIR)</ArtifactsDir> | ||
<ArtifactsDir Condition="'$(ArtifactsDir)' == ''">$(RepoRoot)artifacts\</ArtifactsDir> | ||
<ArtifactsDir>$([MSBuild]::EnsureTrailingSlash($(ArtifactsDir)))</ArtifactsDir> | ||
<DOTNET_INSTALL_DIR Condition="'$(DOTNET_INSTALL_DIR)' == ''">$(RepoRoot)artifacts\.dotnet\$(DotNetCliVersion)\</DOTNET_INSTALL_DIR> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same for this? #Resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, the install dir environment variable is set by build.ps1, if not set already.
In reply to: 184185819 [](ancestors = 184185819)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Doesn't this break the scenario of building the solution from the command line, directly, rather than going through the build scripts?
@@ -8,4 +8,4 @@ while [ -h "$SOURCE" ]; do # resolve $SOURCE until the file is no longer a symli | |||
done | |||
ScriptRoot="$( cd -P "$( dirname "$SOURCE" )" && pwd )" | |||
|
|||
. "$ScriptRoot/build/build.sh" --build --restore --log "$@" | |||
. "$ScriptRoot/build/build.sh" --build --restore "$@" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why was the log command removed? #Resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is not a valid arg in the new version of the repo toolset and caused source-build builds to fail. #Resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
|
||
<PropertyGroup> | ||
<!-- Respect environment variable for the NuGet Packages Root if set; otherwise, use the current default location --> | ||
<NuGetPackageRoot Condition="'$(NuGetPackageRoot)' == ''">$(NUGET_PACKAGES)</NuGetPackageRoot> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this part of RepoToolset now? #Resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@@ -12,18 +12,6 @@ | |||
<PreReleaseVersionLabel>rc1</PreReleaseVersionLabel> | |||
</PropertyGroup> | |||
|
|||
<!-- Repo Toolset Features --> | |||
<PropertyGroup> | |||
<UsingToolMicrosoftNetCompilers>false</UsingToolMicrosoftNetCompilers> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this part of RepoToolset now?
@@ -12,7 +12,7 @@ | |||
<OutDirName>Tests\$(MSBuildProjectName)</OutDirName> | |||
</PropertyGroup> | |||
|
|||
<Import Project="Sdk.props" Sdk="Microsoft.NET.Sdk" /> | |||
<Import Project="Sdk.props" Sdk="RoslynTools.RepoToolset" /> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Personally I really don't like that all projects have to be updated to use a different Sdk. Also, Sdks don't compose if done this way- there's no way to use both RepoToolset and Microsoft.NET.Sdk.Web for example.
Would it be possible instead to:
- Not have the RepoToolset SDK import Microsoft.NET.Sdk
- Have projects that use RepoToolset do so via Sdk imports in Directory.Build.props and Directory.Build.targets
- Leave the Sdk imports in project files as they were (ie Microsoft.NET.Sdk or Microsoft.NET.Sdk.Web)
We don't need to change this before we update the sdk repo to the new repotoolset, but I would like to consider a change like this for the future.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is the current design. We can discuss changes in future.
I'm good with the changes. |
* Update RepoToolset to 1.0.0-beta2-62804-01 * Update dotnet SDK to 2.1.300-preview3-008616 (dotnet#2180) * Remove --log argument from build.sh * Exclude test projects from source build (dotnet#2181) * Fix paths in MSBuildAllProjects (dotnet#2182)
Looks like it was broken by dotnet#2178
No description provided.