### Determine target framework
-`netstandard` or `netcoreapp` is the target framework version currently under development.
-
-- If the library is [part of netstandard](#faq)
- - Your target framework should be `netstandard`
- - If it is a new API only available on .NET Core then it will be added to `netcoreapp`
-- If the library is not part of netstandard
- - If package dependencies are changed then your target framework should be the minimum target framework that supports all your package dependencies.
- - If your package depends directly on runtime changes or library changes that ship with the runtime (i.e. System.Private.CoreLib) then your target framework should be `netstandard`.
- - When targeting `netstandardX` your new API must be supported by all target frameworks that map to that netstandard version (see [mapping table][net-standard table]). If not bump the version to the minimum netstandard version that supports this API on all frameworks that map to that netstandard version.
-
-### Determine library version
-- If targeting netstandard
- - Ensure minor version of the assembly is bumped since last stable package release
-- If targeting netcoreapp
- - No assembly version bump necessary
+`netcoreapp5.0` is the target framework version currently under development and the new apis
+should be added to `netcoreapp5.0`. [More Information on TargetFrameworks](https://docs.microsoft.com/en-us/dotnet/standard/frameworks)
## Making the changes in repo
-**If changing the library version**
-- The `AssemblyVersion` property isn't always in `<Library>\Directory.Build.props` file unless we want to override the default for some reason. For more information on how the original version is calculated, see [Arcade documentation](https://github.com/dotnet/arcade/blob/master/Documentation/CorePackages/Versioning.md).
-- If the `AssemblyVersion` property exists (for example, [Microsoft.CSharp\Directory.Build.props](https://github.com/dotnet/runtime/blob/master/src/libraries/Microsoft.CSharp/Directory.Build.props#L4)), you can change it.
-- If the `AssemblyVersion` property doesn't exist (for example, [System.Runtime\Directory.Build.props](https://github.com/dotnet/runtime/blob/master/src/libraries/System.Runtime/Directory.Build.props)), you can add it.
-
-**If changing the target group**
-- Update both the `Configurations` property in the library's csproj file and the `BuildConfigurations` property in the library's Configurations.props file.
-
**Update pkg**
- If changing the target framework
- Update `SupportedFramework` metadata on the ref ProjectReference to declare the set of concrete platforms you expect your library to support. (see [Specific platform mappings][net-standard table]). Generally will be a combination of netcoreapp2.x, netfx46x, and/or `$(AllXamarinFrameworks)`.
`dotnet msbuild <Library>/pkg/<Library>.pkgproj /t:UpdatePackageIndex`
**Update tests**
- - Set `TargetGroup` which will generally match the `TargetGroup` in the src library build configuration. (ex: [System.Runtime\tests\Configurations.props](https://github.com/dotnet/corefx/blob/master/src/System.Runtime/tests/Configurations.props#L3))
+ - Add new `TargetFramework` to the ```TargetFrameworks```.
- Add new test code following [conventions](project-guidelines.md#code-file-naming-conventions) for new files to that are specific to the new target framework.
- - To run just the new test configuration run `dotnet msbuild <Library>.csproj /t:RebuildAndTest /p:TargetGroup=<TargetGroup>`
+ - To run just the new test targetFramework run `dotnet build <Library>.csproj -f <TargetFramework> /t:RebuildAndTest`. TargetFramework should be chosen only from supported TargetFrameworks.
## Documentation
Once the documentation is official, any subsequent updates to it must be made directly in https://github.com/dotnet/dotnet-api-docs/. It's fine to make updates to the triple slash comments later, they just won't automatically flow into the official docs.
## FAQ
-_**<a name="isnetstandard">Is your API part of netstandard?</a>**_
-
-Use [apisof.net](https://apisof.net) to identify the support matrix of a specific API.
-
-_**What is the difference between being part of netstandard and building against netstandard?**_
-
-Things that are part of netstandard can only change when we release a new version of a platform
-that supports the higher version of netstandard. Whereas things that build against netstandard and
-ship in independent packages can be changed without an update to the platform that it is running on.
-That gives more flexibility to add API to things that build against netstandard because it does not
-require a platform update to consume.
-
_**How do I consume APIs from another package that aren't yet published?**_
If you are adding APIs across multiple packages at the same time. You can temporarily add a direct
If you are moving types down you need to version both contracts at the same time and temporarily use
project references across the projects. You also need to be sure to leave type-forwards in the places
where you removed types in order to maintain back-compat.
-
-
-[net-standard table]: https://docs.microsoft.com/en-us/dotnet/standard/net-standard#net-implementation-support
<PropertyGroup>
<OutputType>Library</OutputType>
<NuGetTargetMoniker>.NETStandard,Version=v1.7</NuGetTargetMoniker>
- <DefineConstants Condition="'$(TargetGroup)' == 'netcoreapp1.1'">$(DefineConstants);netcoreapp11</DefineConstants>
+ <DefineConstants Condition="'$(TargetFramework)' == 'netcoreapp1.1'">$(DefineConstants);netcoreapp11</DefineConstants>
</PropertyGroup>
<ItemGroup>
<Compile Include="System.Net.Security.cs" />
<OSGroup>Windows_NT</OSGroup>
</Project>
<Project Include="System.Net.Security.csproj">
- <TargetGroup>net463</TargetGroup>
+ <TargetFramework>net463</TargetFramework>
</Project>
</ItemGroup>
<Import Project="$(RepositoryEngineeringDir)dir.traversal.targets" />
Tests can be similarly filtered grouping the compilation directives under:
```
- <ItemGroup Condition="'$(TargetGroup)'=='netcoreapp1.1'">
+ <ItemGroup Condition="'$(TargetFramework)'=='netcoreapp1.1'">
```
(from `\tests\FunctionalTests\System.Net.Security.Tests.csproj`)
1. Configure the correct projects in your library's `.builds` file.
2. Reference the `.builds` file from the package project.
-3. Provide a default PackageTargetFramework for empty-TargetGroup builds in the library's `.csproj` or `.vbproj`.
+3. Provide a default PackageTargetFramework for empty-BuildTargetFramework builds in the library's `.csproj` or `.vbproj`.
```
<PackageTargetFramework Condition="'$(PackageTargetFramework)' == ''">dotnet5.4</PackageTargetFramework>
```
- Setup tools (currently done in restore in build.cmd/sh)
- Restore external dependencies
- - CoreCLR - Copy to `bin\runtime\$(BuildConfiguration)`
- - Netstandard Library - Copy to `bin\ref\netstandard`
+ - CoreCLR - Copy to `bin\runtime\$(BuildTargetFramework)-$(OSGroup)-$(Configuration)-$(ArchGroup)`
+ - Netstandard Library - Copy to `bin\ref\netstandard2.0`
- NetFx targeting pack - Copy to `bin\ref\net472`
- Build targeting pack
- Build src\ref.builds which builds all references assembly projects. For reference assembly project information see [ref](#ref)
- Sign product
- Build src\sign.proj
-## Behind the scenes with build-test.cmd/sh
-- build-test.cmd cannot be ran successfully until build.cmd has been ran at least once for a `BuildConfiguration`.
-- Build src\tests.builds which builds all applicable test projects. For test project information see [tests](#tests).
-- The build pass will happen twice. Once for the specific `$(BuildConfiguration)` and once for netstandard. That way we run both sets of applicable tests against for the given `$(BuildConfiguration)`.
-
-## Behind the scenes with build-packages.cmd/sh
-- build-packages.cmd cannot be run successfully until build.cmd has been ran at least once for a BuildConfiguration.
-- Build src\packages.builds which will build only the packages it has the context to build which will generally be only the ones for the given `BuildConfiguration`. If a package requires assets from multiple `BuildConfigurations` it will require that all `BuildConfigurations` are built first.
-
# Build Pivots
Below is a list of all the various options we pivot the project builds on:
## Individual build properties
The following are the properties associated with each build pivot
-- `$(TargetGroup) -> netstandard2.1 | netcoreapp5.0 | net472`
-//**CONSIDER**: naming netcoreappcorert something shorter maybe just corert.
+- `$(BuildTargetFramework) -> netstandard2.1 | netcoreapp5.0 | net472`
- `$(OSGroup) -> Windows | Linux | OSX | FreeBSD | [defaults to running OS when empty]`
-- `$(ConfigurationGroup) -> Release | [defaults to Debug when empty]`
+- `$(Configuration) -> Release | [defaults to Debug when empty]`
- `$(ArchGroup) - x86 | x64 | arm | arm64 | [defaults to x64 when empty]`
- `$(RuntimeOS) - win7 | osx10.10 | ubuntu.14.04 | [any other RID OS+version] | [defaults to running OS when empty]` See [RIDs](https://github.com/dotnet/runtime/tree/master/src/libraries/pkg/Microsoft.NETCore.Platforms) for more info.
For more information on various targets see also [.NET Standard](https://github.com/dotnet/standard/blob/master/docs/versions.md)
## Aggregate build properties
-Each project will define a set of supported build configurations
+Each project will define a set of supported TargetFrameworks
```
<PropertyGroup>
- <BuildConfigurations>
- [BuildConfiguration1];
- [BuildConfiguration2];
- ...
- </BuildConfigurations>
+ <TargetFrameworks>[TargetFramework];[TargetFramework];...</TargetFrameworks>
<PropertyGroup>
```
-- `$(BuildConfiguration) -> $(TargetGroup)[-$(OSGroup)][-$(ConfigurationGroup)][-$(ArchGroup)]`
+- `$(BuildSettings) -> $(BuildTargetFramework)[-$(OSGroup)][-$(Configuration)][-$(ArchGroup)]`
- Note this property should be file path safe and thus can be used in file names or directories that need to a unique path for a project configuration.
- - The only required configuration value is the `$(TargetGroup)` the others are optional.
+ - The only required Build Settings value is the `$(BuildTargetFramework)` the others are optional.
Example:
Pure netstandard configuration:
```
<PropertyGroup>
- <BuildConfigurations>
- netstandard;
- </BuildConfigurations>
+ <TargetFrameworks>netstandard2.0</TargetFrameworks>
<PropertyGroup>
```
All supported targets with unique windows/unix build for netcoreapp:
```
<PropertyGroup>
- <BuildConfigurations>
- $(NetCoreAppCurrent)-Windows_NT;
- $(NetCoreAppCurrent)-Unix;
- $(NetFrameworkCurrent)-Windows_NT;
- </BuildConfigurations>
+ <TargetFrameworks>$(NetCoreAppCurrent)-Windows_NT;$(NetCoreAppCurrent)-Unix;$(NetFrameworkCurrent)-Windows_NT</TargetFrameworks>
<PropertyGroup>
```
-### Placeholder build configurations
-Placeholder build configurations can be added to the `<BuildConfigurations>` property to indicate the build system that the specific project is inbox in that framework and that build configuration needs to be ignored.
+### Placeholder Target Frameworks
+Placeholder Target Framework can be added to the `<TargetFrameworks>` property to indicate the build system that the specific project is inbox in that framework and that Build Setting needs to be ignored.
-Placeholder build configurations start with _ prefix.
+Placeholder target frameworks start with _ prefix.
Example:
-When we have a project that has a `netstandard` build configuration that means that this project is compatible with any build configuration. So if we do a vertical build for `net472` this project will be built as part of the vertical because `net472` is compatible with `netstandard2.0`. This means that in the runtime and testhost binaries the netstandard implementation will be included, and we will test against those assets instead of testing against the framework inbox asset. In order to tell the build system to not include this project as part of the `net472` vertical we need to add a placeholder configuration:
+When we have a project that has a `netstandard2.0` target framework that means that this project is compatible with any build setting. So if we do a vertical build for `net472` this project will be built as part of the vertical because `net472` is compatible with `netstandard2.0`. This means that in the runtime and testhost binaries the netstandard2.0 implementation will be included, and we will test against those assets instead of testing against the framework inbox asset. In order to tell the build system to not include this project as part of the `net472` vertical we need to add a placeholder target framework:
```
<PropertyGroup>
- <BuildConfigurations>
- netstandard2.0;
- _net472;
- </BuildConfigurations>
+ <TargetFrameworks>netstandard2.0;_net472</TargetFrameworks>
</PropertyGroup>
```
## Options for building
-A full or individual project build is centered around BuildConfiguration and will be setup in one of the following ways:
+A full or individual project build is centered around BuildTargetFramework, OSGroup, Configuration and ArchGroup.
-1. `$(BuildConfiguration)` can directly be passed to the build.
-2. `$(Configuration)` can be passed to the build and `$(BuildConfiguration)` will be set to `$(Configuration)-$(ArchGroup)`. This is a convenience mechanism primarily to help with VS support because VS uses the `Configuration` property for switching between various configurations in the UI. NOTE: this only works well for individual projects and not the root builds.
-3. `$(TargetGroup), $(OSGroup), $(ConfigurationGroup), $(ArchGroup)` can individually be passed in to change the default value for just part of the `BuildConfiguration`.
-4. If nothing is passed to the build then we will default `BuildConfiguration` from the environment. Example: `netcoreapp-[OSGroup Running On]-Debug-x64`.
+1. `$(BuildTargetFramework), $(OSGroup), $(Configuration), $(ArchGroup)` can individually be passed in to change the default values.
+2. If nothing is passed to the build then we will default value of these properties from the environment. Example: `netcoreapp5.0-[OSGroup Running On]-Debug-x64`.
+3. While Building an individual project from the VS, we build the project for all latest netcoreapp target frameworks.
-On top of the `BuildConfiguration` we also have `RuntimeOS` which can be passed to customize the specific OS and version needed for native package builds as well as package restoration. If not passed it will default based on the OS you are running on.
+We also have `RuntimeOS` which can be passed to customize the specific OS and version needed for native package builds as well as package restoration. If not passed it will default based on the OS you are running on.
Any of the mentioned properties can be set via `/p:<Property>=<Value>` at the command line. When building using our run tool or any of the wrapper scripts around it (i.e. build.cmd) a number of these properties have aliases which make them easier to pass (run build.cmd/sh -? for the aliases).
-## Selecting the correct build configuration
-When building an individual project the `BuildConfiguration` will be used to select the closest matching configuration listed in the projects `BuildConfigurations` property. The rules used to select the configuration will consider compatible target frameworks and OS fallbacks.
-
-TODO: Link to the target framework and OS fallbacks when they are available.
-Temporary versions are at https://github.com/dotnet/corefx/blob/dev/eng/src/Tools/GenerateProps/osgroups.props and https://github.com/dotnet/corefx/blob/dev/eng/src/Tools/GenerateProps/targetgroups.props
+## Selecting the correct BuildSettings
+When building an individual project the `BuildTargetFramework` and `OSGroup` will be used to select the closest matching TargetFramework listed in the projects `TargetFrameworks` property. The rules used to select the targetFramework will consider compatible target frameworks and OS fallbacks.
-## Supported full build configurations
+## Supported full build settings
- .NET Core latest on current OS (default) -> `$(NetCoreAppCurrent)-[RunningOS]`
- .NET Framework latest -> `$(NetFrameworkCurrent)-Windows_NT`
-## Project configurations for VS
-For each unique configuration needed for a given library project a configuration entry separated by a ';' should be added to the project so it can be selected and built in VS and also clearly identify the various configurations.<BR/>
-
-`$(TargetGroup)-$(OSGroup)-$(ConfigurationGroup)|$(Platform`
-- Note that the majority of managed projects, currently all in corefx, $(Platform) is overridden to be AnyCPU.
-
-`<Configurations>netcoreapp-Unix-Debug;netcoreapp-Unix-Release;netcoreapp-Windows_NT-Debug;netcoreapp-Windows_NT-Release</Configurations>`
-
-####*Examples*
-Project configurations with a unique implementation on Unix and Windows
-```xml
-<Configurations>netcoreapp-Unix-Debug;netcoreapp-Unix-Release;netcoreapp-Windows_NT-Debug;netcoreapp-Windows_NT-Release</Configurations>
-```
-Project configurations that are unique for a few different target frameworks and runtimes
-```xml
-<Configurations>netcoreapp-Windows_NT-Debug;netcoreapp-Windows_NT-Release</Configurations>
-```
-
-## Updating Configurations
-
-We have a build task that you can run to automatically update all the projects with the above boilerplate as well as updating all the solution files for the libraries. Whenever you change the list of configurations for a project you can regenerate all these for the entire repo by running:
-
-```
-dotnet msbuild build.proj /t:UpdateVSConfigurations
-```
-
-If you want to scope the generation you can either undo changes that you don't need or you can temporally limit the set of projects or directories by updating the item set in the UpdateVSConfigurations target in https://github.com/dotnet/runtime/blob/master/src/libraries/build.proj
-
# Library project guidelines
Library projects should use the following directory layout.
## ref
Reference assemblies are required for any library that has more than one implementation or uses a facade. A reference assembly is a surface-area-only assembly that represents the public API of the library. To generate a reference assembly source file you can use the [GenAPI tool](https://www.nuget.org/packages/Microsoft.DotNet.BuildTools.GenAPI). If a library is a pure portable library with a single implementation it need not use a reference assembly at all. Instructions on updating reference sources can be found [here](https://github.com/dotnet/runtime/blob/master/docs/coding-guidelines/updating-ref-source.md).
-In the ref directory for the library there should be at most **one** `.csproj` that contains the latest API for the reference assembly for the library. That project can contain multiple entries in its `BuildConfigurations` property.
-
-There are two types of reference assembly projects:
-
-1. Libraries that are contain APIs in netstandard
- - `BuildConfigurations` should contain non-netstandard configurations for the platforms they support.
- - Should use a relative path `<ProjectReference>` to the dependencies it has. Those dependencies should only be libraries with similar build configurations and be part of netstandard.
-<BR/>//**CONSIDER**: just using Reference with a custom task to pull from TP or turn to ProjectReference
-2. Libraries that are built on top of netstandard
- - `BuildConfigurations` should contain only netstandard configurations.
- - Should contain `<Reference Include='netstandard'>`
- - Anything outside of netstandard should use a relative path `<ProjectReference>` to its dependencies it has. Those dependencies should only be libraries that are built against netstandard as well.
+In the ref directory for the library there should be at most **one** `.csproj` that contains the latest API for the reference assembly for the library. That project can contain multiple entries in its `TargetFrameworks` property. Ref projects should use `<ProjectReference>` for its dependencies.
### ref output
The output for the ref project build will be a flat targeting pack folder in the following directory:
-`bin\ref\$(TargetGroup)`
+`bin\ref\$(TargetFramework)`
-<BR/>//**CONSIDER**: Do we need a specific BuildConfiguration version of TargetGroup for this output path to ensure all projects output to same targeting path?
+<BR/>//**CONSIDER**: Do we need a specific BuildTargetFramework version of TargetFramework for this output path to ensure all projects output to same targeting path?
## src
-In the src directory for a library there should be only **one** `.csproj` file that contains any information necessary to build the library in various configurations. All supported configurations should be listed in the `BuildConfigurations` property.
+In the src directory for a library there should be only **one** `.csproj` file that contains any information necessary to build the library in various target frameworks. All supported target frameworks should be listed in the `TargetFrameworks` property.
-All libraries should use `<Reference Include="..." />` for all their project references. That will cause them to be resolved against a targeting pack (i.e. `bin\ref\netcoreapp` or `\bin\ref\netstanard`) based on the project configuration. There should not be any direct project references to other libraries. The only exception to that rule right now is for partial facades which directly reference System.Private.CoreLib and thus need to directly reference other partial facades to avoid type conflicts.
+All libraries should use `<Reference Include="..." />` for all their project references. That will cause them to be resolved against a targeting pack (i.e. `bin\ref\netcoreapp5.0` or `\bin\ref\netstanard2.0`) based on the project target framework. There should not be any direct project references to other libraries. The only exception to that rule right now is for partial facades which directly reference System.Private.CoreLib and thus need to directly reference other partial facades to avoid type conflicts.
<BR>//**CONSIDER**: just using Reference and use a reference to System.Private.CoreLib as a trigger to turn the other References into a ProjectReference automatically. That will allow us to have consistency where all projects just use Reference.
### src output
The output for the src product build will be a flat runtime folder into the following directory:
-`bin\runtime\$(BuildConfiguration)`
+`bin\runtime\$(BuildSettings)`
-Note: The `BuildConfiguration` is the global property and not the project configuration because we need all projects to output to the same runtime directory no matter which compatible configuration we select and build the project with.
+Note: The `BuildSettings` is a global property and not the project setting because we need all projects to output to the same runtime directory no matter which compatible target framework we select and build the project with.
+```<BuildSettings>$(BuildTargetFramework)-$(OSGroup)-(Configuration)-(ArchGroup)</BuildSettings>```
## pkg
In the pkg directory for the library there should be only **one** `.pkgproj` for the primary package for the library. If the library has platform-specific implementations those should be split into platform specific projects in a subfolder for each platform. (see [Package projects](./package-projects.md))
TODO: Outline changes needed for pkgprojs
## tests
-Similar to the src projects tests projects will define a `BuildConfigurations` property so they can list out the set of build configurations they support.
+Similar to the src projects tests projects will define a `TargetFrameworks` property so they can list out the set of target frameworks they support.
-Tests should not have any `<Reference>` or `<ProjectReference>` items in their project because they will automatically reference everything in the targeting pack based on the
configuration they are building in. The only exception to this is a `<ProjectReference>` can be used to reference other test helper libraries or assets.
+Tests should not have any `<Reference>` or `<ProjectReference>` items in their project because they will automatically reference everything in the targeting pack based on the
TargetFramework they are building in. The only exception to this is a `<ProjectReference>` can be used to reference other test helper libraries or assets.
-In order to build and run a test project in a given configuration a root level build.cmd/sh must have been completed for that configuration first. Tests will run on the live built runtime at `bin\runtime\$(BuildConfiguration)`.
+In order to build and run a test project in a given build target framework a root level build.cmd/sh must have been completed for that build target framework first. Tests will run on the live built runtime at `bin\runtime\$(BuildSettings)`.
TODO: We need update our test host so that it can run from the shared runtime directory as well as resolve assemblies from the test output directory.
### tests output
All test outputs should be under
-`bin\tests\$(MSBuildProjectName)\$(BuildConfiguration)` or
-`bin\tests\$(MSBuildProjectName)\netstandard`
+`bin\tests\$(MSBuildProjectName)\$(TargetFramework)` or
+`bin\tests\$(MSBuildProjectName)\netstandard2.0`
## Facades
Facade are unique in that they don't have any code and instead are generated by finding a contract reference assembly with the matching identity and generating type forwards for all the types to where they live in the implementation assemblies (aka facade seeds). There are also partial facades which contain some type forwards as well as some code definitions. All the various build configurations should be contained in the one csproj file per library.
- The source code file should contain only one class. The only exception is small supporting structs, enums, nested classes, or delegates that only apply to the class can also be contained in the source file.
- The source code file should be named `<class>.cs` and should be placed in a directory structure that matches its namespace relative to its project directory. Ex. `System\IO\Stream.cs`
- Larger nested classes should be factored out into their own source files using a partial class and the file name should be `<class>.<nested class>.cs`.
-- Classes that are forked based on configuration should have file names `<class>.<configuration>.cs`.
- - Where `<configuration>` is one of `$(OSGroup)`, `$(TargetGroup)`, `$(ConfigurationGroup)`, or `$(Platform)`, matching exactly by case to ensure consistency.
+- Classes that are forked based on BuildSettings should have file names `<class>.<BuildSettings>.cs`.
+ - Where `<BuildSettings>` is one of `$(OSGroup)`, `$(TargetFramework)`, `$(Configuration)`, or `$(Platform)`, matching exactly by case to ensure consistency.
- Classes that are forked based on a feature set should have file names `<class>.<feature>.cs`.
- Where `<feature>` is the name of something that causes a fork in code that isn't a single configuration. Examples:
- `.CoreCLR.cs` - implementation specific to CoreCLR runtime
## Define naming convention
As mentioned in [Conventions for forked code](#conventions-for-forked-code) `#ifdef`ing the code is the last resort as it makes code harder to maintain overtime. If we do need to use `#ifdef`'s we should use the following conventions:
-- Defines based on conventions should be one of `$(OSGroup)`, `$(TargetGroup)`, `$(ConfigurationGroup)`, or `$(Platform)`, matching exactly by case to ensure consistency.
+- Defines based on conventions should be one of `$(OSGroup)`, `$(TargetFramework)`, `$(Configuration)`, or `$(Platform)`, matching exactly by case to ensure consistency.
- Examples: `<DefineConstants>$(DefineConstants);net46</DefineConstants>`
- Defines based on convention should match the pattern `FEATURE_<feature name>`. These can unique to a given library project or potentially shared (via name) across multiple projects.
## For System.Runtime
-These steps can also be applied to some unique assemblies which depend on changes in System.Private.Corelib coming from [coreclr](https://github.com/dotnet/coreclr) (partial facades like [System.Memory](https://github.com/dotnet/corefx/blob/83711167ee74d2e87cf2d5ed3508c94044bb7edc/src/System.Memory/src/System.Memory.csproj#L6), for example).
-1) Build coreclr release.
-2) Build corefx release with coreclr bits (see (// TODO //)) for more details).
-3) Run `msbuild /t:GenerateReferenceSource /p:ConfigurationGroup=Release` from the System.Runtime/ref directory.
-4) Filter out all unrelated changes and extract the changes you care about (ignore certain attributes being removed). Generally, this step is not required for other reference assemblies.
+These steps can also be applied to some unique assemblies which depend on changes in System.Private.Corelib. (partial facades like System.Memory, for example).
+
+1) Run `dotnet build -c Release /t:GenerateReferenceSource` from the System.Runtime/ref directory.
+2) Filter out all unrelated changes and extract the changes you care about (ignore certain attributes being removed). Generally, this step is not required for other reference assemblies.
The above commands will give you libraries in "debug" configuration (the default) using a runtime in "release" configuration which hopefully you built earlier.
-The libraries build has two logical components, the native build which produces the "shims" (which provide a stable interface between the OS and managed code) and the managed build which produces the MSIL code and NuGet packages that make up CoreFX. The commands above will build both.
+The libraries build has two logical components, the native build which produces the "shims" (which provide a stable interface between the OS and managed code) and the managed build which produces the MSIL code and NuGet packages that make up Libraries. The commands above will build both.
-The build configurations are generally defaulted based on where you are building (i.e. which OS or which architecture) but we have a few shortcuts for the individual properties that can be passed to the build scripts:
+The build settings(TargetFramework, OSGroup, Configuration, Architecture) are generally defaulted based on where you are building (i.e. which OS or which architecture) but we have a few shortcuts for the individual properties that can be passed to the build scripts:
-- `-framework|-f` identifies the target framework for the build. Possible values include `netcoreapp5.0` (currently the latest .NET Core version) or `net472`. (msbuild property `TargetFramework`)
+- `-framework|-f` identifies the target framework for the build. Possible values include `netcoreapp5.0` (currently the latest .NET Core version) or `net472`. (msbuild property `BuildTargetFramework`)
- `-os` identifies the OS for the build. It defaults to the OS you are running on but possible values include `Windows_NT`, `Unix`, `Linux`, or `OSX`. (msbuild property `OSGroup`)
-- `-configuration|-c Debug|Release` controls the optimization level the compilers use for the build. It defaults to `Debug`. (msbuild property `ConfigurationGroup`)
+- `-configuration|-c Debug|Release` controls the optimization level the compilers use for the build. It defaults to `Debug`. (msbuild property `Configuration`)
- `-arch` identifies the architecture for the build. It defaults to `x64` but possible values include `x64`, `x86`, `arm`, or `arm64`. (msbuild property `ArchGroup`)
-For more details on the build configurations see [project-guidelines](../../../coding-guidelines/project-guidelines.md#build-pivots).
+For more details on the build settings see [project-guidelines](../../../coding-guidelines/project-guidelines.md#build-pivots).
If you invoke the build script without any actions, the default action chain `-restore -build` is executed. You can chain multiple actions together (e.g., `-restore -build -buildtests`) and they will execute in the appropriate order. Note that if you specify actions like `-build` explicitly, you likely need to explicitly add `-restore` as well.
As `dotnet build` works on both Unix and Windows and calls the restore target implicitly, we will use it throughout this guide.
-Under the src directory is a set of directories, each of which represents a particular assembly in CoreFX. See Library Project Guidelines section under [project-guidelines](../../../coding-guidelines/project-guidelines.md) for more details about the structure.
+Under the src directory is a set of directories, each of which represents a particular assembly in Libraries. See Library Project Guidelines section under [project-guidelines](../../../coding-guidelines/project-guidelines.md) for more details about the structure.
For example the src\libraries\System.Diagnostics.DiagnosticSource directory holds the source code for the System.Diagnostics.DiagnosticSource.dll assembly.
-You can build the DLL for System.Diagnostics.DiagnosticSource.dll by going to the `src\libraries\System.Diagnostics.DiagnosticsSource\src` directory and typing `dotnet build`. The DLL ends up in `artifacts\bin\AnyOS.AnyCPU.Debug\System.Diagnostics.DiagnosticSource` as well as `artifacts\bin\runtime\[BuildConfiguration]`.
+You can build the DLL for System.Diagnostics.DiagnosticSource.dll by going to the `src\libraries\System.Diagnostics.DiagnosticsSource\src` directory and typing `dotnet build`. The DLL ends up in `artifacts\bin\AnyOS.AnyCPU.Debug\System.Diagnostics.DiagnosticSource` as well as `artifacts\bin\runtime\[$(BuildTargetFramework)-$(OSGroup)-$(Configuration)-$(ArchGroup)]`.
You can build the tests for System.Diagnostics.DiagnosticSource.dll by going to
`src\libraries\System.Diagnostics.DiagnosticSource\tests` and typing `dotnet build`.
Some libraries might also have a ref and/or a pkg directory and you can build them in a similar way by typing `dotnet build` in that directory.
-For libraries that have multiple build configurations the configurations will be listed in the `<BuildConfigurations>` property group, commonly found in a configurations.props file next to the csproj. When building the csproj for a configuration the most compatible one in the list will be chosen and set for the build. For more information about `BuildConfigurations` see [project-guidelines](../../../coding-guidelines/project-guidelines.md).
+For libraries that have multiple target frameworks the target frameworks will be listed in the `<TargetFrameworks>` property group. When building the csproj for a BuildTargetFramework the most compatible target framework in the list will be chosen and set for the build. For more information about `TargetFrameworks` see [project-guidelines](../../../coding-guidelines/project-guidelines.md).
**Examples**
### Building in Release or Debug
By default, building from the root or within a project will build the libraries in Debug mode.
-One can build in Debug or Release mode from the root by doing `./build.sh -subsetCategory libraries -c Release` or `./build.sh -subsetCategory libraries -c Debug` or when building a project by specifying `-c Debug/Release` after the `dotnet build` command.
+One can build in Debug or Release mode from the root by doing `./build.sh -subsetCategory libraries -c Release` or `./build.sh -subsetCategory libraries -c Debug`.
### Building other Architectures
$ ./build.sh --arch arm /p:BuildNative=false
-The output is at `artifacts/bin/[BuildConfiguration]` where `BuildConfiguration` looks something like `netcoreapp-<OSGroup>-Debug-<Architecture>`. Ex: `artifacts/bin/netcoreapp-Linux-Debug-x64`. For more details on the build configurations see [project-guidelines](/docs/coding-guidelines/project-guidelines.md)
+The output is at `artifacts/bin/[BuildSettings]` where `BuildSettings` looks something like `netcoreapp5.0-<OSGroup>-Debug-<Architecture>`. Ex: `artifacts/bin/netcoreapp5.0-Linux-Debug-x64`. For more details on the build configurations see [project-guidelines](/docs/coding-guidelines/project-guidelines.md)
Building corefx for Linux ARM Emulator
=======================================
Example building for armel
```
src/Native/build-native.sh armel
---> Output goes to artifacts/bin/runtime/netcoreapp-Linux-Debug-armel
+--> Output goes to artifacts/bin/runtime/netcoreapp5.0-Linux-Debug-armel
build /p:ArchGroup=x64 /p:BuildNative=false
---> Output goes to artifacts/bin/runtime/netcoreapp-Linux-Debug-x64
+--> Output goes to artifacts/bin/runtime/netcoreapp5.0-Linux-Debug-x64
```
The reason you need to build the managed portion for x64 is because it depends on runtime packages for the new architecture which don't exist yet so we use another existing architecture such as x64 as a proxy for building the managed binaries.
-Similar if you want to try and run tests you will have to copy the managed assemblies from the proxy directory (i.e. `netcoreapp-Linux-Debug-x64`) to the new architecture directory (i.e `netcoreapp-Linux-Debug-armel`) and run code via another host such as corerun because dotnet is at a higher level and most likely doesn't exist for the new architecture yet.
+Similar if you want to try and run tests you will have to copy the managed assemblies from the proxy directory (i.e. `netcoreapp5.0-Linux-Debug-x64`) to the new architecture directory (i.e `netcoreapp5.0-Linux-Debug-armel`) and run code via another host such as corerun because dotnet is at a higher level and most likely doesn't exist for the new architecture yet.
Once all the necessary builds are setup and packages are published the splitting of the build and manual creation of the runtime should no longer be necessary.
</ItemGroup>
```
-Ensure that the right `TargetGroup` (what we're testing) is set.
+Ensure that the right `BuildTargetFramework` (what we're testing) is set.
To identify which of the combinations failed, search for the following pattern in the output:
To run a test from a single Build Pivot combination, specify all properties and build the `csproj`:
```
-dotnet msbuild System.Net.ServicePoint.Tests.csproj /t:rebuildandtest /p:TargetGroup=netcoreapp2.0 /p:OuterLoop=true /p:xunitoptions=-showprogress /p:ConfigurationGroup=Debug
+dotnet build System.Net.ServicePoint.Tests.csproj -f netcoreapp2.0 /t:rebuildandtest /p:OuterLoop=true /p:xunitoptions=-showprogress
```
Will run the test using the following pivot values:
* Architecture: AnyCPU
#### Running tests in a different target framework
-Each test project can potentially have multiple build configurations. There are some tests that might be OS-specific, or might be testing an API that is available only on some target frameworks, so the `TargetFrameworks` property specifies the valid configurations. By default we will build and run only the default build configuration which is `netcoreapp`. The rest of the configurations will need to be built and ran by specifying the `BuildTargetFramework` option.
-
+Each test project can potentially have multiple target frameworks. There are some tests that might be OS-specific, or might be testing an API that is available only on some target frameworks, so the `TargetFrameworks` property specifies the valid target frameworks. By default we will build and run only the default build target framework which is `netcoreapp5.0`. The rest of the targetframeworks will need to be built and ran by specifying the BuildTargetFramework option.
```cmd
dotnet build src\libraries\System.Runtime\tests\System.Runtime.Tests.csproj /p:BuildTargetFramework=net472
```
<Project>
<!-- Honor the generic RuntimeConfiguration property. -->
<PropertyGroup>
- <RuntimeConfiguration Condition="'$(RuntimeConfiguration)' == ''">$(ConfigurationGroup)</RuntimeConfiguration>
+ <RuntimeConfiguration Condition="'$(RuntimeConfiguration)' == ''">$(Configuration)</RuntimeConfiguration>
<RuntimeConfiguration Condition="'$(RuntimeConfiguration)' == '' AND ('$(Configuration)' == 'Debug' OR '$(Configuration)' == 'Release')">$(Configuration)</RuntimeConfiguration>
<RuntimeConfiguration Condition="'$(RuntimeConfiguration)' == ''">Debug</RuntimeConfiguration>
<CoreCLRConfiguration Condition="'$(CoreCLRConfiguration)' == ''">$(RuntimeConfiguration)</CoreCLRConfiguration>
"build" { $arguments += " -build" }
"buildtests" { if ($build -eq $true) { $arguments += " /p:BuildTests=true" } else { $arguments += " -build /p:BuildTests=only" } }
"test" { $arguments += " -test" }
- "configuration" { $configuration = (Get-Culture).TextInfo.ToTitleCase($($PSBoundParameters[$argument])); $arguments += " /p:ConfigurationGroup=$configuration -configuration $configuration" }
+ "configuration" { $arguments += " -configuration $((Get-Culture).TextInfo.ToTitleCase($($PSBoundParameters[$argument])))" }
"runtimeConfiguration" { $arguments += " /p:RuntimeConfiguration=$((Get-Culture).TextInfo.ToTitleCase($($PSBoundParameters[$argument])))" }
"framework" { $arguments += " /p:BuildTargetFramework=$($PSBoundParameters[$argument].ToLowerInvariant())" }
"os" { $arguments += " /p:OSGroup=$($PSBoundParameters[$argument])" }
;;
-configuration|-c)
val="$(tr '[:lower:]' '[:upper:]' <<< ${2:0:1})${2:1}"
- arguments="$arguments /p:ConfigurationGroup=$val -configuration $val"
+ arguments="$arguments -configuration $val"
shift 2
;;
-framework|-f)
Must be enabled by setting BinPlaceILLinkTrimAssembly=true
-->
<ItemGroup Condition="'$(BinPlaceILLinkTrimAssembly)' == 'true'">
- <BinPlaceTargetFramework Include="$(BuildConfiguration)">
- <RuntimePath>$(ArtifactsBinDir)ILLinkTrimAssembly/$(BuildConfiguration)/trimmed</RuntimePath>
+ <BinPlaceTargetFramework Include="$(BuildSettings)">
+ <RuntimePath>$(ArtifactsBinDir)ILLinkTrimAssembly/$(BuildSettings)/trimmed</RuntimePath>
<ItemName>TrimmedItem</ItemName>
</BinPlaceTargetFramework>
- <BinPlaceTargetFramework Include="$(BuildConfiguration)">
- <RuntimePath>$(ArtifactsBinDir)ILLinkTrimAssembly/$(BuildConfiguration)/reports</RuntimePath>
+ <BinPlaceTargetFramework Include="$(BuildSettings)">
+ <RuntimePath>$(ArtifactsBinDir)ILLinkTrimAssembly/$(BuildSettings)/reports</RuntimePath>
<ItemName>TrimmingReport</ItemName>
</BinPlaceTargetFramework>
- <BinPlaceTargetFramework Include="$(BuildConfiguration)">
- <RuntimePath>$(ArtifactsBinDir)ILLinkTrimAssembly/$(BuildConfiguration)/pretrimmed</RuntimePath>
+ <BinPlaceTargetFramework Include="$(BuildSettings)">
+ <RuntimePath>$(ArtifactsBinDir)ILLinkTrimAssembly/$(BuildSettings)/pretrimmed</RuntimePath>
<ItemName>PreTrimmedItem</ItemName>
</BinPlaceTargetFramework>
</ItemGroup>
<HarvestStablePackage>false</HarvestStablePackage>
<!-- Validation will fail in case we were relying on harvested assets or assets not built to satisfy stated support -->
<SkipValidatePackage>true</SkipValidatePackage>
- <!-- Include All BuildConfigurations in package, so that whatever we're building for source build is included -->
- <PackageConfigurations>$(BuildConfigurations)</PackageConfigurations>
</PropertyGroup>
<Import Condition="Exists('$(PkgDir)baseline\baseline.props') and '$(MSBuildProjectExtension)' == '.pkgproj'" Project="$(PkgDir)baseline\baseline.props" />
#
# Build with RuntimeFlavor only. This excercise code paths where only Configuration is
-# specified. Catches cases where we depend on ConfigurationGroup also being specified
+# specified. Catches cases where we depend on Configuration also being specified
#
- template: /eng/pipelines/common/platform-matrix.yml
parameters:
echo "Input sources:"
echo " --runtime <location> Location of root of the binaries directory"
echo " containing the FreeBSD, NetBSD or Linux runtime"
- echo " default: <repo_root>/bin/testhost/netcoreapp-<OS>-<Configuration
Group>-<Arch>"
+ echo " default: <repo_root>/bin/testhost/netcoreapp-<OS>-<Configuration>-<Arch>"
echo " --corefx-tests <location> Location of the root binaries location containing"
echo " the tests to run"
echo " default: <repo_root>/artifacts/bin"
echo
echo "Flavor/OS/Architecture options:"
- echo " --configurationGroup <config> ConfigurationGroup to run (Debug/Release)"
+ echo " --configuration <config> Configuration to run (Debug/Release)"
echo " default: Debug"
echo " --os <os> OS to run (FreeBSD, NetBSD or Linux)"
echo " default: detect current OS"
ProjectRoot="$(dirname "$(dirname "$(realpath ${BASH_SOURCE[0]})")")"
# Location parameters
-# OS/ConfigurationGroup defaults
-ConfigurationGroup="Debug"
+# OS/Configuration defaults
+Configuration="Debug"
OSName=$(uname -s)
case $OSName in
FreeBSD)
fi
fi
- dirName="$1/netcoreapp-$OS-$ConfigurationGroup-$__Arch"
+ dirName="$1/netcoreapp-$OS-$Configuration-$__Arch"
if [ ! -d "$dirName" ]; then
echo "Nothing to test in $testProject"
return
--restrict-proj)
TestSelection=$2
;;
- --configurationGroup)
- ConfigurationGroup=$2
+ --configuration)
+ Configuration=$2
;;
--os)
OS=$2
if [ "$Runtime" == "" ]
then
- Runtime="$ProjectRoot/artifacts/bin/testhost/netcoreapp-$OS-$ConfigurationGroup-$__Arch"
+ Runtime="$ProjectRoot/artifacts/bin/testhost/netcoreapp-$OS-$Configuration-$__Arch"
fi
if [ "$CoreFxTests" == "" ]
# Check parameters up front for valid values:
-if [ ! "$ConfigurationGroup" == "Debug" ] && [ ! "$ConfigurationGroup" == "Release" ]
+if [ ! "$Configuration" == "Debug" ] && [ ! "$Configuration" == "Release" ]
then
- echo "error: ConfigurationGroup should be Debug or Release"
+ echo "error: Configuration should be Debug or Release"
exit 1
fi
ensure_binaries_are_present
-# Walk the directory tree rooted at src bin/tests/$OS.AnyCPU.$ConfigurationGroup/
+# Walk the directory tree rooted at src bin/tests/$OS.AnyCPU.$Configuration/
TestsFailed=0
numberOfProcesses=0
Text="Skipping tests in $(AssemblyName) because it is not supported on $(TargetOS)" />
<Message Condition="'$(ConfigurationErrorMsg)' != ''"
- Text="Skipping tests in $(AssemblyName) because there is no configuration compatible with the current BuildConfiguration." />
+ Text="Skipping tests in $(AssemblyName) because there is no TargetFramework compatible with the current BuildTargetFramework." />
</Target>
<Target Name="RunTests"
echo "Input sources:"
echo " --runtime <location> Location of root of the binaries directory"
echo " containing the FreeBSD, Linux, NetBSD or OSX runtime"
- echo " default: <repo_root>/bin/testhost/netcoreapp-<OS>-<Configuration
Group>-<Arch>"
+ echo " default: <repo_root>/bin/testhost/netcoreapp-<OS>-<Configuration>-<Arch>"
echo " --corefx-tests <location> Location of the root binaries location containing"
echo " the tests to run"
echo " default: <repo_root>/bin"
echo
echo "Flavor/OS/Architecture options:"
- echo " --configurationGroup <config> ConfigurationGroup to run (Debug/Release)"
+ echo " --configuration <config> Configuration to run (Debug/Release)"
echo " default: Debug"
echo " --os <os> OS to run (FreeBSD, Linux, NetBSD or OSX)"
echo " default: detect current OS"
echo " --coreclr-coverage Optional argument to get coreclr code coverage reports"
echo " --coreclr-objs <location> Location of root of the object directory"
echo " containing the FreeBSD, Linux, NetBSD or OSX coreclr build"
- echo " default: <repo_root>/bin/obj/<OS>.x64.<ConfigurationGroup"
+ echo " default: <repo_root>/bin/obj/<OS>.x64.<Configuration"
echo " --coreclr-src <location> Location of root of the directory"
echo " containing the coreclr source files"
echo
ProjectRoot="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"
# Location parameters
-# OS/ConfigurationGroup defaults
-ConfigurationGroup="Debug"
+# OS/Configuration defaults
+Configuration="Debug"
OSName=$(uname -s)
case $OSName in
fi
fi
- dirName="$1/netcoreapp-$OS-$ConfigurationGroup-$__Arch"
+ dirName="$1/netcoreapp-$OS-$Configuration-$__Arch"
if [ ! -d "$dirName" ]; then
echo "===== Nothing to test in $testProject"
return
TestSelection=$2
;;
- --configurationGroup)
- ConfigurationGroup=$2
+ --configuration)
+ Configuration=$2
;;
--os)
if [ "$Runtime" == "" ]
then
- Runtime="$ProjectRoot/bin/testhost/netcoreapp-$OS-$ConfigurationGroup-$__Arch"
+ Runtime="$ProjectRoot/bin/testhost/netcoreapp-$OS-$Configuration-$__Arch"
fi
if [ "$CoreFxTests" == "" ]
# Check parameters up front for valid values:
-if [ ! "$ConfigurationGroup" == "Debug" ] && [ ! "$ConfigurationGroup" == "Release" ]
+if [ ! "$Configuration" == "Debug" ] && [ ! "$Configuration" == "Release" ]
then
- echo "error: ConfigurationGroup should be Debug or Release"
+ echo "error: Configuration should be Debug or Release"
exit 1
fi
ensure_binaries_are_present
-# Walk the directory tree rooted at src bin/tests/$OS.AnyCPU.$ConfigurationGroup/
+# Walk the directory tree rooted at src bin/tests/$OS.AnyCPU.$Configuration/
numberOfProcesses=0
</PropertyGroup>
<PropertyGroup>
- <!--
- These *Group properties are only intended to enable passing them individually at the command line to initialize
- BuildConfiguration. They will be overwritten by our configurations/configuration.props file and defaulted
- based on Configuration for the individual projects which is selected based on BuildConfiguration.
-
- See Documentation/coding-guidelines/project-guidelines.md for more details on our configurations.
- -->
<OSGroup Condition="'$(OSGroup)' == ''">$(DefaultOSGroup)</OSGroup>
- <!-- We can remove this after removing this from the Arcade target.-->
- <BuildOS>$(OSGroup)</BuildOS>
</PropertyGroup>
<Import Sdk="Microsoft.DotNet.Build.Tasks.TargetFramework.Sdk" Project="Sdk.props" />
the build system to use webassembly as the RuntimeOS for produced package RIDs. -->
<RuntimeOS Condition="'$(OSGroup)' == 'WebAssembly'">$(OSGroup.ToLowerInvariant())</RuntimeOS>
- <!-- Initialize BuildConfiguration from the individual properties if it wasn't already explicitly set -->
+ <!-- Initialize BuildSettings from the individual properties if it wasn't already explicitly set -->
<Configuration Condition="'$(Configuration)'==''">Debug</Configuration>
- <BuildConfiguration Condition="'$(BuildConfiguration)' == ''">$(BuildTargetFramework)-$(OSGroup)-$(Configuration)-$(ArchGroup)</BuildConfiguration>
-
- <!-- if PKGPROJ doesn't set BuildConfigurations, make sure it only builds for TargetGroup=package or BuildAllConfigurations -->
- <BuildConfigurations Condition="'$(MSBuildProjectExtension)' == '.pkgproj' and '$(BuildConfigurations)' == ''">package</BuildConfigurations>
+ <BuildSettings Condition="'$(BuildSettings)' == ''">$(BuildTargetFramework)-$(OSGroup)-$(Configuration)-$(ArchGroup)</BuildSettings>
</PropertyGroup>
<Choose>
-->
<AppendTargetFrameworkToOutputPath>false</AppendTargetFrameworkToOutputPath>
- <RuntimePath Condition="'$(RuntimePath)' == ''">$([MSBuild]::NormalizeDirectory('$(ArtifactsBinDir)', 'runtime', '$(BuildConfiguration)'))</RuntimePath>
+ <RuntimePath Condition="'$(RuntimePath)' == ''">$([MSBuild]::NormalizeDirectory('$(ArtifactsBinDir)', 'runtime', '$(BuildSettings)'))</RuntimePath>
<RefRootPath>$([MSBuild]::NormalizeDirectory('$(ArtifactsBinDir)', 'ref'))</RefRootPath>
- <BuildConfigurationRefPath>$([MSBuild]::NormalizeDirectory('$(RefRootPath)', '$(BuildTargetFramework)'))</BuildConfigurationRefPath>
+ <BuildTargetFrameworkRefPath>$([MSBuild]::NormalizeDirectory('$(RefRootPath)', '$(BuildTargetFramework)'))</BuildTargetFrameworkRefPath>
<RefPath>$([MSBuild]::NormalizeDirectory('$(RefRootPath)', '$(TargetFramework)'))</RefPath>
<NetStandard20RefPath>$([MSBuild]::NormalizeDirectory('$(RefRootPath)', 'netstandard2.0'))</NetStandard20RefPath>
<NetStandard21RefPath>$([MSBuild]::NormalizeDirectory('$(RefRootPath)', 'netstandard2.1'))</NetStandard21RefPath>
<NETCoreAppPackageRefPath>$(ArtifactsBinDir)pkg\$(NetCoreAppCurrent)\ref</NETCoreAppPackageRefPath>
<NETCoreAppPackageRuntimePath>$(ArtifactsBinDir)pkg\$(NetCoreAppCurrent)\lib</NETCoreAppPackageRuntimePath>
- <TestHostRootPath>$([MSBuild]::NormalizeDirectory('$(ArtifactsBinDir)', 'testhost', '$(BuildConfiguration)'))</TestHostRootPath>
+ <TestHostRootPath>$([MSBuild]::NormalizeDirectory('$(ArtifactsBinDir)', 'testhost', '$(BuildSettings)'))</TestHostRootPath>
<!-- interop is not available on NETStandard1.0 -->
<IncludeDllSafeSearchPathAttribute Condition="'$(TargetFramework)' == 'netstandard1.0'">false</IncludeDllSafeSearchPathAttribute>
<ItemGroup Condition="'@(BinPlaceTargetFrameworks)' == ''">
<!-- binplace to directories for the target vertical -->
<BinPlaceTargetFrameworks Include="$(BuildTargetFramework)-$(OSGroup)" Condition="'$(BinPlaceForTargetVertical)' == 'true'">
- <RefPath>$(BuildConfigurationRefPath)</RefPath>
+ <RefPath>$(BuildTargetFrameworkRefPath)</RefPath>
<RuntimePath>$(RuntimePath)</RuntimePath>
</BinPlaceTargetFrameworks>
<!-- binplace to directories for packages -->
<RuntimePath>$(TestHostRootPath)</RuntimePath>
</BinPlaceTargetFrameworks>
- <!-- binplace targeting packs which may be different from BuildConfiguration -->
+ <!-- binplace targeting packs which may be different from Build TargetFramework -->
<BinPlaceTargetFrameworks Include="netstandard2.0">
<RefPath>$(NetStandard20RefPath)</RefPath>
</BinPlaceTargetFrameworks>
<BinPlaceTargetFrameworks Condition="'$(BuildAllConfigurations)' == 'true'" Include="@(AllTargetFrameworkList)">
<RefPath>$(RefRootPath)%(Identity)/</RefPath>
</BinPlaceTargetFrameworks>
- <!-- for BuildAllConfigurations make sure runtimepaths are created for all vertical targetgroups. -->
+ <!-- for BuildAllConfigurations make sure runtimepaths are created for all vertical target frameworks. -->
<BinPlaceTargetFrameworks Condition="'$(BuildAllConfigurations)' == 'true' and ('$(BinPlaceForTargetVertical)' == 'true' or ('$(TargetFramework)' != '$(NetCoreAppCurrent)' and '$(TargetFrameworkSuffix)' == ''))" Include="$(NetCoreAppCurrent)-$(OSGroup)">
<RuntimePath>$(ArtifactsBinDir)runtime/%(Identity)-$(Configuration)-$(ArchGroup)</RuntimePath>
</BinPlaceTargetFrameworks>
<Import Project="$(RepositoryEngineeringDir)illink.targets" />
<Import Project="$(RepositoryEngineeringDir)notSupported.SourceBuild.targets" Condition="'$(DotNetBuildFromSource)' == 'true'" />
- <Target Name="ReportConfigurationErrorMessage"
- BeforeTargets="AssignProjectConfiguration"
- Condition="'$(BuildConfigurations)' != ''" >
- <Message Importance="Low" Text="$(MSBuildProjectFullPath), C: $(Configuration) BC: $(BuildConfiguration) BCs: $(BuildConfigurations)" />
- <Message Importance="High" Condition="'$(ConfigurationErrorMsg)' != ''" Text="$(MSBuildProjectFullPath) ConfigurationErrorMessage: $(ConfigurationErrorMsg)" />
- </Target>
-
<Target Name="GenerateReferenceSource">
<PropertyGroup>
<_RefSourceFileOutputPath>$([MSBuild]::NormalizePath('$(MSBuildProjectDirectory)', '..', 'ref', '$(AssemblyName).cs'))</_RefSourceFileOutputPath>
</PropertyGroup>
<ItemGroup>
<ContractProject Include="..\ref\System.Linq.csproj">
- <TargetGroup>$(NetCoreAppCurrent)</TargetGroup>
+ <BuildTargetFramework>$(NetCoreAppCurrent)</BuildTargetFramework>
</ContractProject>
</ItemGroup>
<ItemGroup> <!-- Optimize for speed -->
<Import Project="$(MSBuildThisFileDirectory)Directory.Build.props" />
<PropertyGroup Condition="'$(DotNetBuildFromSource)' == 'true'">
- <AdditionalBuildConfigurations>$(AdditionalBuildConfigurations);package-$(Configuration)</AdditionalBuildConfigurations>
+ <AdditionalBuildTargetFrameworks>$(AdditionalBuildTargetFrameworks);package-$(Configuration)</AdditionalBuildTargetFrameworks>
</PropertyGroup>
<ItemGroup Condition="'$(SkipManagedPackageBuild)' != 'true'">
<Project Remove="@(Project)" />
<Project Include="@(_projectsToBuild)" />
</ItemGroup>
-
- <PropertyGroup>
- <!-- don't use BuildConfiguration filtering -->
- <FilterProjectsByBuildConfiguration>false</FilterProjectsByBuildConfiguration>
- </PropertyGroup>
</Target>
</Project>
Package testing doesn't run on xunit. -->
<EnableXunitReporter Condition="'$(BuildAllConfigurations)' != 'true'">true</EnableXunitReporter>
- <TestArchiveRuntimeFile>$(TestArchiveRuntimeRoot)test-runtime-$(BuildConfiguration).zip</TestArchiveRuntimeFile>
+ <TestArchiveRuntimeFile>$(TestArchiveRuntimeRoot)test-runtime-$(BuildSettings).zip</TestArchiveRuntimeFile>
<TestArchiveRuntimeFile Condition="'$(BuildAllConfigurations)' == 'true'">$(TestArchiveRuntimeRoot)packages-testPayload-$(Configuration).zip</TestArchiveRuntimeFile>
<!-- The helix runtime payload and the tests to run -->
<HelixArchitecture>$(ArchGroup)</HelixArchitecture>
<!-- This property is used to show the tests results in Azure Dev Ops. By setting this property the
- test run name will be displayed as $(BuildConfiguration)-$(HelixTargetQueue) -->
- <TestRunNamePrefix>$(BuildConfiguration)-</TestRunNamePrefix>
+ test run name will be displayed as $(BuildSettings)-$(HelixTargetQueue) -->
+ <TestRunNamePrefix>$(BuildSettings)-</TestRunNamePrefix>
<TestRunNamePrefix Condition="'$(TestRunNamePrefixSuffix)' != ''">$(TestRunNamePrefix)$(TestRunNamePrefixSuffix)-</TestRunNamePrefix>
<FailOnTestFailure Condition="'$(WaitForWorkItemCompletion)' != ''">$(WaitForWorkItemCompletion)</FailOnTestFailure>
<ApiCompatBaselineIgnoreFile>$(MSBuildThisFileDirectory)ApiCompatBaseline.$(ApiCompatTarget).netfx461.ignore.txt</ApiCompatBaselineIgnoreFile>
<ApiCompatNSBaselineFile>$(MSBuildThisFileDirectory)ApiCompatBaseline.$(ApiCompatTarget).netstandard.txt</ApiCompatNSBaselineFile>
<ApiCompatNSOnlyBaselineFile>$(MSBuildThisFileDirectory)ApiCompatBaseline.$(ApiCompatTarget).netstandardOnly.txt</ApiCompatNSOnlyBaselineFile>
- <ApiCompatImplementationDirs>$(BuildConfigurationRefPath.TrimEnd('\/'))</ApiCompatImplementationDirs>
+ <ApiCompatImplementationDirs>$(BuildTargetFrameworkRefPath.TrimEnd('\/'))</ApiCompatImplementationDirs>
<!-- Set to true to build this project -->
<BaselineApiCompat Condition="'$(BaselineApiCompat)' == ''">false</BaselineApiCompat>
<_RunApiCompat>true</_RunApiCompat>
<Target Name="BuildAllProjects">
<MSBuild Targets="Build"
Projects="@(Project)"
- Properties="BuildAllProjects=true;BuildConfiguration=$(BuildConfiguration);%(Project.AdditionalProperties)"
+ Properties="BuildAllProjects=true;%(Project.AdditionalProperties)"
BuildInParallel="true"
ContinueOnError="ErrorAndStop" />
<MSBuild Targets="Test"
Projects="@(Project)"
Condition="'$(SerializeProjects)' == 'true' and '%(Identity)' != ''"
- Properties="TestAllProjects=true;BuildConfiguration=$(BuildConfiguration)"
+ Properties="TestAllProjects=true"
ContinueOnError="ErrorAndContinue" />
<MSBuild Targets="Test"
Projects="@(Project)"
Condition="'$(SerializeProjects)' != 'true'"
- Properties="TestAllProjects=true;BuildConfiguration=$(BuildConfiguration)"
+ Properties="TestAllProjects=true"
BuildInParallel="true"
ContinueOnError="ErrorAndContinue" />
projects / platform / upstream / dotnet / runtime.git / commitdiff