Skip to content
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

Merged
merged 6 commits into from
Apr 26, 2018
Merged

Conversation

tmat
Copy link
Member

@tmat tmat commented Apr 25, 2018

No description provided.

@livarcocc
Copy link
Contributor

@tannergooding can you review this please?

@livarcocc livarcocc added this to the 2.1.3xx milestone Apr 25, 2018
@livarcocc
Copy link
Contributor

@mmitche to give the clear on when this can be merged.

@@ -0,0 +1,7 @@
<?xml version="1.0" encoding="utf-8"?>
Copy link
Member

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.

Copy link
Member Author

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)

Copy link
Member

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?

Copy link
Member

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)

@@ -3,11 +3,10 @@
<Project>

<PropertyGroup>
<MSBuildAllProjects>$(MSBuildAllProjects);$(MSBuildThisFileDirectory)..\Directory.Build.props</MSBuildAllProjects>
<MSBuildAllProjects>$(MSBuildAllProjects);$(MSBuildThisFileFullPath)</MSBuildAllProjects>
Copy link
Member

@tannergooding tannergooding Apr 25, 2018

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

Copy link
Member Author

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)

Copy link
Member

@tannergooding tannergooding Apr 25, 2018

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

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see. Will fix. Thanks for pointing it out!


In reply to: 184193805 [](ancestors = 184193805)

@@ -9,6 +9,9 @@ obj/
# Visual Studio
###############################################################################
.vs/
.dotnet/
Copy link
Member

@tannergooding tannergooding Apr 25, 2018

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

Copy link
Member Author

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)

Copy link
Member

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.

Copy link
Member Author

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)

@@ -3,31 +3,11 @@
<Project>

<PropertyGroup>
<Configuration Condition="'$(Configuration)' == ''">Debug</Configuration>
<MSBuildAllProjects>$(MSBuildAllProjects);$(MSBuildThisFileFullPath)</MSBuildAllProjects>
Copy link
Member

@tannergooding tannergooding Apr 25, 2018

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

Copy link
Member

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>
Copy link
Member

@tannergooding tannergooding Apr 25, 2018

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

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

DOTNET_SDK_ARTIFACTS_DIR is no longer needed.


In reply to: 184185770 [](ancestors = 184185770)

Copy link
Member

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.

Copy link
Member Author

@tmat tmat Apr 25, 2018

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:

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>
Copy link
Member

@tannergooding tannergooding Apr 25, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same for this? #Resolved

Copy link
Member Author

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)

Copy link
Member

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 "$@"
Copy link
Member

@tannergooding tannergooding Apr 25, 2018

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

Copy link
Member

@dagood dagood Apr 25, 2018

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

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The build now always produces binlog.


In reply to: 184189056 [](ancestors = 184189056)


<PropertyGroup>
<!-- Respect environment variable for the NuGet Packages Root if set; otherwise, use the current default location -->
<NuGetPackageRoot Condition="'$(NuGetPackageRoot)' == ''">$(NUGET_PACKAGES)</NuGetPackageRoot>
Copy link
Member

@tannergooding tannergooding Apr 25, 2018

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

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes.


In reply to: 184186017 [](ancestors = 184186017)

@@ -12,18 +12,6 @@
<PreReleaseVersionLabel>rc1</PreReleaseVersionLabel>
</PropertyGroup>

<!-- Repo Toolset Features -->
<PropertyGroup>
<UsingToolMicrosoftNetCompilers>false</UsingToolMicrosoftNetCompilers>
Copy link
Member

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" />
Copy link
Member

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.

Copy link
Member Author

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.

@mmitche
Copy link
Member

mmitche commented Apr 26, 2018

I'm good with the changes.

@tmat tmat merged commit 363351b into release/2.1.3xx Apr 26, 2018
wli3 pushed a commit to wli3/sdk that referenced this pull request May 17, 2018
* 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)
sbomer added a commit to sbomer/sdk that referenced this pull request Sep 19, 2018
Looks like it was broken by dotnet#2178
@sbomer sbomer mentioned this pull request Sep 19, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants