Strathweb. A free flowing tech monologue.

In the last two posts we covered quantum key exchange using the B92 and BB84 protocols.

In the last part of this series we started talking about the area of quantum cryptography, or more accurately, quantum key distribution.

To celebrate the release of .NET 5.0, which happened yesterday, we are happy to announce the release of dotnet-script - with support for .NET 5.0 and C# 9.

Almost fours year ago I blogged about building lightweight microservices with ASP.NET Core 1.2 (which actually never shipped in such version and later became ASP.NET Core 2.0).

This is already part 9 of the series (time flies!).

Last time, we discussed the quantum teleportation protocol, which relies on the phenomenon of quantum entanglement to move an arbitrary quantum state from one qubit to another, even if they are spatially separated.

Some time ago I blogged about new Omnisharp features - support for analyzers and support for Editorconfig.

In the previous part of the series we discussed how quantum theory prohibits copying of an arbitrary quantum state.

In the last part of this series we looked at the phenomenon of entanglement - one of the core concepts of quantum theory, which has been fundamentally important in the development of quantum information theory.

The QDK provides an excellent, low barrier way of getting started with Q# development - without having to deal with the compiler directly, or worrying about how to simulate the code you wrote on a classical device.

In the last post in this series we dove deep into the mathematics and usage examples of multi-qubit gates, with special attention paid to one of the most critical gates in quantum computing, the CNOT gate.

In the previous post of this series, we discussed single qubit gates.

Two days ago I blogged about doing semantic classification of C# code using Roslyn.

Last week I wrote a guest post on the Q# community blog about the new standalone/self-contained Q# applications that were introduced in Microsoft Quantum Development Kit 0.11.2004.2825.

A while ago, I blogged about using Roslyn’s completion service.

We left off in the last post after having discussed the Hadamard gate - our first quantum gate - and how it can be used to crate a uniform superposiiton for a single qubit.

One of the nice new features that we shipped in OmniSharp recently, and that has already made its way into the C# Extension for VS Code is support for decompilation.

In the previous post in this series we mentioned the concept of superposition briefly.

As we all know, we have recently been spoiled with the first preview release of .NET 5.

Quantum mechanics is one of the fundamental theories of physics, and has been tremendously successful at describing the behavior of subatomic particles.

There are several ways of bootstrapping your MVC applications on top of ASP.NET Core 3.x.

OmniSharp powers intellisense and language services in C# plugins and extensions for numerous editors, including VS Code.

EditorConfig is an excellent way to enforce stylistic rules on your C# projects.

When you compile your C#, F# or VB.NET code, which are all high-level managed languages, the relevant compiler doesn’t compile it to native code, but instead it compiles it into the Common Intermedia Language.

One of the little known and rarely used hidden features of .NET Core is the ability to seed AppContext data dictionary directly from the csproj project file.

One of the awesome features introduced in .NET Core 3.0 and C# 8.0 are async streams.

In this blog post we will look at how you could create an instance of an object in C# without calling its constructor - which sounds a bit crazy, but is actually something that has been supported by both CLR and Core CLR for a long time now.

We have some exciting news to announce - dotnet-script is now supporting .NET Core 3.0.

Reflection is a tremendously powerful concept in .NET, which every C# developer, sooner or later, ends up working with.

One of the great extensibility points in the routing feature of the older versions of the ASP.NET MVC and ASP.NET Core MVC frameworks was the ability to pick up any route and dynamically point it at a given controller/action.

Recently, I blogged about Roslyn analyzers support in OmniSharp and C# extension VS Code and some background on how that feature came together.

In this post I wanted to show you how to write and embed a C# interactive shell (a REPL - read-evaluate-print-loop) in a browser, on top of WebAssembly.

Earlier this month, I wrote an article for my friends over at DotNetCurry.

Recently we merged a big (albeit still experimental) feature into OmniSharp - the support for Roslyn analyzers.

ASP.NET Core 2.1 introduced support for a little (or, should I say, not at all) documented feature called IActionResultExecutor.

The other day I was reviewing some code in an ASP.NET Core app.

A while ago we looked at how ApiControllerAttribute can be used in ASP.NET Core MVC to make Web API authoring a little bit more developer friendly.

Since the beginning of .NET Core, the one feature that I have been most anxiously waiting for, has been support for collectible assemblies.

I am involved in a few open source projects built around the Roslyn compiler.

It’s that time again, the new dotnet-script release, version 0.27.0 is out.

Both the C# compiler and the CLR/CoreCLR runtimes contain a bunch of rules that are in place to save us from ourselves (and to allow us to write code without needing to fully understand ECMA-334 C# Language Specification).

ASP.NET Core MVC is pretty flexible in terms of how it expects you to return results from the API actions.

When you are building flexible HTTP APIs, supporting a wide array of different clients, it is common to rely on the process of content negotiation, to allow each client to interact with the API in the most convenient way - be it JSON, XML, Protobuf, Messa…

After a short holiday break, the dotnet-script release train is back at full speed!

As part of my recent talks on ASP.NET core, I have been showing how to build a custom IFileProvider for ASP.NET Core.

One of the most common things that I have seen developers working with ASP.NET Core struggle with, is the way to centrally and consistently handle application errors and input validation.

Last year I blogged about a way to handle NuGet package versions at the solution level for .NET SDK-based csproj project files (so those using entries to define their NuGet dependencies).

I was working on an interesting issue in an ASP.NET Core recently.

It is common to leverage action filters when building MVC applications - this was the case in classic ASP.NET MVC, in ASP.NET Web API and is a still widely used technique (with much richer support!)

A few years ago I blogged about dependency injection directly into actions in ASP.NET Web API.