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
Organize some markdowns and fix links (dotnet#1159)
* Move files into hierarchy
* fix more links
* Fix botr and features links
* Remove bad apostrophe
* spelling
* Apply suggestions from code review
Co-Authored-By: Youssef Victor <31348972+Youssef1313@users.noreply.github.com>
* Update docs/coding-guidelines/package-projects.md
Co-Authored-By: Jan Kotas <jkotas@microsoft.com>
Co-authored-by: Youssef Victor <31348972+Youssef1313@users.noreply.github.com>
Co-authored-by: Jan Kotas <jkotas@microsoft.com>
Copy file name to clipboardExpand all lines: CONTRIBUTING.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -157,6 +157,6 @@ See [IdnMapping.cs](./src/libraries/System.Private.CoreLib/src/System/Globalizat
157
157
158
158
### Porting Files from Other Projects
159
159
160
-
There are many good algorithms implemented in other languages that would benefit the .NET Core project. The rules for porting a Java file to C#, for example, are the same as would be used for copying the same file, as described above.
160
+
There are many good algorithms implemented in other languages that would benefit the .NET Core project. The rules for porting a Java file to C#, for example, are the same as would be used for copying the same file, as described above.
161
161
162
162
[Clean-room](https://en.wikipedia.org/wiki/Clean_room_design) implementations of existing algorithms that are not permissively licensed will generally not be accepted. If you want to create or nominate such an implementation, please create an issue to discuss the idea.
Copy file name to clipboardExpand all lines: docs/coding-guidelines/EventLogging.md
+3-3Lines changed: 3 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -6,14 +6,14 @@ Event Logging is a mechanism by which CoreClr can provide a variety of informati
6
6
7
7
# Adding Events to the Runtime
8
8
9
-
- Edit the [Event manifest](../../src/vm/ClrEtwAll.man) to add a new event. For guidelines on adding new events, take a look at the existing events in the manifest and this guide for [ETW Manifests](https://msdn.microsoft.com/en-us/library/dd996930%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396).
9
+
- Edit the [Event manifest](../../src/coreclr/src/vm/ClrEtwAll.man) to add a new event. For guidelines on adding new events, take a look at the existing events in the manifest and this guide for [ETW Manifests](https://msdn.microsoft.com/en-us/library/dd996930%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396).
10
10
- The build system should automatically generate the required artifacts for the added events.
11
-
- Add entries in the [exclusion list](../../src/vm/ClrEtwAllMeta) if necessary
11
+
- Add entries in the [exclusion list](../../src/coreclr/src/vm/ClrEtwAllMeta.lst) if necessary
12
12
- The Event Logging Mechanism provides the following two functions, which can be used within the VM:
13
13
- **FireEtw**EventName, this is used to trigger the event
14
14
- **EventEnabled**EventName, this is used to see if any consumer has subscribed to this event
15
15
16
16
17
17
# Adding New Logging System
18
18
19
-
Though the the Event logging system was designed for ETW, the build system provides a mechanism, basically an [adapter script- genXplatEventing.py](../../src/scripts/genXplatEventing.py) so that other Logging System can be added and used by CoreClr. An Example of such an extension for [LTTng logging system](https://lttng.org/) can be found in [genXplatLttng.py](../../src/scripts/genXplatLttng.py)
19
+
Though the the Event logging system was designed for ETW, the build system provides a mechanism, basically an [adapter script- genEventing.py](../../src/coreclr/src/scripts/genEventing.py) so that other Logging System can be added and used by CoreClr. An Example of such an extension for [LTTng logging system](https://lttng.org/) can be found in [genLttngProvider.py](../../src/coreclr/src/scripts/genLttngProvider.py)
The makeup of a package folder is primarily a grouping of project references to the projects that compose that package. Settings within each referenced project determines where that asset will be placed in the package. For example, reference assembly projects will be placed under the `ref/{targetMoniker}` folder in the package and implementations will be under either `lib/{targetMoniker}` or `runtimes/{rid}/lib/{targetMoniker}`. Whenever NuGet evaluates a package in the context of a referencing project it will choose the best compile time asset (preferring `ref`, then falling back to `lib`) and runtime asset (preferring `runtimes/{rid}/lib` and falling back to `lib`) for every package that is referenced. For more information see http://docs.nuget.org/.
218
219
219
-
Asset projects (`.csproj`, `.vbproj`, or `.depproj`) can control their `{targetMoniker}` using the `PackageTargetFramework` property in the project file. Similarly `{rid}` is controlled using the `PackageTargetRuntime` property. In the corefx repo we automatically select default values for these properties based on the [Build pivots](#build-pivots). These can be overridden in the project reference using metadata of the same name, but this is rarely needed.
220
+
Asset projects (`.csproj`, `.vbproj`, or `.depproj`) can control their `{targetMoniker}` using the `PackageTargetFramework` property in the project file. Similarly `{rid}` is controlled using the `PackageTargetRuntime` property. For the libraries we automatically select default values for these properties based on the build pivots. These can be overridden in the project reference using metadata of the same name, but this is rarely needed.
220
221
221
222
The primary thing that the library author needs to do in order to ensure the correct asset selection is:
Copy file name to clipboardExpand all lines: docs/coding-guidelines/performance-guidelines.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -5,7 +5,7 @@ Different applications have different needs when it comes to performance. For l
5
5
6
6
Much has been written about writing high-performance code in C#. This page provides links to some of that material and will expand over time as additional resources are found and identified as being relevant and useful.
7
7
8
-
You can read [CoreCLR Performance Requirements](../../coreclr/project-docs/performance-guidelines.md) to learn more.
8
+
You can read [CoreCLR Performance Requirements](../project/performance-guidelines.md) to learn more.
Copy file name to clipboardExpand all lines: docs/coding-guidelines/project-guidelines.md
+2-1Lines changed: 2 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -244,7 +244,8 @@ Each source file should use the following guidelines
244
244
-`.WinRT.cs` - implementation based on [WinRT](https://en.wikipedia.org/wiki/Windows_Runtime)
245
245
246
246
## Define naming convention
247
-
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:
247
+
248
+
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:
248
249
- Defines based on conventions should be one of `$(OSGroup)`, `$(TargetGroup)`, `$(ConfigurationGroup)`, or `$(Platform)`, matching exactly by case to ensure consistency.
- 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.
This document provides the steps you need to take to update the reference assembly when adding new **public** APIs to an implementation assembly (post [API Review](https://github.com/dotnet/corefx/blob/master/Documentation/coding-guidelines/adding-api-guidelines.md)).
1
+
This document provides the steps you need to take to update the reference assembly when adding new **public** APIs to an implementation assembly (post [API Review](adding-api-guidelines.md)).
2
2
3
-
## For most assemblies within corefx
4
-
1) Implement the API in the source assembly and [build it](../project-docs/developer-guide.md#building-individual-libraries).
5
-
2) Run the following command (from the src directory) `msbuild /t:GenerateReferenceSource` to update the reference assembly**.
6
-
3) Navigate to the ref directory and build the reference assembly.
7
-
4) Add, build, and run tests.
3
+
## For most assemblies within libraries
4
+
5
+
1. Implement the API in the source assembly and [build it](../workflow/building/libraries/README.md#building-individual-libraries).
6
+
2. Run the following command (from the src directory) `msbuild /t:GenerateReferenceSource` to update the reference assembly**.
7
+
3. Navigate to the ref directory and build the reference assembly.
8
+
4. Add, build, and run tests.
8
9
9
10
****Note:** If you already added the new API to the reference source, re-generating it (after building the source assembly) will update it to be fully qualified and placed in the correct order. This can be done by running the `GenerateReferenceSource` command from the ref directory.
10
11
11
12
## For System.Runtime
13
+
12
14
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).
13
15
1) Build coreclr release.
14
-
2) Build corefx release with coreclr bits (see [Testing with private CoreCLR bits](../project-docs/developer-guide.md#testing-with-private-coreclr-bits) for more details).
16
+
2) Build corefx release with coreclr bits (see (// TODO //)) for more details).
15
17
3) Run `msbuild /t:GenerateReferenceSource /p:ConfigurationGroup=Release` from the System.Runtime/ref directory.
16
-
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.
18
+
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.
0 commit comments