You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
-`$(TargetOS) -> Windows | Linux | OSX | FreeBSD | [defaults to running OS when empty]`
33
33
-`$(Configuration) -> Release | [defaults to Debug when empty]`
34
34
-`$(TargetArchitecture) - x86 | x64 | arm | arm64 | [defaults to x64 when empty]`
@@ -82,7 +82,7 @@ When we have a project that has a `netstandard2.0` target framework that means t
82
82
A full or individual project build is centered around BuildTargetFramework, TargetOS, Configuration and TargetArchitecture.
83
83
84
84
1.`$(BuildTargetFramework), $(TargetOS), $(Configuration), $(TargetArchitecture)` can individually be passed in to change the default values.
85
-
2. If nothing is passed to the build then we will default value of these properties from the environment. Example: `netcoreapp5.0-[TargetOS Running On]-Debug-x64`.
85
+
2. If nothing is passed to the build then we will default value of these properties from the environment. Example: `net5.0-[TargetOS Running On]-Debug-x64`.
86
86
3. While Building an individual project from the VS, we build the project for all latest netcoreapp target frameworks.
87
87
88
88
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.
@@ -121,7 +121,7 @@ The output for the ref project build will be a flat targeting pack folder in the
121
121
## src
122
122
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.
123
123
124
-
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.
124
+
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\net5.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.
125
125
<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.
Copy file name to clipboardExpand all lines: docs/design/coreclr/jit/viewing-jit-dumps.md
+6-6Lines changed: 6 additions & 6 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -20,7 +20,7 @@ The first thing to do is setup the .NET Core app we want to dump. Here are the s
20
20
21
21
<PropertyGroup>
22
22
<OutputType>Exe</OutputType>
23
-
<TargetFramework>netcoreapp5.0</TargetFramework>
23
+
<TargetFramework>net5.0</TargetFramework>
24
24
<RuntimeIdentifier>win-x64</RuntimeIdentifier>
25
25
</PropertyGroup>
26
26
@@ -58,17 +58,17 @@ The first thing to do is setup the .NET Core app we want to dump. Here are the s
58
58
}
59
59
```
60
60
61
-
* After you've finished editing the code, run `dotnet restore` and `dotnet publish -c Release`. This should drop all of the binaries needed to run your app in `bin/Release/netcoreapp5.0/<rid>/publish`.
61
+
* After you've finished editing the code, run `dotnet restore` and `dotnet publish -c Release`. This should drop all of the binaries needed to run your app in `bin/Release/net5.0/<rid>/publish`.
62
62
* Overwrite the CLR dlls with the ones you've built locally. If you're a fan of the command line, here are some shell commands for doing this:
Copy file name to clipboardExpand all lines: docs/workflow/building/libraries/README.md
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -74,7 +74,7 @@ The libraries build has two logical components, the native build which produces
74
74
75
75
The build settings (BuildTargetFramework, TargetOS, 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:
76
76
77
-
-`-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`)
77
+
-`-framework|-f` identifies the target framework for the build. Possible values include `net5.0` (currently the latest .NET version) or `net472`. (msbuild property `BuildTargetFramework`)
78
78
-`-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 `TargetOS`)
79
79
-`-configuration|-c Debug|Release` controls the optimization level the compilers use for the build. It defaults to `Debug`. (msbuild property `Configuration`)
80
80
-`-arch` identifies the architecture for the build. It defaults to `x64` but possible values include `x64`, `x86`, `arm`, or `arm64`. (msbuild property `TargetArchitecture`)
@@ -98,7 +98,7 @@ By default the `build` script only builds the product libraries and none of the
98
98
99
99
- Building for different target frameworks (restore and build are implicit again as no action is passed in)
Copy file name to clipboardExpand all lines: docs/workflow/building/libraries/cross-building.md
+4-4Lines changed: 4 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -85,7 +85,7 @@ You can also build just managed code with:
85
85
86
86
$ ./build.sh --arch arm /p:BuildNative=false
87
87
88
-
The output is at `artifacts/bin/[BuildSettings]` where `BuildSettings` looks something like `netcoreapp5.0-<TargetOS>-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)
88
+
The output is at `artifacts/bin/[BuildSettings]` where `BuildSettings` looks something like `net5.0-<TargetOS>-Debug-<Architecture>`. Ex: `artifacts/bin/net5.0-Linux-Debug-x64`. For more details on the build configurations see [project-guidelines](/docs/coding-guidelines/project-guidelines.md)
89
89
90
90
Building corefx for Linux ARM Emulator
91
91
=======================================
@@ -118,14 +118,14 @@ When building for a new architecture you will need to build the native pieces se
118
118
Example building for armel
119
119
```
120
120
src/Native/build-native.sh armel
121
-
--> Output goes to artifacts/bin/runtime/netcoreapp5.0-Linux-Debug-armel
121
+
--> Output goes to artifacts/bin/runtime/net5.0-Linux-Debug-armel
--> Output goes to artifacts/bin/runtime/netcoreapp5.0-Linux-Debug-x64
124
+
--> Output goes to artifacts/bin/runtime/net5.0-Linux-Debug-x64
125
125
```
126
126
127
127
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.
128
128
129
-
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.
129
+
Similar if you want to try and run tests you will have to copy the managed assemblies from the proxy directory (i.e. `net5.0-Linux-Debug-x64`) to the new architecture directory (i.e `net5.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.
130
130
131
131
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.
#### Running tests on a different target framework
61
61
62
-
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, e.g.:
62
+
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 `net5.0`. The rest of the `TargetFrameworks` will need to be built and ran by specifying the `BuildTargetFramework` option, e.g.:
0 commit comments