Posted on Leave a comment

ASP.NET Core updates in .NET Core 3.1



.NET Core 3.1 is now available and is ready for production use! .NET Core 3.1 is a Long Term Support (LTS) release.

Here’s what’s new in this release for ASP.NET Core:

  • Partial class support for Razor components
  • Pass parameters to top-level components
  • New component tag helper
  • Prevent default actions for events in Blazor apps
  • Stop event propagation in Blazor apps
  • Detailed errors during Blazor app development
  • Support for shared queues in HttpSysServer
  • Breaking changes for SameSite cookies

You can find all the details about these new features in the What’s new in ASP.NET Core 3.1 topic.

See the release notes for additional details and known issues.

Get started

To get started with ASP.NET Core in .NET Core 3.1 install the .NET Core 3.1 SDK.

If you’re on Windows using Visual Studio, install Visual Studio 2019 16.4. Installing Visual Studio 2019 16.4 will also install .NET Core 3.1, so you don’t need to separately install it.

Upgrade an existing project

To upgrade an existing ASP.NET Core app to .NET Core 3.0, follow the migrations steps in the ASP.NET Core docs.

See the full list of breaking changes in ASP.NET Core 3.1.

To upgrade an existing ASP.NET Core 3.0 RC1 project to 3.0:

  • Update all Microsoft.AspNetCore.* and Microsoft.Extensions.* package references to 3.1.0

That’s it! You should now be all set to use .NET Core 3.1!

Blazor WebAssembly update

Alongside this .NET Core 3.1 release, we’ve also released a Blazor WebAssembly update. Blazor WebAssembly is still in preview and is not part of the .NET Core 3.1 release. Blazor WebAssembly will ship as a stable release at a future date.

To install the latest Blazor WebAssembly template run the following command:

dotnet new -i Microsoft.AspNetCore.Blazor.Templates::3.1.0-preview4.19579.2

This release of Blazor WebAssembly includes a number of new features and improvements:

  • .NET Standard 2.1 support
  • Support for static assets in when publishing
  • iOS 13 support
  • Better linker errors
  • Attach to process debugging from Visual Studio

.NET Standard 2.1 support

Blazor WebAssembly apps now target .NET Standard 2.1 by default. Using .NET Standard 2.1 libraries from a Blazor WebAssembly app is now supported within the limits of the browser security sandbox.

Support for static assets in libraries when publishing

Standalone Blazor WebAssembly apps now support static assets from Razor class libraries both during development and when publishing. This applies to both standalone Blazor WebAssembly apps and ASP.NET Core hosted apps. Static assets are consumed from referenced libraries using the path prefix: _content/{LIBRARY NAME}/.

iOS 13 support

Blazor WebAssembly apps now work from iOS 13 based devices. The .NET IL interpreter now uses a non-recursive implementation to prevent exceeding the size of the stack on these devices.

Better linker errors

The IL linker is now integrated with Blazor WebAssembly projects such that linker errors are surfaced as build errors.

Attach to process debugging from Visual Studio

You can now debug Blazor WebAssembly apps from Visual Studio by attaching to the browser process. Currently this experience is very manual. In a future update, we expect to enable Visual Studio to handle all of the necessary wire-up to debug a Blazor WebAssembly app when you hit F5. Also, various features of the debugging experience (like viewing locals) are not yet enabled. This is something we will be working on over the next few months.

To debug a running Blazor WebAssembly app from Visual Studio:

  1. Run the app without debugging (Ctrl-F5 instead of F5)
  2. Open the Debug properties of the app and copy the HTTP app URL
  3. Browse to the HTTP address (not the HTTPS address) of the app using a Chromium based browser (Edge Beta or Chrome).
  4. With the browser in focus, press Shift-Alt-D and then follow the instructions to open a browser with remote debugging enabled
  5. Close all other browser instances
  6. In Visual Studio, select Debug > Attach to Process.
  7. For the Connection type, select Chrome devtools protocol websocket (no authentication).
  8. For the Connection target, paste in the HTTP address (not the HTTPS address) of the app and press Enter (don’t click “Find” – that does something else).
  9. Select the browser process you want to debug and select Attach
  10. In the Select Code Type dialog, select the code type for the specific browser you are attaching to (Edge or Chrome) and then select OK
  11. Set a break point in your app (for example, in the IncrementCount method in the Counter component) and then use that part of the app to hit the breakpoint.

In a later release, this process will become automated inside Visual Studio and Visual Studio Code so you can launch and attach the debugger with a single click or keystroke. Then you will no longer need to go through this detailed attachment process manually.

Give feedback

We hope you enjoy this release of ASP.NET Core in .NET Core 3.1! We are eager to hear about your experiences with this latest .NET Core release. Let us know what you think by filing issues on GitHub.

Thanks for trying out ASP.NET Core!


Posted on Leave a comment

Why choose the Godot Game Engine over Unity or Unreal Engine


This is a very common question, so this guide and video is setting out to answer why *I* might choose to use Godot over those other engines. Keep in mind, this isn’t me saying Godot is better or worse than those engines. Additionally, I have a video on Unreal vs Unity in the works, so if you want to decide which of those engines to use, stay tuned for that.

Without further ado, let’s jump in.


Obviously, the lack of a price tag is one of the most obvious features of Godot. Yes, you can start for free with both Unity and Unreal Engine, but both ultimately have a price tag. With Unity, you pay a per seat license fee if you make over 100K a year. With Unreal Engine you pay a fixed 5% royalty after the first $3000 dollars earned. If you’re not making money nor plan to, this obviously doesn’t matter… but the more successful your game is, the better a deal free is!

Open Source

On the topic of free, we also have free as in freedom. Godot is free in both regards, to price tag and license, being licensed under the MIT license. Unity trails in this regard having only select subsets of the code available. Unreal Engine has the source code available and you can completely build the engine from scratch, as well as being able to fix problems yourself by walking through a debug build and applying fixes.

