There is no question that the emergence of generative AI is going to significantly alter various aspects of our daily lives. At the same time, most of the large language models (LLMs) are designed as general-purpose black boxes and their utility is initially confined to the data they were trained on. However, it is possible to extend their functionality and reasoning to any custom data set, be it private or public, even without the massive effort that would be needed to retrain or even fine-tune them.

We are going to start exploring that concept today with a multi-part post series on “bringing your own data” to Azure OpenAI. In part one today, we will set up the necessary Azure resources and prepare the stage for a client application integration, which will follow in parts two and further.

One of the cool new features coming in .NET 8.0 is the ability to take advantage of a zero-overhead approach to access private members, via the UnsafeAccessorAttribute. This is a great improvement over the traditional, slow, reflection-based approach, as the new functionality is not only fast (compile-time) but also compatible with Native AOT.

Let’s have a quick look at the feature, which was originally tracked by this Github issue.

At the end of last year I blogged about using .NET 7 and the prototype dotnet WASI SDK from Steve Sanderson to build WASM-WASI applications. That SDK is now deprecated and the WASI workload has instead been integrated into the main .NET 8, which will ship in November this year. The workload is still flagged as experimental, but there is now commitment from the .NET runtime and SDK teams to make the WASM-WASI experience first class in .NET.

In this post we will explore where this workload is at today, and what we can and can’t do with it at this stage.

I recently blogged about building GPT-powered applications with Azure OpenAI Service. In that post, we looked at using the text-davinci-003 model to provide classification capabilities for natural text - more specifically, we categorized and rated scientific papers based on the interest area (note that the recommended model for this task now is gpt-35-turbo now).

In today’s post we are going to continue exploring Azure OpenAI Service, this time looking at the embeddings model, text-embedding-ada-002.

Earlier this year I blogged about post-quantum cryptography in .NET using Dilithium and Kyber. This was then followed by another post, which showed how Dilithium can be wired into a popular .NET Identity Server, Duende Identity Server, for token signing purposes.

Today I would like to announce Strathweb.Dilithium, a set of .NET helper libraries to facilitate working with Dilithium in ASP.NET Core projects.

In the last post we covered how UniFFI can be used to elegantly create C bindings and generate bridge C# code that allows for calling native code written in Rust from a C# program. Today, we are going to build upon that, and we will show - in a true cross platform fashion - how the same core Rust library we used last time around, and the same toolchain that we have already set up, can be used to generate similar bindings for Swift. This will enable us to reuse our native Rust code in an iOS or macOS application.

There are plenty of reasons to be excited about Rust. Rust provides cross-platform compatibility and can compile to nearly any platform, including Windows, iOS, Android, and many more. One of Rust’s core features is its focus on memory safety. It accomplishes this through its ownership model, which helps prevent common bugs such as null pointer dereferencing, dangling pointers, and data races.

All of this makes Rust an excellent alternative to C++/C for implementing shared logic and algorithms, spanning many different platforms.

In this post we shall see how we can integrate Rust into program written in C# - and how a native library built with Rust can be called into from a .NET application.

In January I blogged about using the QIR Runner as an alternative (or even preferred!) way for simulating your Q# programs locally. The main reason behind that were performance gains (QIR runner is written in Rust), standardization (same intermediate format used as input into the simulator and the quantum hardware) and the complete incompatibility of the default QDK full state simulator with ARM64 processor architecture (even under x64 emulation).

One major limitation of the QIR Runner was that it was also x64 compatible only, but at least still worked well on ARM processors under emulation. This limitation has now been addressed.

On March 12th, a new IETF draft JOSE and COSE Encoding for Dilithium was published. It describes JSON serializations for CRYSTALS-Dilithium, a post-quantum cryptography suite. This in turn allows using post-quantum cryptography for tasks like signing JSON Web Tokens in a standardized fashion.

I previously blogged about using CRYSTALS-Dilithium from .NET applications, so in this post let’s see how we can apply this new draft to one of the most popular .NET OpenID Connect / OAuth 2.0 servers, Duende Identity Server