This repository has been archived by the owner on Jan 23, 2023. It is now read-only.
Sdk test projects #19044
Merged
Sdk test projects #19044
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…SDK style projects
…rgets} fpr SDK projects
… targets for non-sdk projects, and only default to not building sdk projects when we're part of the overall build
…hem picking up dirs.props/targets automatically
Fix runtime version to match MicrosoftNETCoreRuntimeCoreCLRPackageVersion for all sdk projects + test wrappers
…ing on the package directory
| <!-- if this is a RunOnly project that has been scheduled to build, make the output directory and build any dependent projects --> | ||
| <Target Name="Build" Condition="('$(CLRTestKind)'=='RunOnly') And '$(_WillCLRTestProjectBuild)'"> | ||
| <MSBuild Projects="@(ProjectReference)" /> | ||
| <MakeDir ContinueOnError="false" Directories="$(OutputPath)" /> |
There was a problem hiding this comment.
I don't remember the default behavior of this, but does the MakeDir task consider a directory that already exists an error?
AaronRobinsonMSFT
approved these changes
Jul 20, 2018
|
@dotnet-bot test CentOS7.1 x64 Debug Innerloop Build |
|
@dotnet-bot test all please |
|
Everything look ok to you? |
RussKeldorph
approved these changes
Jul 25, 2018
jashook
pushed a commit
to jashook/coreclr
that referenced
this pull request
Aug 14, 2018
Change the associated targets and props files in the test directory to allow the test csproj's to be built as SDK style projects alongside traditional style projects.
Remove CodeTaskFactory:
- Allows the projects to be built using the core version of msbuild/dotnet build
- Converted to using msbuild property expansion instead
Add directory.build.{props,targets}:
- Currently we just import the dirs.props and targets, but means SDK style projects don't need to explicitly include these files
- We probably want to move all projects over to using these in the future, but this keeps the changes smaller for now
Specific code for SDK projects:
- There are a several changes required to build an SDK project. This change guards them behind conditionals so that only the new style projects see them. When we get to the point that there are only new projects, we can remove the guards (probably at the same time as ditching the dir.props)
Reordered build targets:
- Because SDK projects implicitly import the build targets, we can no longer re-define the build targets unconditionally knowing they will likely be overwritten.
- Instead we move the overwritten targets to separate files, and include these conditionally based on properties. In this way there is always a build defined for SDK projects, which can then be overwritten to do nothing as needed.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
New PR replacing #18810 rebased on top of #18695:
This change updates the associated targets and props files in the test directory to allow the test csproj's to be built as SDK style projects alongside traditional style projects.
It does not yet upgrade any of the projects, I'll submit a seperate batch of PRs for that, so that these changes aren't lost in a ton of mechanical refactoring.
While these changes allow the csproj's to be upgraded, there is still work to be done to allow depproj and ilproj's to be converted over to the new style. By allowing a mix of projects styles this change allows us to upgrade piece-meal rather than in a single big bang, hopefully allowing us to easier figure out bugs if they arise.