UE4 however is under a more restrictive proprietary license, while Godot is under the incredibly flexible and permissive code license.

Another aspect in Godot’s favor… it’s also by far the smallest code base and very modular in design from a code perspective. This makes it among the easiest engines to contribute code to. The learning curve to understand the source code is a fraction of that to get started contributing to Unreal, while contributing to Unity is frankly impossible without a very expensive negotiated source license.

Language Flexibility

Over the years Unity have *REMOVED* language support. Once there was UnityScript and Boo, a python like language, in addition to C#. Now it’s pretty much just C# and their in development visual scripting language.

Unreal on the other hand has C++ support, with the C++ thanks to Live++ usable very much like a scripting language (although final build times are by far the worst of all 3 engines!), as well as the (IMHO) single best visual programming language available, Blueprints.

For Godot the options are much more robust. First off there is the Python-lite scripting language, GDScript. You can also use C++, although the workflow for gameplay programming may be suboptimal. Additionally, C# support is being added as a first-class language and there is a visual programming language available here as well, although I can’t really think of a reason to use it as it stands now.

Where Godot really shines though is its modularity. GDScript itself is implemented as a module, meaning making other custom scripting languages is a borderline trivial task, as is extending or customizing GDScript. Additionally, there is GDNative/NativeScript it makes it fairly simple to link to external code, without having to jump into the guts of Godot (nor having to compile Godot) or to write performance critical code in C or C++. Finally, you have the ability to create C++ “modules” that have access to all of the C++ classes available in Godot without having to make changes to the underlying codebase.

Ease of Use

This one is obviously subjective, but if you are looking to create a game, especially as a beginner, the learning curve and ease of use with GDScript make this the easiest of the 3 engines to pick up, at least in my opinion. Unreal Engine is frankly fairly appalling for 2D titles, having basically abandoned Paper2D (their 2D API) on the vine. Over the last couple years Unity have really been focusing heavier on dedicated 2D support, but you still must dig through a lot of cruft and overhead to get to the meat of your game.

With Godot you pretty much everything you need for 2D out of the box and the ability to work directly with pixel (or % based) coordinates.

It’s Tiny

Unreal and Unity are multi GB installs and both have a hub or launcher app. Godot… a 50ish MB zip file (plus templates for a couple hundred more MB needed when deploying). Download, unzip and start game development!

You Like it Better?

You may, or you may not like the coding model of Godot. Chances are if you like the Node based approach to game development, you will love Godot. All three game engines (and almost all modern game engines) take a composition-based approach to scene modeling. Godot takes it one step further, making everything nodes, trees of nodes, even scenes are simply nodes. The approach is different enough that users may either love or hate the approach. If you love the approach Godot takes, you will be productive in it. If you don’t like it, you’re probably better served using Unity or Unreal.

Why Not Pick Godot Then?

I am not even going to pretend that Godot is the perfect game engine and ideal in every situation… there are certainly areas where Unity and Unreal have a small to huge advantage. This could be its own entire video, but a quick list include:

  • Performance concerns, especially on large 3D scenes (hopefully resolved with proper culling and the upcoming Vulkan renderer). In 3D, both engines out perform Godot quite often
  • Platforms… Unity and Unreal support every single platform you can imagine, Godot supports most of the common consumer categories and takes longer to get support for devices like AR/VR. Hardware manufacturers work with Unity and Epic from the design stages, while Godot pretty much must wait for hardware to come to market and then for someone to implement it. Another huge difference, and one of the few downsides to open source software, it isn’t compatible with the closed proprietary licenses of console hardware. While Godot has been ported to run on console hardware, it isn’t supported out of the box and probably never will be.
  • Ecosystem. Godot has a vibrant community but can’t hold a candle to the ecosystem around Unreal and especially Unity. There are simply more users, more books, larger asset stores, etc.
  • The resume factor… this is a part of ecosystem continued. It’s easier to get a job with Unity experience or Unreal experience on the resume than Godot. While many people wouldn’t (and really for a full-time hire, shouldn’t) care what engine you use, when people are hunting for employees, they often look for Unity or UE experience specifically. The other side of this coin is the number of people with Unity or UE experience is larger if you are the one doing the hiring.
  • As with many open source projects, it’s still heavily dependent on one or two key developers. If the leads left the project, it would be a massive blow to the future of Godot. Meanwhile there are hundred or thousands of people being paid to develop Unity or Unreal and the departure of any individual member isn’t likely to have a tangible impact.

The Longer Video Version

Programming General



Posted on Leave a comment




ASP.NET Core now enables developers to build gRPC services. gRPC is an opinionated contract-first remote procedure call framework, with a focus on performance and developer productivity. gRPC integrates with ASP.NET Core 3.0, so you can use your existing ASP.NET Core logging, configuration, authentication patterns to build new gRPC services.

This blog post compares gRPC to JSON HTTP APIs, discusses gRPC’s strengths and weaknesses, and when you could use gRPC to build your apps.

gRPC strengths

Developer productivity

With gRPC services, a client application can directly call methods on a server app on a different machine as if it was a local object. gRPC is based around the idea of defining a service, specifying the methods that can be called remotely with their parameters and return types. The server implements this interface and runs a gRPC server to handle client calls. On the client, a strongly-typed gRPC client is available that provides the same methods as the server.

gRPC is able to achieve this through first-class support for code generation. A core file to gRPC development is the .proto file, which defines the contract of gRPC services and messages using Protobuf interface definition language (IDL):


