From a29e031bf58f3d08f41b339fe9bd743e6358c3a1 Mon Sep 17 00:00:00 2001 From: Cijo Thomas Date: Tue, 10 Nov 2020 11:17:56 -0800 Subject: [PATCH 1/4] Use GA version of DiagnosticSource (#1500) * Use GA version of DiagnosticSource * fix space * Update bcl backages to be utpo 6.0 version --- NuGet.config | 1 - build/Common.props | 16 ++++++++-------- docs/Directory.Build.props | 2 +- src/OpenTelemetry.Api/CHANGELOG.md | 2 ++ 4 files changed, 11 insertions(+), 10 deletions(-) diff --git a/NuGet.config b/NuGet.config index 575482bb36e..bb984e4c44f 100644 --- a/NuGet.config +++ b/NuGet.config @@ -3,7 +3,6 @@ - diff --git a/build/Common.props b/build/Common.props index 6be31e03db1..b719ee866a5 100644 --- a/build/Common.props +++ b/build/Common.props @@ -25,12 +25,12 @@ [3.6.1,4.0) [2.23.0,3.0) [2.25.0,3.0) - [2.1.1,5.0) - [2.1.1,5.0) + [2.1.1,6.0) + [2.1.1,6.0) [1.0.7,2.0) [3.3.1] [16.9.0-preview-20201020-06] - [2.1.0,5.0) + [2.1.0,6.0) [2.1.0,6.0) [2.1.0,6.0) [1.0.0,2.0) @@ -39,11 +39,11 @@ [0.12.1,0.13) [2.1.58,3.0) [1.1.118,2.0) - [1.4.0,5.0] - [5.0.0-rc.2.20475.5] - [4.7.0,5.0) - [4.7.0,5.0) - [4.5.3,5.0) + [1.4.0,6.0) + [5.0.0,6.0) + [4.7.0,6.0) + [4.7.0,6.0) + [4.5.3,6.0) diff --git a/docs/Directory.Build.props b/docs/Directory.Build.props index 16d159113e6..3b7db6739a2 100644 --- a/docs/Directory.Build.props +++ b/docs/Directory.Build.props @@ -14,7 +14,7 @@ Please sort alphabetically. Refer to https://docs.microsoft.com/en-us/nuget/concepts/package-versioning for semver syntax. --> - [5.0.0-rc.2.20475.5,6.0) + [5.0.0,6.0) [0.4.0-beta.2,1.0) [0.4.0-beta.2,1.0) diff --git a/src/OpenTelemetry.Api/CHANGELOG.md b/src/OpenTelemetry.Api/CHANGELOG.md index 30c27c010e9..ae233a6b7d3 100644 --- a/src/OpenTelemetry.Api/CHANGELOG.md +++ b/src/OpenTelemetry.Api/CHANGELOG.md @@ -2,6 +2,8 @@ ## Unreleased +* Updated System.Diagnostics.DiagnosticSource to version 5.0.0 + ## 0.8.0-beta.1 Released 2020-Nov-5 From fa1e17f4cea748de6b6f83c56f3464293bc1e53f Mon Sep 17 00:00:00 2001 From: Cijo Thomas Date: Tue, 10 Nov 2020 11:50:50 -0800 Subject: [PATCH 2/4] OpenTelemetry Instrumentation API doc improvements (#1499) * OpenTelemetry Instrumentation API doc improvements * fix links * metric warning * propagator fix * comparison link * fix markdown * fix link * edits from review --- .../TestOTelShimWithConsoleExporter.cs | 25 +-- src/OpenTelemetry.Api/README.md | 144 +++++++++++++----- 2 files changed, 123 insertions(+), 46 deletions(-) diff --git a/examples/Console/TestOTelShimWithConsoleExporter.cs b/examples/Console/TestOTelShimWithConsoleExporter.cs index 75c35145d7f..de4fbc772a9 100644 --- a/examples/Console/TestOTelShimWithConsoleExporter.cs +++ b/examples/Console/TestOTelShimWithConsoleExporter.cs @@ -36,18 +36,19 @@ internal static object Run(OpenTelemetryShimOptions options) // which decide to use OpenTelemetry. var tracer = TracerProvider.Default.GetTracer("MyCompany.MyProduct.MyWebServer"); - var span = tracer.StartSpan("parent span"); - span.SetAttribute("mystring", "value"); - span.SetAttribute("myint", 100); - span.SetAttribute("mydouble", 101.089); - span.SetAttribute("mybool", true); - span.UpdateName("parent span new name"); - - var spanChild = tracer.StartSpan("child span"); - spanChild.AddEvent("sample event").SetAttribute("ch", "value").SetAttribute("more", "attributes"); - spanChild.End(); - - span.End(); + using (var parentSpan = tracer.StartActiveSpan("parent span")) + { + parentSpan.SetAttribute("mystring", "value"); + parentSpan.SetAttribute("myint", 100); + parentSpan.SetAttribute("mydouble", 101.089); + parentSpan.SetAttribute("mybool", true); + parentSpan.UpdateName("parent span new name"); + + var childSpan = tracer.StartSpan("child span"); + childSpan.AddEvent("sample event").SetAttribute("ch", "value").SetAttribute("more", "attributes"); + childSpan.SetStatus(Status.Ok); + childSpan.End(); + } System.Console.WriteLine("Press Enter key to exit."); diff --git a/src/OpenTelemetry.Api/README.md b/src/OpenTelemetry.Api/README.md index f5d152d8330..64419db1b65 100644 --- a/src/OpenTelemetry.Api/README.md +++ b/src/OpenTelemetry.Api/README.md @@ -16,7 +16,7 @@ * [Adding Events](#adding-events) * [Setting Status](#setting-status) * [Instrumenting a library/application with OpenTelemetry.API - Shim](#instrumenting-a-libraryapplication-with-opentelemetryapi-shim) + Shim](#instrumenting-using-opentelemetryapi-shim) * [References](#references) ## Installation @@ -33,6 +33,8 @@ instrument an application/library. It does not address concerns like how telemetry is exported to a specific telemetry backend, how to sample the telemetry, etc. The API consists of [Tracing API](https://github.com/open-telemetry/opentelemetry-specification/blob/master/specification/trace/api.md), +[Logging +API](https://github.com/open-telemetry/opentelemetry-specification/blob/master/specification/logs/overview.md), [Metrics API](https://github.com/open-telemetry/opentelemetry-specification/blob/master/specification/metrics/api.md), [Context and Propagation @@ -46,9 +48,17 @@ conventions](https://github.com/open-telemetry/opentelemetry-specification/tree/ API](https://github.com/open-telemetry/opentelemetry-specification/blob/master/specification/trace/api.md) allows users to generate [Spans](https://github.com/open-telemetry/opentelemetry-specification/blob/master/specification/trace/api.md#span), -which represent a single operation within a trace. Spans can be nested to form -a trace tree. Each trace contains a root span, which typically describes the -entire operation and, optionally one or more sub-spans for its sub-operations. +which represent a single operation within a trace. Spans can be nested to form a +trace tree. Each trace contains a root span, which typically describes the +entire operation and, optionally one or more child-spans for its +child-operations. + +### Logging API + +OpenTelemetry does not introduce its own API for logging. Instead it recommends +to integrate with existing well-known logging libraries for each language. For +.NET, the logging API is simply the [Microsoft.Extensions.Logging +API](https://docs.microsoft.com/dotnet/core/extensions/logging). ### Metrics API @@ -58,6 +68,10 @@ allows users to capture measurements about the execution of a computer program at runtime. The Metrics API is designed to process raw measurements, generally with the intent to produce continuous summaries of those measurements. +_**Warning:** OpenTelemetry .NET has a prototype Metrics API implementation only +and is not recommended for any production use. The API is expected to change +heavily._ + ## Introduction to OpenTelemetry .NET Tracing API .NET runtime had `Activity` class for a long time, which was meant to be used @@ -65,8 +79,8 @@ for tracing purposes and represents the equivalent of the OpenTelemetry [Span](https://github.com/open-telemetry/opentelemetry-specification/blob/master/specification/trace/api.md#span). OpenTelemetry .NET is reusing the existing `Activity` and associated classes to represent the OpenTelemetry `Span`. This means, users can instrument their -applications/libraries to emit OpenTelemetry compatible traces by using just -the .NET Runtime. +applications/libraries to emit OpenTelemetry compatible traces by using just the +.NET Runtime. The `Activity` and associated classes are shipped as part of `System.Diagnostics.DiagnosticSource` nuget package. Version 5.0.0 of this @@ -77,32 +91,57 @@ specification](https://github.com/open-telemetry/opentelemetry-specification/blo Even though `Activity` enables all the scenarios OpenTelemetry supports, users who are already familiar with OpenTelemetry terminology may find it easy to operate with that terminology. For instance, `StartSpan` may be preferred over -`StartActivity`. To help with this transition, the OpenTelemetry.API package -has [shim](#instrumenting-a-libraryapplication-with-opentelemetryapi-shim) -classes to wrap around the .NET `Activity` classes. +`StartActivity`. To help with this transition, the OpenTelemetry.API package has +[shim](#instrumenting-using-opentelemetryapi-shim) classes +to wrap around the .NET `Activity` classes. The shim exist only in the API. OpenTelemetry SDK for .NET will be operating entirely with `Activity` only. Irrespective of whether shim classes or `Activity` is used for instrumentation, the end result would be same. i.e Processors/Exporters see the same data. +The recommended way of instrumenting is by using the [.NET Activity +API](#instrumenting-a-libraryapplication-with-net-activity-api). Users are +required to just take dependency on the +[DiagnosticSource](https://www.nuget.org/packages/System.Diagnostics.DiagnosticSource/5.0.0). +Adding dependency to +[OpenTelemetry.API](https://www.nuget.org/packages/opentelemetry.api) is +required only for the following scenarios: + +1. You want to use terminology matching OpenTelemetry spec (Span vs Activity). + The [shim](#instrumenting-using-opentelemetryapi-shim) can be useful for such + users. Refer to the [comparison of Activity API and OpenTelemetry Tracing + API](https://github.com/open-telemetry/opentelemetry-dotnet/issues/947) if + you want to compare the differences. +2. Your library performs communication with other libraries/components, and want + to access + [Propagators](https://github.com/open-telemetry/opentelemetry-specification/blob/master/specification/context/api-propagators.md), + to inject and extract context data. Some of the most common libraries + requiring this include + [HttpClient](../OpenTelemetry.Instrumentation.Http/README.md), + [ASP.NET](../OpenTelemetry.Instrumentation.AspNet/README.md), [ASP.NET + Core](../OpenTelemetry.Instrumentation.AspNetCore/README.md). This repo + already provides instrumentation for these common libraries. If your library + is not built on top of these, and want to leverage propagators, follow the + [Context propagation](#context-propagation) section. + ## Instrumenting a library/application with .NET Activity API ### Basic usage -As mentioned in the introduction, the instrumentation API for OpenTelemetry -.NET is the .NET `Activity` API. Guidance for instrumenting using this API is +As mentioned in the introduction, the instrumentation API for OpenTelemetry .NET +is the .NET `Activity` API. Guidance for instrumenting using this API is documented fully in the TBD(dotnet activity user guide link), but is described here as well. 1. Install the `System.Diagnostics.DiagnosticSource` package version - `5.0.0-rc.2.20475.5` or above to your application or library. + `5.0.0` or above to your application or library. ```xml ``` @@ -128,17 +167,23 @@ here as well. ``` If there are no listeners interested in this activity, the activity above - will be null. Ensure that all subsequent calls using this activity is - protected with a null check. + will be null. This happens when the final application does not enable + OpenTelemetry (or other `ActivityListener`s), or when OpenTelemetry samplers + chose not to sample this activity. Ensure that all subsequent calls using + this activity are protected with a null check. 4. Populate activity with tags following the [OpenTelemetry semantic conventions](https://github.com/open-telemetry/opentelemetry-specification/tree/master/specification/trace/semantic_conventions). It is highly recommended to check `activity.IsAllDataRequested`, before - populating any tags which are not readily available. + populating any tags which are not readily available. `IsAllDataRequested` is + the same as + [Span.IsRecording](https://github.com/open-telemetry/opentelemetry-specification/blob/master/specification/trace/api.md#isrecording) + and will be false when samplers decide to not record the activity, and this + can be used to avoid any expensive operation to retrieve tags. ```csharp activity?.SetTag("http.method", "GET"); - if (activity?.IsAllDataRequested ?? false) + if (activity != null && activity.IsAllDataRequested == true) { activity.SetTag("http.url", "http://www.mywebsite.com"); } @@ -168,12 +213,12 @@ following sections describes more features. ### Activity creation options -Basic usage example above showed how `StartActivity` method can be used to -start an `Activity`. The started activity will automatically becomes the -`Current` activity. It is important to note that the `StartActivity` returns -`null`, if no listeners are interested in the activity to be created. This -happens when the final application does not enable OpenTelemetry, or when -OpenTelemetry samplers chose not to sample this activity. +Basic usage example above showed how `StartActivity` method can be used to start +an `Activity`. The started activity will automatically becomes the `Current` +activity. It is important to note that the `StartActivity` returns `null`, if no +listeners are interested in the activity to be created. This happens when the +final application does not enable OpenTelemetry, or when OpenTelemetry samplers +chose not to sample this activity. `StartActivity` has many overloads to control the activity creation. @@ -230,7 +275,10 @@ OpenTelemetry samplers chose not to sample this activity. Refer to the [specification](https://github.com/open-telemetry/opentelemetry-specification/blob/master/specification/common/common.md#attribute-and-label-naming) for best practices on naming tags. It is also possible to provide an initial - set of tags during activity creation, as shown below. + set of tags during activity creation, as shown below. Tags provided at + activity creation are accessible for + [Samplers](https://github.com/open-telemetry/opentelemetry-specification/blob/master/specification/trace/sdk.md#sampler), + whereas any tags added using `SetTag` are not available for samplers. ```csharp var initialTags = new ActivityTagsCollection(); @@ -286,8 +334,8 @@ OpenTelemetry samplers chose not to sample this activity. ### Adding Events It is possible to [add -event](https://github.com/open-telemetry/opentelemetry-specification/blob/master/specification/trace/api.md#add-events) -with `Activity` using the `AddEvent` method as shown below. +events](https://github.com/open-telemetry/opentelemetry-specification/blob/master/specification/trace/api.md#add-events) +to `Activity` using the `AddEvent` method as shown below. ```csharp activity?.AddEvent(new ActivityEvent("sample activity event.")); @@ -303,21 +351,49 @@ OpenTelemetry defines a concept called to be associated with `Activity`. There is no `Status` class in .NET, and hence `Status` is set to an `Activity` using the following special tags -`otel.status_code` is the `Tag` name used to store the [Status Canonical -Code](https://github.com/open-telemetry/opentelemetry-specification/blob/master/specification/trace/api.md#statuscanonicalcode). +`otel.status_code` is the `Tag` name used to store the `StatusCode`, and `otel.status_description` is the `Tag` name used to store the optional -[Description](https://github.com/open-telemetry/opentelemetry-specification/blob/master/specification/trace/api.md#getdescription) +`Description`. Example: ```csharp -activity?.SetTag("otel.status_code", "status canonical code"); -activity?.SetTag("otel.status_description", "status description"); +activity?.SetTag("otel.status_code", 2); +activity?.SetTag("otel.status_description", "error status description"); ``` -## Instrumenting a library/application with OpenTelemetry.API Shim - -This section to be filled after shim is shipped. +StatusCodes can be 0, 1, 2 which corresponds to `Unset`, `Ok` and `Error` +respectively from [StatusCode.cs](./Trace/StatusCode.cs) + +If using OpenTelemetry API +[shim](#instrumenting-using-opentelemetryapi-shim), then you +can leverage the `SetStatus` extension method on `Activity` as well. + +## Instrumenting using OpenTelemetry.API Shim + +As mentioned in the introduction section, using OpenTelemetry.API Shim is only +recommended if you want to use OpenTelemetry terminology like Tracer, Span +instead of ActivitySource, Activity. + +Follow [this](../../examples/console/TestOTelShimWithConsoleExporter.cs) code for +example usage of this shim. + +## Context propagation + +[OpenTelemetry.API](https://www.nuget.org/packages/opentelemetry.api) must be +used to access [Propagators +API](https://github.com/open-telemetry/opentelemetry-specification/blob/master/specification/context/api-propagators.md) +which defines how to extract and inject context across process boundaries. This +is typically required if you are not using any of the .NET communication +libraries which has instrumentations already available which does the +propagation (eg: Asp.Net Core or HttpClient). In such cases, context extraction +and propagation is the responsibility of the library itself. An example would be +a producer-consumer pattern using some queuing library like RabbitMQ. Follow the +[messaging example](../../examples/MicroserviceExample/README.md) for examples on +how to +[inject](../../examples/MicroserviceExample/Utils/Messaging/MessageSender.cs) and +[extract](../../examples/MicroserviceExample/Utils/Messaging/MessageReceiver.cs) +context. ## References From baa2972e49ffd84e07db8b233f5b059dc6ae7cae Mon Sep 17 00:00:00 2001 From: Cijo Thomas Date: Tue, 10 Nov 2020 17:59:18 -0800 Subject: [PATCH 3/4] Instrumentation Library doc (#1467) * Draft of instrumentation doc * more details * markdowns * minor * link * fix link * doc fix * minor * link --- docs/trace/extending-the-sdk/README.md | 105 ++++++++++++++++++++++++- 1 file changed, 104 insertions(+), 1 deletion(-) diff --git a/docs/trace/extending-the-sdk/README.md b/docs/trace/extending-the-sdk/README.md index fd1ee95bf5d..e213ed0199e 100644 --- a/docs/trace/extending-the-sdk/README.md +++ b/docs/trace/extending-the-sdk/README.md @@ -60,7 +60,110 @@ Exporter to the `TracerProvider` as shown in the example [here](./Program.cs). ## Instrumentation Library -TBD +The [inspiration of the OpenTelemetry +project](https://github.com/open-telemetry/opentelemetry-specification/blob/master/specification/overview.md#instrumentation-libraries) +is to make every library and application observable out of the box by having +them call OpenTelemetry API directly. However, many libraries will not have such +integration, and as such there is a need for a separate library which would +inject such calls, using mechanisms such as wrapping interfaces, subscribing to +library-specific callbacks, or translating existing telemetry into OpenTelemetry +model. + +A library which enables instrumentation for another library is called +[Instrumentation +Library](https://github.com/open-telemetry/opentelemetry-specification/blob/master/specification/glossary.md#instrumentation-library) +and the library it instruments is called the [Instrumented +Library](https://github.com/open-telemetry/opentelemetry-specification/blob/master/specification/glossary.md#instrumented-library). +If a given library has built-in instrumentation with OpenTelemetry, then +instrumented library and instrumentation library will be the same. + +The [OpenTelemetry .NET Github repo](../../../README.md#getting-started) ships +the following instrumentation libraries. The individual docs for them describes +the library they instrument, and steps for enabling them. + +* [ASP.NET](../../../src/OpenTelemetry.Instrumentation.AspNet/README.md) +* [ASP.NET Core](../../../src/OpenTelemetry.Instrumentation.AspNetCore/README.md) +* [gRPC client](../../../src/OpenTelemetry.Instrumentation.GrpcNetClient/README.md) +* [HTTP clients](../../../src/OpenTelemetry.Instrumentation.Http/README.md) +* [Redis + client](../../../src/OpenTelemetry.Instrumentation.StackExchangeRedis/README.md) +* [SQL client](../../../src/OpenTelemetry.Instrumentation.SqlClient/README.md) + +### Writing own instrumentation library + +This section describes the steps required to write your own instrumentation +library. + +*If you are writing a new library or modifying an existing library, the +recommendation is to use [ActivitySource API/OpenTelemetry +API](../../../src/OpenTelemetry.Api/README.md#introduction-to-opentelemetry-net-tracing-api) +to instrument it and emit activity/span. If the instrumented library is +instrumented using ActivitySource API, then there is no need of writing a +separate instrumentation library, as instrumented and instrumentation library +become same in this case. For applications to collect traces from this library, +all that is needed is to enable the ActivitySource for the library using +`AddSource` method of the `TracerProviderBuilder`. The following section is +applicable only if you are writing an instrumentation library for an +instrumented library which you cannot modify to emit activities directly* + +As mentioned earlier, the instrumentation library must use ActivitySource API to +emit activities. The mechanics of how the instrumentation library works depends +on each library. For example, StackExchangeRedis library allows hooks into the +library, and the [StackExchangeRedis instrumentation +library]../../../src/OpenTelemetry.Instrumentation.StackExchangeRedis/README.md) +in this case, leverages them, and emits Span/Activity, on behalf of the +instrumented library. Another example is System.Data.SqlClient for .NET +Framework, which publishes events using `EventSource`. The [SqlClient +instrumentation +library](../../../src/OpenTelemetry.Instrumentation.SqlClient/Implementation/SqlEventSourceListener.netfx.cs), +in this case subscribes to the `EventSource` callbacks and in turn produces +Activity. + +Irrespective of the mechanics used for achieving instrumentation, the +instrumentation library must use [ActivitySource API/OpenTelemetry +API](../../../src/OpenTelemetry.Api/README.md#introduction-to-opentelemetry-net-tracing-api) +to emit Activities on behalf of the instrumented library. + +### Instrumentation library optional requirements + +The instrumentation library may provide extension methods on +`TracerProviderBuilder`, to enable the instrumentation. Providing this extension +method is optional, and the below guidance must be followed: + +1. If the instrumentation library requires state management tied to that of + `TracerProvider`, then it must register itself with the provider with the + `AddInstrumentation` method on the `TracerProviderBuilder`. This causes the + instrumentation to be created and disposed along with `TracerProvider`. If + the above is required, then it must also provide an extension method on + `TracerProviderBuilder`. Inside this extension method, it can do the + `AddInstrumentation` method, and `AddSource` to enable its ActivitySource for + the provider. An example instrumentation using this approach is + [StackExchangeRedis + instrumentation](../../../src/OpenTelemetry.Instrumentation.StackExchangeRedis/TracerProviderBuilderExtensions.cs) + +2. If the instrumentation library does not requires any state management tied to + that of `TracerProvider`, then providing `TracerProviderBuilder` extension + method is optional. If provided, then it must call `AddSource` to enable its + ActivitySource for the provider. +3. If instrumentation library does not require state management, and is not + providing extension method, then the name of the ActivitySource used by the + instrumented library must be documented so that end users can enable it using + `AddSource` API. + +There is a special case for libraries which are already instrumented with +[Activity](https://github.com/dotnet/runtime/blob/master/src/libraries/System.Diagnostics.DiagnosticSource/src/ActivityUserGuide.md), +but using the +[DiagnosticSource](https://github.com/dotnet/runtime/blob/master/src/libraries/System.Diagnostics.DiagnosticSource/src/DiagnosticSourceUsersGuide.md) +method. These libraries already emit activities, but it may not conform to the +OpenTelemetry semantic conventions. Also, as these libraries do not use +ActivitySource to create Activity, they cannot be simply enabled. For this case, +the recommended approach is to write instrumentation library which subscribe to +the DiagnosticSource events from the instrumented library, and in turn produce +*new* activity using ActivitySource. This new activity must be created as a +sibling of the activity already produced by the library. i.e the new activity +must have the same parent as the original activity. Some common examples of such +libraries include Asp.Net, Asp.Net Core, HttpClient (.NET Core). Instrumentation +libraries for these are already provided in this repo. ## Processor From 18cb0a3e98978f6d980d861ea0047d352cb0142e Mon Sep 17 00:00:00 2001 From: Cijo Thomas Date: Tue, 10 Nov 2020 22:08:57 -0800 Subject: [PATCH 4/4] Modify GHActions to use new .net5 (#1503) --- .github/workflows/dotnet-core-cov.yml | 6 +++--- .github/workflows/dotnet-core-linux.yml | 2 +- .github/workflows/dotnet-core-win.yml | 6 +++--- .github/workflows/dotnet-core.yml | 6 +++--- 4 files changed, 10 insertions(+), 10 deletions(-) diff --git a/.github/workflows/dotnet-core-cov.yml b/.github/workflows/dotnet-core-cov.yml index 8411111da63..5c89738792c 100644 --- a/.github/workflows/dotnet-core-cov.yml +++ b/.github/workflows/dotnet-core-cov.yml @@ -27,17 +27,17 @@ jobs: - name: Setup .NET Core 2.1 uses: actions/setup-dotnet@v1 with: - dotnet-version: 2.1.807 + dotnet-version: 2.1.x - name: Setup .NET Core 3.1 uses: actions/setup-dotnet@v1 with: - dotnet-version: 3.1.301 + dotnet-version: 3.1.x - name: Setup .NET 5 uses: actions/setup-dotnet@v1 with: - dotnet-version: '5.0.100-rc.2.20479.15' + dotnet-version: '5.0.x' - name: Install dependencies run: dotnet restore diff --git a/.github/workflows/dotnet-core-linux.yml b/.github/workflows/dotnet-core-linux.yml index ba128f31aeb..a2eb6400266 100644 --- a/.github/workflows/dotnet-core-linux.yml +++ b/.github/workflows/dotnet-core-linux.yml @@ -30,7 +30,7 @@ jobs: - name: Setup .NET 5 uses: actions/setup-dotnet@v1 with: - dotnet-version: '5.0.100-rc.2.20479.15' + dotnet-version: '5.0.x' - name: Install dependencies run: dotnet restore diff --git a/.github/workflows/dotnet-core-win.yml b/.github/workflows/dotnet-core-win.yml index ab60a49e303..205bff698a1 100644 --- a/.github/workflows/dotnet-core-win.yml +++ b/.github/workflows/dotnet-core-win.yml @@ -20,17 +20,17 @@ jobs: - name: Setup .NET Core 2.1 uses: actions/setup-dotnet@v1 with: - dotnet-version: 2.1.807 + dotnet-version: 2.1.x - name: Setup .NET Core 3.1 uses: actions/setup-dotnet@v1 with: - dotnet-version: 3.1.301 + dotnet-version: 3.1.x - name: Setup .NET 5 uses: actions/setup-dotnet@v1 with: - dotnet-version: '5.0.100-rc.2.20479.15' + dotnet-version: '5.0.x' - name: Install dependencies run: dotnet restore diff --git a/.github/workflows/dotnet-core.yml b/.github/workflows/dotnet-core.yml index acad4bcf1ff..2216d4ae4fb 100644 --- a/.github/workflows/dotnet-core.yml +++ b/.github/workflows/dotnet-core.yml @@ -26,17 +26,17 @@ jobs: - name: Setup .NET Core 2.1 uses: actions/setup-dotnet@v1 with: - dotnet-version: 2.1.807 + dotnet-version: 2.1.x - name: Setup .NET Core 3.1 uses: actions/setup-dotnet@v1 with: - dotnet-version: 3.1.301 + dotnet-version: 3.1.x - name: Setup .NET 5 uses: actions/setup-dotnet@v1 with: - dotnet-version: '5.0.100-rc.2.20479.15' + dotnet-version: '5.0.x' - name: Install dependencies run: dotnet restore