// The greeting service definition.
service Greeter { // Sends a greeting rpc SayHello (HelloRequest) returns (HelloReply);
} // The request message containing the user's name.
message HelloRequest { string name = 1;
} // The response message containing the greetings
message HelloReply { string message = 1;

Protobuf IDL is a language neutral syntax, so it can be shared between gRPC services and clients implemented in different languages. gRPC frameworks use the .proto file to code generate a service base class, messages, and a complete client. Using the generated strongly-typed Greeter client to call the service:


var channel = GrpcChannel.ForAddress("https://localhost:5001")
var client = new Greeter.GreeterClient(channel); var reply = await client.SayHelloAsync(new HelloRequest { Name = "World" });
Console.WriteLine("Greeting: " + reply.Message);

By sharing the .proto file between the server and client, messages and client code can be generated from end to end. Code generation of the client eliminates duplication of messages on the client and server, and creates a strongly-typed client for you. Not having to write a client saves significant development time in applications with many services.


gRPC messages are serialized using Protobuf, an efficient binary message format. Protobuf serializes very quickly on the server and client. Protobuf serialization results in small message payloads, important in limited bandwidth scenarios like mobile apps.

gRPC requires HTTP/2, a major revision of HTTP that provides significant performance benefits over HTTP 1.x:

  • Binary framing and compression. HTTP/2 protocol is compact and efficient both in sending and receiving.
  • Multiplexing of multiple HTTP/2 calls over a single TCP connection. Multiplexing eliminates head-of-line blocking at the application layer.

Real-time services

HTTP/2 provides a foundation for long-lived, real-time communication streams. gRPC provides first-class support for streaming through HTTP/2.

A gRPC service supports all streaming combinations:

  • Unary (no streaming)
  • Server to client streaming
  • Client to server streaming
  • Bidirectional streaming

Note that the concept of broadcasting a message out to multiple connections doesn’t exist natively in gRPC. For example, in a chat room where new chat messages should be sent to all clients in the chat room, each gRPC call is required to individually stream new chat messages to the client. SignalR is a useful framework for this scenario. SignalR has the concept of persistent connections and built-in support for broadcasting messages.

Deadline/timeouts and cancellation

gRPC allows clients to specify how long they are willing to wait for an RPC to complete. The deadline is sent to the server, and the server can decide what action to take if it exceeds the deadline. For example, the server might cancel in-progress gRPC/HTTP/database requests on timeout.

Propagating the deadline and cancellation through child gRPC calls helps enforce resource usage limits.

gRPC weaknesses

Limited browser support

gRPC has excellent cross-platform support! gRPC implementations are available for every programming language in common usage today. However one place you can’t call a gRPC service from is a browser. gRPC heavily uses HTTP/2 features and no browser provides the level of control required over web requests to support a gRPC client. For example, browsers do not allow a caller to require that HTTP/2 be used, or provide access to underlying HTTP/2 frames.

gRPC-Web is an additional technology from the gRPC team that provides limited gRPC support in the browser. gRPC-Web consists of two parts: a JavaScript client that supports all modern browsers, and a gRPC-Web proxy on the server. The gRPC-Web client calls the proxy and the proxy will forward on the gRPC requests to the gRPC server.

Not all of gRPC’s features are supported by gRPC-Web. Client and bidirectional streaming isn’t supported, and there is limited support for server streaming.

Not human readable

HTTP API requests using JSON are sent as text and can be read and created by humans.

gRPC messages are encoded with Protobuf by default. While Protobuf is efficient to send and receive, its binary format isn’t human readable. Protobuf requires the message’s interface description specified in the .proto file to properly deserialize. Additional tooling is required to analyze Protobuf payloads on the wire and to compose requests by hand.

Features such as server reflection and the gRPC command line tool exist to assist with binary Protobuf messages. Also, Protobuf messages support conversion to and from JSON. The built-in JSON conversion provides an efficient way to convert Protobuf messages to and from human readable form when debugging.

gRPC recommended scenarios

gRPC is well suited to the following scenarios:

  • Microservices – gRPC is designed for low latency and high throughput communication. gRPC is great for lightweight microservices where efficiency is critical.
  • Point-to-point real-time communication – gRPC has excellent support for bidirectional streaming. gRPC services can push messages in real-time without polling.
  • Polyglot environments – gRPC tooling supports all popular development languages, making gRPC a good choice for multi-language environments.
  • Network constrained environments – gRPC messages are serialized with Protobuf, a lightweight message format. A gRPC message is always smaller than an equivalent JSON message.


gRPC is a powerful new tool for ASP.NET Core developers. While gRPC is not a complete replacement for HTTP APIs, it offers improved productivity and performance benefits in some scenarios.

gRPC on ASP.NET Core is available now! If you are interested in learning more about gRPC, check out these resources:


Posted on Leave a comment

ASP.NET Core updates in .NET Core 3.1 Preview 3



.NET Core 3.1 Preview 3 is now available. This release is primarily focused on bug fixes.

See the release notes for additional details and known issues.

Get started

To get started with ASP.NET Core in .NET Core 3.1 Preview 3 install the .NET Core 3.1 Preview 3 SDK.

If you’re on Windows using Visual Studio, for the best experience we recommend installing the latest preview of Visual Studio 2019 16.4. Installing Visual Studio 2019 16.4 will also install .NET Core 3.1 Preview 3, so you don’t need to separately install it. For Blazor development with .NET Core 3.1, Visual Studio 2019 16.4 is required.

Alongside this .NET Core 3.1 Preview 3 release, we’ve also released a Blazor WebAssembly update. To install the latest Blazor WebAssembly template also run the following command:

dotnet new -i Microsoft.AspNetCore.Blazor.Templates::3.1.0-preview3.19555.2

Upgrade an existing project

To upgrade an existing ASP.NET Core 3.1 Preview 2 project to 3.1 Preview 3:

  • Update all Microsoft.AspNetCore.* package references to 3.1.0-preview3.19555.2

See also the full list of breaking changes in ASP.NET Core 3.1.

That’s it! You should now be all set to use .NET Core 3.1 Preview 3!

Give feedback

We hope you enjoy the new features in this preview release of ASP.NET Core! Please let us know what you think by filing issues on GitHub.

Thanks for trying out ASP.NET Core!


Posted on Leave a comment

Improvements in .NET Core 3.0 for troubleshooting and monitoring distributed apps



Post was authored by Sergey Kanzhelev. Thank you David Fowler and Richard Lander for reviews.


Operating distributed apps is hard. Distributed apps typically consists of multiple components. These components may be owned and operated by different teams. Every interaction with an app results in distributed trace of code executions across many components. If your customer experiences a problem – pinpointing the root cause in one of components participated in a distributed trace is a hard task.

One big difference of distributed apps comparing to monoliths is a difficulty to correlate telemetry (like logs) across a single distributed trace. Looking at logs you can see how each component processed each request. But it is hard to know which request in once component and request in other component belong to the same distributed trace.

Historically, Application Performance Monitoring (APM) vendors provided the functionality of distributed trace context propagation from one component to another. Telemetry is correlated using this context. Due to heterogeneous nature of many environments, with components owned by different teams and using different tools for monitoring, it was always hard to instrument distributed apps consistently. APM vendors provided automatic code injection agents and SDKs to handle complexity of understanding various distributed context formats and RPC protocols.

With the upcoming transition of W3C Trace Context specification into Proposed Recommendation maturity level, and support of this specification by many vendors and platforms, the complexity of the context propagation is decreasing. The W3C Trace Context specification describes semantics of the distributed trace context and its format. This ensures that every component in a distributed app may understand this context and propagate it to components it calls into.

Microsoft is working on making distributed apps development easier with many ongoing developments like Orleans framework and project Dapr. As for distributed trace context propagation – Microsoft services and platforms will be adopting a W3C Trace Context format.

We believe that ASP.NET Core must provide an outstanding experience for building distributed tracing apps. With every release of ASP.NET Core we execute on this promise. This post describes the scenario of distributed tracing and logging highlighting improvements in .NET Core 3.0 and talks about discussions of a new exciting features we plan to add going forward.

Distributed Tracing and Logging

Let’s explore distributed tracing in .NET Core 3.0 and improvements recently made. First, we’ll see how two “out of the box” ASP.NET Core 3.0 apps has logs correlated across the entire distributed trace. Second, we’ll explore how easy it is to set distributed trace context for any .NET Core application and how it will automatically be propagated across http. And third, we’ll see how the same distributed trace identity is used by telemetry SDKs like OpenTelemetry and ASP.NET Core logs.

This demo will also demonstrate how .NET Core 3.0 embraces W3C Trace Context standard and what other features it offers.

Demo set up

In this demo we will have three simple components: ClientApp, FrontEndApp and BackEndApp.

BackEndApp is a template ASP.NET Core application called WeatherApp. It exposes a REST API to get a weather forecast.

FrontEndApp proxies all incoming requests into the calls to BackEndApp using this controller:

public class WeatherForecastProxyController : ControllerBase
{ private readonly ILogger<WeatherForecastProxyController> _logger; private readonly HttpClient _httpClient; public WeatherForecastProxyController( ILogger<WeatherForecastProxyController> logger, HttpClient httpClient) { _logger = logger; _httpClient = httpClient; } [HttpGet] public async Task<IEnumerable<WeatherForecast>> Get() { var jsonStream = await _httpClient.GetStreamAsync("http://localhost:5001/weatherforecast"); var weatherForecast = await JsonSerializer.DeserializeAsync<IEnumerable<WeatherForecast>>(jsonStream); return weatherForecast; }

Finally, ClientApp is a .NET Core 3.0 Windows Forms app. ClientApp calls into FrontEndApp for the weather forecast.

private async Task<string> GetWeatherForecast()
{ return await _httpClient.GetStringAsync( "http://localhost:5000/weatherforecastproxy");

Please note, there were no additional SDKs enabled or libraries installed on demo apps. As the demo progresses – every code change will be mentioned.

Correlated logs

Let’s make the very first call from ClientApp and take a look at the logs produced by FrontEndApp and BackEndApp.

FrontEndApp (a few line breaks added for readability):

info: Microsoft.AspNetCore.Routing.EndpointMiddleware[1] => ConnectionId:0HLR1BR0PL1CH => RequestPath:/weatherforecastproxy RequestId:0HLR1BR0PL1CH:00000001, SpanId:|363a800a-4cf070ad93fe3bd8., TraceId:363a800a-4cf070ad93fe3bd8, ParentId:
Executed endpoint 'FrontEndApp.Controllers.WeatherForecastProxyController.Get (FrontEndApp)'


info: BackEndApp.Controllers.WeatherForecastController[0] => ConnectionId:0HLR1BMQHFKRL => RequestPath:/weatherforecast RequestId:0HLR1BMQHFKRL:00000002, SpanId:|363a800a-4cf070ad93fe3bd8.94c1cdba_, TraceId:363a800a-4cf070ad93fe3bd8, ParentId:|363a800a-4cf070ad93fe3bd8. Executed endpoint 'FrontEndApp.Controllers.WeatherForecastController.Get (BackEndApp)'

Like magic, logs from two independent apps share the same TraceId. Behind the scene, ASP.NET Core 3.0 app will initialize a distributed trace context and pass it in the header. This is how incoming headers to the BackEndApp looks like:

You may notice that FrontEndApp didn’t receive any additional headers:

The reason is that in ASP.NET Core apps – distributed trace being initiated by ASP.NET Core framework itself on every incoming request. Next section explains how to do it for any .NET Core 3.0 app.

Initiate distributed trace in .NET Core 3.0 app

You may have noticed the difference in behavior of Windows Forms ClientApp and ASP.NET Core FrontEndApp. ClientApp didn’t set any distributed trace context. So FrontEndApp didn’t receive it. It is easy to set up distributed operation. Easiest way to do it is to use an API called Activity from the DiagnosticSource package.

private async Task<string> GetWeatherForecast()
{ var activity = new Activity("CallToBackend").Start(); try { return await _httpClient.GetStringAsync( "http://localhost:5000/weatherforecastproxy"); } finally { activity.Stop(); }

Once you have started an activity, HttpClient knows that distributed trace context needs to be propagated. Now all three components – ClientApp, FrontEndApp and BackEndApp share the same TraceId.

W3C Trace Context support

You may notice that the context is propagating using the header called Request-Id. This header was introduced in Asp.Net Core 2.0 and is used by default for better compatibility with these apps. However, as the W3C Trace Context specification is being widely adopted, it is recommended to switch to this format of context propagation.

With .NET Core 3.0, it is easy to switch to W3C Trace Context format to propagate distributed trace identifiers. Easiest way to do it is in the main method- just add a simple line in the Main method:

static void Main()
{ Activity.DefaultIdFormat = ActivityIdFormat.W3C; … Application.Run(new MainForm());

Now, when the FrontEndApp receives requests from the ClientApp, you see a traceparent header in the request:

The ASP.NET Core app will understand this header and recognize that it needs to use W3C Trace Context format for outgoing calls now.

Note, ASP.NET Core apps will recognize the correct format of distributed trace context automatically. However, it is still a good practice to switch the default format of distributed trace context to W3C for better interoperability in heterogeneous environments.

You will see all the logs attributed with the TraceId and SpanId obtained from the incoming header:

info: Microsoft.AspNetCore.Hosting.Diagnostics[1] => ConnectionId:0HLQV2BC3VP2T => RequestPath:/weatherforecast RequestId:0HLQV2BC3VP2T:00000001, SpanId:da13aa3c6fd9c146, TraceId:f11a03e3f078414fa7c0a0ce568c8b5c, ParentId:5076c17d0a604244 Request starting HTTP/1.1 GET http://localhost:5000/weatherforecast

Activity and distributed tracing with OpenTelemetry

OpenTelemetry provides a single set of APIs, libraries, agents, and collector services to capture distributed traces and metrics from your application. You can analyze them using Prometheus, Jaeger, Zipkin, and other observability tools.

Let’s enable OpenTelemetry on the BackEndApp. It is very easy to do, just call AddOpenTelemetry on startup:

services.AddOpenTelemetry(b => b.UseZipkin(o => { o.ServiceName="BackEndApp"; o.Endpoint=new Uri("http://zipkin /api/v2/spans"); }) .AddRequestCollector());

Now, as we just saw, TraceId in the FrontEndApp logs will match TraceId in the BackEndApp.

info: Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker[2] => ConnectionId:0HLR2RC6BIIVO => RequestPath:/weatherforecastproxy RequestId:0HLR2RC6BIIVO:00000001, SpanId:54e2de7b9428e940, TraceId:e1a9b61ec50c954d852f645262c7b31a, ParentId:69dce1f155911a45 => FrontEndApp.Controllers.WeatherForecastProxyController.Get (FrontEndApp)
Executed action FrontEndApp.Controllers.WeatherForecastProxyController.Get (FrontEndApp) in 3187.3112ms info: Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker[2] => ConnectionId:0HLR2RLEHSKBV => RequestPath:/weatherforecast RequestId:0HLR2RLEHSKBV:00000001, SpanId:0e783a0867544240, TraceId:e1a9b61ec50c954d852f645262c7b31a, ParentId:54e2de7b9428e940 => BackEndApp.Controllers.WeatherForecastController.Get (BackEndApp)
Executed action BackEndApp.Controllers.WeatherForecastController.Get (BackEndApp) in 3085.9111ms

Furthermore, the same Trace will be reported by Zipkin. So now you can correlate distributed traces collected by your distributed tracing tool and logs from the machine. You can also give this TraceId to the user when ClientApp experience issues. The user can share it with your app support and corresponding logs and distributed traces can be easily discovered across all components.

Taking example one step further – you can easily enable monitoring for all three components and see them on the gantt chart.

ASP.NET Core apps integrates with distributed trace

As we just seen telemetry collected by Application Monitoring vendors is correlated using the same distributed trace context as ASP.NET Core uses. This makes ASP.NET Core 3.0 apps great for the environments where different components are owned by different teams.

Imagine that only two of apps – A and C on the picture below enabled telemetry collection using SDK like OpenTelemetry. Before ASP.NET Core 3.0 it would mean that distributed tracing will not work, and a trace will be “broken” by app B.

With ASP.NET Core 3.0, since in most deployments ASP.NET Core apps are configured with the basic logging enabled, app B will propagate distributed trace context. This distributed traces from A and C will be correlated.

With the example of apps from before – if ClientApp and BackEndApp are instrumented and FrontEndApp is not – you see distributed trace is still being correlated:

This also makes ASP.NET Core apps great for the service mesh environments. In service mesh deployments, A and C from the picture above may represent a service mesh. In order for service mesh to stitch request entering and leaving component B – certain headers have to be propagated by an app. See this note from the Istio for example:

Although Istio proxies are able to automatically send spans, they need some hints to tie together the entire trace. Applications need to propagate the appropriate HTTP headers so that when the proxies send span information, the spans can be correlated correctly into a single trace.

As we work with service mesh authors to adopt W3C Trace Context format, ASP.NET Core apps will “just work” and propagate needed headers.

Passing additional context

Talking about other scenarios, it is often the case that you want to share more context between components in a distributed app. Let’s say a ClientApp wants to send its version so all REST calls will know where the request is coming from. You can add these properties in Activity.Baggage like this:

private async Task<string> GetWeatherForecast()
{ var activity = new Activity("CallToBackend") .AddBaggage("appVersion", "v1.0") .Start(); try { return await _httpClient.GetStringAsync( "http://localhost:5000/weatherforecastproxy"); } finally { activity.Stop(); }

Now on server side you see an additional header Correlation-Context in both – FrontEndApp and BackEndApp.

And you can use the Activity.Baggage to attribute your logs:

var appVersion = Activity.Current.Baggage.FirstOrDefault(b => b.Key == "appVersion").Value;
using (_logger.BeginScope($"appVersion={appVersion}"))
{ _logger.LogInformation("this weather forecast is from random source");

And you see the scope now contains an appVersion:

info: FrontEndApp.Controllers.WeatherForecastController[0] => ConnectionId:0HLQV353507UG => RequestPath:/weatherforecast RequestId:0HLQV353507UG:00000001, SpanId:37a0f7ebf3ecac42, TraceId:c7e07b7719a7a3489617663753f985e4, ParentId:f5df77ba38504846 => FrontEndApp.Controllers.WeatherForecastController.Get (BackEndApp) => appVersion=v1.0 this weather forecast is from random source

Next steps

With the improvements for ASP.NET Core 3.0 we hear that some of the features included in ASP.NET Core is hard to consume. Developers and DevOps wants a turnkey telemetry solution that will work with many APM vendors. We believe that investments we are making in OpenTelemetry will allow more people to benefit from investments we are making in ASP.NET Core monitoring and troubleshooting. This is one of the big areas of investments for a team.

We also help people adopt W3C Trace Context everywhere and will be making it a default distributed trace context propagation format in future versions of ASP.NET Core.

Another area of investments is to improve distributed context propagation scenarios. Distributed apps comparing to monoliths are lacking common shared state with the lifetime of a single distributed trace. This shared state (or context) can be used for basic logging as was described in this article, as well as for advanced routing of requests, experimentation, A/B testing, business context propagation, etc. Some of scenarios are described in this epic: Distributed Context in ASP.NET and Open Telemetry.

Please send us your feedback and tell what improvements in distributed apps troubleshooting and monitoring we need to make.


Posted on Leave a comment

Top Programming Languages Of 2019

Every year GitHub release their State of the Octoverse report containing a huge number of insights drawn from datamining the massive number of public and private repositories on GitHub.  One of the most interesting parts of the report is always the most popular programming languages.  This year, the 10 most popular programming languages on GitHub are:

  1. JavaScript
  2. Python
  3. Java
  4. PHP
  5. C#
  6. C++
  7. TypeScript
  8. Shell
  9. C
  10. Ruby

The list was created using the following criteria:

Top 10 primary languages over time, ranked by number of unique contributors to public and private repositories tagged with the appropriate primary language.

Every year Stack Overflow have a similar report, drawn instead from a developer survey.  The language popularity reports are remarkably consistent between the two 2019 reports.

You can learn more about the reports watching the video below.

GameDev News Programming

Posted on Leave a comment

ASP.NET Core updates in .NET Core 3.1 Preview 2

Daniel Roth


.NET Core 3.1 Preview 2 is now available. This release is primarily focused on bug fixes, but it contains a few new features as well.

Here’s what’s new in this release for ASP.NET Core:

  • New component tag helper
  • Prevent default actions for events in Blazor apps
  • Stop event propagation in Blazor apps
  • Validation of nested models in Blazor forms
  • Detailed errors during Blazor app development

See the release notes for additional details and known issues.

Get started

To get started with ASP.NET Core in .NET Core 3.1 Preview 2 install the .NET Core 3.1 Preview 2 SDK.

If you’re on Windows using Visual Studio, for the best experience we recommend installing the latest preview of Visual Studio 2019 16.4. Installing Visual Studio 2019 16.4 will also install .NET Core 3.1 Preview 2, so you don’t need to separately install it. For Blazor development with .NET Core 3.1, Visual Studio 2019 16.4 is required.

Alongside this .NET Core 3.1 Preview 2 release, we’ve also released a Blazor WebAssembly update. To install the latest Blazor WebAssembly template also run the following command:

dotnet new -i Microsoft.AspNetCore.Blazor.Templates::3.1.0-preview2.19528.8

Upgrade an existing project

To upgrade an existing ASP.NET Core 3.1 Preview 1 project to 3.1 Preview 2:

  • Update all Microsoft.AspNetCore.* package references to 3.1.0-preview2.19528.8

See also the full list of breaking changes in ASP.NET Core 3.1.

That’s it! You should now be all set to use .NET Core 3.1 Preview 2!

New component tag helper

Using Razor components from views and pages is now more convenient with the new component tag helper.

Previously, rendering a component from a view or page involved using the RenderComponentAsync HTML helper.

@(await Html.RenderComponentAsync<Counter>(RenderMode.ServerPrerendered, new { IncrementAmount = 10 }))

The new component tag helper simplifies the syntax for rendering components from pages and views. Simply specify the type of the component you wish to render as well as the desired render mode. You can also specify component parameters using attributes prefixed with param-.

<component type="typeof(Counter)" render-mode="ServerPrerendered" param-IncrementAmount="10" />

The different render modes allow you to control how the component is rendered:

RenderMode Description
Static Renders the component into static HTML.
Server Renders a marker for a Blazor Server application. This doesn’t include any output from the component. When the user-agent starts, it uses this marker to bootstrap the Blazor app.
ServerPrerendered Renders the component into static HTML and includes a marker for a Blazor Server app. When the user-agent starts, it uses this marker to bootstrap the Blazor app.

Prevent default actions for events in Blazor apps

You can now prevent the default action for events in Blazor apps using the new @oneventname:preventDefault directive attribute. For example, the following component displays a count in a text box that can be changed by pressing the “+” or “-” keys:

<p>Press "+" or "-" in change the count.</p>
<input value="@count" @onkeypress="@KeyHandler" @onkeypress:preventDefault /> @code { int count = 0; void KeyHandler(KeyboardEventArgs ev) { if (ev.Key == "+") { count++; } else if (ev.Key == "-") { count--; } }

The @onkeypress:preventDefault directive attribute prevents the default action of showing the text typed by the user in the text box. Specifying this attribute without a value is equivalent to @onkeypress:preventDefault="true". The value of the attribute can also be an expression: @onkeypress:preventDefault="shouldPreventDefault". You don’t have to define an event handler to prevent the default action; both features can be used independently.

Stop event propagation in Blazor apps

Use the new @oneventname:stopPropagation directive attribute to stop event propagation in Blazor apps.

In the following example, checking the checkbox prevents click events from the child div from propagating to the parent div:

<input @bind="stopPropagation" type="checkbox" />
Parent div
Child div
</div> <button @onclick="OnClick">Click me!</button> @code { bool stopPropagation; void OnClickParentDiv() => Console.WriteLine("Parent div clicked."); void OnClickChildDiv() => Console.WriteLine("Child div clicked."); }

Detailed errors during Blazor app development

When your Blazor app isn’t functioning properly during development, it’s important to get detailed error information so that you can troubleshoot and fix the issues. Blazor apps now display a gold bar at the bottom of the screen when an error occurs.

During development, in Blazor Server apps, the gold bar will direct you to the browser console where you can see the exception that has occurred.

Blazor detailed errors in development

In production, the gold bar notifies the user that something has gone wrong, and recommends the user to refresh the browser.

Blazor detailed errors in production

The UI for this error handling experience is part of the updated Blazor project templates so that it can be easily customized:


An error has occurred. This application may no longer respond until reloaded. An unhandled exception has occurred. See browser dev tools for details. Reload 🗙

Validation of nested models in Blazor forms

Blazor provides support for validating form input using data annotations with the built-in DataAnnotationsValidator. However, the DataAnnotationsValidator only validates top-level properties of the model bound to the form.

To validate the entire object graph of the bound model, try out the new ObjectGraphDataAnnotationsValidator available in the experimental Microsoft.AspNetCore.Blazor.DataAnnotations.Validation package:

<EditForm Model="@model" OnValidSubmit="@HandleValidSubmit"> <ObjectGraphDataAnnotationsValidator /> ...

The Microsoft.AspNetCore.Blazor.DataAnnotations.Validation is not slated to ship with .NET Core 3.1, but is provided as an experimental package to get early feedback.

Give feedback

We hope you enjoy the new features in this preview release of ASP.NET Core! Please let us know what you think by filing issues on GitHub.

Thanks for trying out ASP.NET Core!

Daniel Roth
Daniel Roth

Principal Program Manager, ASP.NET

Follow Daniel   

Posted on Leave a comment

Vulkan Unified Samples Repository

The Khronos Group have just released the Vulkan Unified Samples Repository, a single location for the best tutorials and code samples for learning and using the Vulkan API.

Details from the Khronos blog:

Today, The Khronos® Group releases the Vulkan ® Unified Samples Repository, a new central location where anyone can access Khronos-reviewed, high-quality Vulkan code samples in order to make development easier and more streamlined for all abilities. Khronos and its members, in collaboration with external contributors, created the Vulkan Unified Samples Project in response to user demand for more accessible resources and best practices for developing with Vulkan. Within Khronos, the Vulkan Working Group discovered that there were many useful and high-quality samples available already (both from members and external contributors), but they were not all in one central location. Additionally, there was no top-level review of all the samples for interoperability or compatibility. This new repository project was created to solve this challenge by putting resources in one place, ensuring samples are reviewed and maintained by Khronos. They are then organized into a central library available for developers of all abilities to use, learn from, and gain ideas.

The first group of samples includes a generous donation of performance-based samples and best practice documents from Khronos member, Arm.

The repository is hosted entirely on GitHub under the Apache 2.0 source license.  The code samples are located here.

You can learn more in the video below.

GameDev News Programming

Posted on Leave a comment

Haxe 4.0.0 Released

The Haxe Programming Language just hit a major milestone with the release of version 4.0.0.  The programming language gains several new features such as:

  • New function type syntax
  • Arrow function syntax
  • final keyword
  • New and faster Haxe built-in interpreter
  • Unicode support on all targets
  • Key-value iterators
  • Auto-“using” for types
  • IDE services protocol for better IDE support
  • New high-performance run-time HashLink, a successor of Neko
  • .. and much more!

Check the complete What’s New Guide for a full list of changes in this release, including possible breaking changes from Haxe 3.x.  There is a thriving ecosystem of game engines and frameworks for Haxe which we showcased here.  Of particular interest are the Blender based Armory3D engine (tutorial series here) and the popular and mature 2D frame HaxeFlixel (tutorial series here).

You can learn more about the Haxe 4.0.0 release in the video below.

GameDev News Programming

Posted on Leave a comment

Upcoming SameSite Cookie Changes in ASP.NET and ASP.NET Core



SameSite is a 2016 extension to HTTP cookies intended to mitigate cross site request forgery (CSRF). The original design was an opt-in feature which could be used by adding a new SameSite property to cookies. It had two values, Lax and Strict. Setting the value to Lax indicated the cookie should be sent on navigation within the same site, or through GET navigation to your site from other sites. A value of Strict limited the cookie to requests which only originated from the same site. Not setting the property at all placed no restrictions on how the cookie flowed in requests. OpenIdConnect authentication operations (e.g. login, logout), and other features that send POST requests from an external site to the site requesting the operation, can use cookies for correlation and/or CSRF protection. These operations would need to opt-out of SameSite, by not setting the property at all, to ensure these cookies will be sent during their specialized request flows.

Google is now updating the standard and implementing their proposed changes in an upcoming version of Chrome. The change adds a new SameSite value, “None”, and changes the default behavior to “Lax”. This breaks OpenIdConnect logins, and potentially other features your web site may rely on, these features will have to use cookies whose SameSite property is set to a value of “None”. However browsers which adhere to the original standard and are unaware of the new value have a different behavior to browsers which use the new standard as the SameSite standard states that if a browser sees a value for SameSite it does not understand it should treat that value as “Strict”. This means your .NET website will now have to add user agent sniffing to decide whether you send the new None value, or not send the attribute at all.

.NET will issue updates to change the behavior of its SameSite attribute behavior in .NET 4.7.2 and in .NET Core 2.1 and above to reflect Google’s introduction of a new value. The updates for the .NET Framework will be available on November 19th as an optional update via Microsoft Update and WSUS if you use the “Check for Update” functionality. On December 10th it will become widely available and appear in Microsoft Update without you having to specifically check for updates. .NET Core updates will be available with .NET Core 3.1 starting with preview 1, in November.

.NET Core 3.1 will contain an updated enum definition, SameSite.Unspecified which will not set the SameSite property.

The OpenIdConnect middleware for Microsoft.Owin v4.1 and .NET Core will be updated at the same time as their .NET Framework and .NET updates, however we cannot introduce the user agent sniffing code into the framework, this must be implemented in your site code. The implementation of agent sniffing will vary according to what version of ASP.NET or ASP.NET Core you are using and the browsers you wish to support.

For ASP.NET 4.7.2 with Microsoft.Owin 4.1.0 agent sniffing can be implemented using ICookieManager;

public class SameSiteCookieManager : ICookieManager
{ private readonly ICookieManager _innerManager; public SameSiteCookieManager() : this(new CookieManager()) { } public SameSiteCookieManager(ICookieManager innerManager) { _innerManager = innerManager; } public void AppendResponseCookie(IOwinContext context, string key, string value, CookieOptions options) { CheckSameSite(context, options); _innerManager.AppendResponseCookie(context, key, value, options); } public void DeleteCookie(IOwinContext context, string key, CookieOptions options) { CheckSameSite(context, options); _innerManager.DeleteCookie(context, key, options); } public string GetRequestCookie(IOwinContext context, string key) { return _innerManager.GetRequestCookie(context, key); } private void CheckSameSite(IOwinContext context, CookieOptions options) { if (DisallowsSameSiteNone(context) && options.SameSite == SameSiteMode.None) { options.SameSite = null; } } public static bool DisallowsSameSiteNone(IOwinContext context) { // TODO: Use your User Agent library of choice here. var userAgent = context.Request.Headers["User-Agent"]; return userAgent.Contains("BrokenUserAgent") || userAgent.Contains("BrokenUserAgent2") }

And then configure OpenIdConnect settings to use the new CookieManager;

app.UseOpenIdConnectAuthentication( new OpenIdConnectAuthenticationOptions { // … Your preexisting options … CookieManager = new SameSiteCookieManager(new SystemWebCookieManager())

SystemWebCookieManager will need the .NET 4.7.2 or later SameSite patch installed to work correctly.

For ASP.NET Core you should install the patches and then implement the agent sniffing code within a cookie policy. For versions prior to 3.1 replace SameSiteMode.Unspecified with (SameSiteMode)(-1).

private void CheckSameSite(HttpContext httpContext, CookieOptions options)
{ if (options.SameSite > SameSiteMode.Unspecified) { var userAgent = httpContext.Request.Headers["User-Agent"].ToString(); // TODO: Use your User Agent library of choice here. if (/* UserAgent doesn’t support new behavior */) { // For .NET Core < 3.1 set SameSite = -1 options.SameSite = SameSiteMode.Unspecified; } }
} public void ConfigureServices(IServiceCollection services)
{ services.Configure<CookiePolicyOptions>(options => { options.MinimumSameSitePolicy = SameSiteMode.Unspecified; options.OnAppendCookie = cookieContext => CheckSameSite(cookieContext.Context, cookieContext.CookieOptions); options.OnDeleteCookie = cookieContext => CheckSameSite(cookieContext.Context, cookieContext.CookieOptions); });
} public void Configure(IApplicationBuilder app)
{ app.UseCookiePolicy(); // Before UseAuthentication or anything else that writes cookies. app.UseAuthentication(); // …

Under testing with the Azure Active Directory team we have found the following checks work for all the common user agents that Azure Active Directory sees that don’t understand the new value.

public static bool DisallowsSameSiteNone(string userAgent)
    // Cover all iOS based browsers here. This includes:
    // - Safari on iOS 12 for iPhone, iPod Touch, iPad
    // - WkWebview on iOS 12 for iPhone, iPod Touch, iPad
    // - Chrome on iOS 12 for iPhone, iPod Touch, iPad
    // All of which are broken by SameSite=None, because they use the iOS networking stack
    if (userAgent.Contains("CPU iPhone OS 12") || userAgent.Contains("iPad; CPU OS 12"))
        return true;
    }     // Cover Mac OS X based browsers that use the Mac OS networking stack. This includes:
    // - Safari on Mac OS X.
    // This does not include:
    // - Chrome on Mac OS X
    // Because they do not use the Mac OS networking stack.
    if (userAgent.Contains("Macintosh; Intel Mac OS X 10_14") &&  userAgent.Contains("Version/") && userAgent.Contains("Safari"))
        return true;
    }     // Cover Chrome 50-69, because some versions are broken by SameSite=None,  // and none in this range require it.
    // Note: this covers some pre-Chromium Edge versions,  // but pre-Chromium Edge does not require SameSite=None.
    if (userAgent.Contains("Chrome/5") || userAgent.Contains("Chrome/6"))
        return true;
    }     return false;

This browser list is by no means canonical and you should validate that the common browsers and other user agents your system supports behave as expected once the update is in place.

Chrome 80 is scheduled to turn on the new behavior in February or March 2020, including a temporary mitigation added in Chrome 79 Beta. If you want to test the new behavior without the mitigation use Chromium 76. Older versions of Chromium are available for download.

If you cannot update your framework versions by the time Chrome turns the new behavior in early 2020 you may be able to change your OpenIdConnect flow to a Code flow, rather than the default implicit flow that ASP.NET and ASP.NET Core uses, but this should be viewed as a temporary measure.

We strongly encourage you to download the updated .NET Framework and .NET Core versions when they become available in November and start planning your update before Chrome’s changes are rolled out.