1. Null-Conditional Assignment (?=)

We've all written this boilerplate code a thousand times. You have a nullable object, and you only want to assign a value to one of its properties if the object itself isn't null.

In C# 13, you had to perform an explicit null check.

public class Channel
{
    public int Subscribers { get; set; }
    public int Members { get; set; }
}

// ---

Channel? myChannel = null; // or new Channel();

// We have to check for null before assigning
if (myChannel is not null)
{
    myChannel.Subscribers = 1000;
}

After: C# 14

With the new null-conditional assignment operator (?=), you can do this in a single, safe, and readable line.

Channel? myChannel = null;

// This will only assign 1000 if myChannel is not null
myChannel?.Subscribers = 1000;

It's a small change, but a very welcome one!

2. The field Keyword for Semi-Auto-Properties

Auto-properties are great, but as soon as you need to add logic to your getter or setter (like validation), you have to convert it to a full property with an explicit private backing field.

Before: C# 13

This required creating a separate field (_subscribers) just to add a check in the setter.

public class Channel
{
    private int _subscribers;
    public int Subscribers
    {
        get => _subscribers;
        set
        {
            if (value < 1000)
            {
                throw new ArgumentException("Not enough subs!");
            }
            _subscribers = value;
        }
    }
}

After: C# 14

The new field keyword gives you access to the implicit, compiler-generated backing field of an auto-property. This means you can add logic without the boilerplate!

public class Channel
{
    public int Subscribers
    {
        get => field; // 'field' refers to the implicit backing field
        set
        {
            if (value < 1000)
            {
                throw new ArgumentException("Not enough subs!");
            }
            field = value; // Assign to the implicit backing field
        }
    }
}

This keeps the code much cleaner and more concise.

3. User-Defined Compound Operators

This one is really cool. Have you ever wanted to define what a compound operator like ++ or += does for your own custom type? Now you can!

Imagine we want the ++ operator to increment both the Subscribers and Members properties of our Channel class at the same time.

Before: C# 13

You'd have to increment each property manually.

var myChannel = new Channel();
myChannel.Subscribers++;
myChannel.Members++;

After: C# 14

You can now overload the compound operator directly in your class definition.

public class Channel
{
    public int Subscribers { get; set; }
    public int Members { get; set; }

    public void operator ++()
    {
        Subscribers++;
        Members++;
    }

    public void operator +=(int amount)
    {
        Subscribers += amount;
        Members += amount;
    }
}

// ---

var myChannel = new Channel();
myChannel++; // This now increments both Subscribers and Members!

Console.WriteLine($"Subs: {myChannel.Subscribers}, Members: {myChannel.Members}");
// Output: Subs: 1, Members: 1

Not sure where I’d use this but hey ho!

4. The extension Keyword

Extension methods have always required a public static class and public static methods using the this keyword. C# 14 introduces a new, more explicit syntax.

Before: C# 13

The classic syntax we all know.

public static class ChannelExtensions
{
    public static void PrintDetails(this Channel c)
    {
        Console.WriteLine($"Subs: {c.Subscribers}, Members: {c.Members}");
    }
}

After: C# 14

You can now use the extension keyword to create an "extension type." The syntax is cleaner and makes the intent clearer.

public extension ChannelExtensions
{
    public void PrintDetails(this Channel c)
    {
        Console.WriteLine($"Subs: {c.Subscribers}, Members: {c.Members}");
    }
}

Personally, I'm not totally sold on this one yet, as it just creates another way to do the same thing. You can now use extension methods to add Properties, but still…

5. nameof Improvements for Generics

The nameof operator is a handy tool for getting the string name of a variable, type, or member. However, it had a limitation with generic types.

Before: C# 13

nameof worked on a constructed generic type, but not on an "unbound" or open generic type.

C#

public class Channel<T> { }
public class YouTube { }

// This worked fine
Console.WriteLine(nameof(Channel<YouTube>)); // Output: Channel

// This caused a compile error
// Console.WriteLine(nameof(Channel<>));

After: C# 14

This limitation has been removed. You can now use nameof directly on an unbound generic type.

C#

// Now this works perfectly!
Console.WriteLine(nameof(Channel<>)); // Output: Channel

This is a nice little fix for those edge cases where you need the name of the generic type definition itself.

My thoughts on C# 14

Actually they’ve been quite restrained this year. No crazy new ways to instantiate lists or classes that conceptually forks C#. I do get alot of comments on my channel saying that C# is getting too complicated, so glad they have shown restraint. Well done chaps!

Let's look at the full state of WPF today.

Alive and Well in the Enterprise and “boring” stuff

First things first: Microsoft is still actively working on WPF. It was made part of the open-source .NET Foundation and continues to receive meaningful updates. In .NET 8, we got hardware acceleration for RDP and a new folder dialog. For .NET 9, Microsoft is adding a Fluent theme to make WPF apps look more like modern Windows 11 applications, a feature many thought was reserved for newer frameworks. The official roadmap even shows plans for .NET 10. This isn't just life support; it's active development. This predictability is precisely what enterprises value, which is why you'll find WPF powering critical line-of-business applications on oil rigs, in maritime shipping, and across the manufacturing industry—the so-called "dark matter developers" who don't always show up in surveys but build the backbone of industry.

• What's new for WPF in .NET 8 - Microsoft Dev Blogs

• WPF Roadmap 2024 - GitHub

• Windows Presentation Foundation - Microsoft Docs

Third parties make bank on WPF

WPF’s longevity isn’t just thanks to Microsoft. I’d wager that third parties make more money from WPF than MS does themselves and are incentivized to keep it that way.

A massive ecosystem of vendors and open-source projects keeps it vibrant. Companies like Telerik and DevExpress continue to sell and support extensive component libraries, investing thousands to ensure developers can build complex, feature-rich applications quickly. At the same time, the open-source community is keeping things fresh. Before MS added the Fluent theme to WPF, popular projects like MahApps.Metro give WPF apps a modern Windows look and feel like Windows 10 rather than the classic WebForms inspired take, while Material Design in XAML allows you to build a Windows app that looks like an Android app. This combination of corporate and community support is a self perpetuating machine.

• WPF vs. .NET MAUI: How to Choose in 2024 - Telerik

• WPF UI Controls - DevExpress

• Material Design in XAML Toolkit - GitHub

• MahApps.Metro - GitHub

The Geographic Divide and the Ghost of WinUI

So if it's not dead, where is it hiding? I think the debate is still a thing because because WPF's popularity is highly regional. In the United States, the average salary for a WPF developer is a chonky $130,000, suggesting strong demand. But cross the pond to the UK, and the number of job postings mentioning WPF is vanishingly small. In Japan, they're practically non-existent outside of niche finance roles. Surprisingly, Google Trends data shows a huge resurgence of interest in China and South Korea. Meanwhile, Microsoft's intended successor, WinUI, has seen development activity fall off a cliff since late 2021, with its GitHub commit history looking like a ghost town compared to the flurry of activity around .NET MAUI, Avalonia, and even WPF itself.

I miss WinUI btw. Seriously. WinUI 2.x was fast, compiled native and created apps indistinguishable from the Windows 10 and Windows 11 shells. In my view if you cannot create the native Settings app pixel for pixel perfect then its not a “native” app toolkit.

• The Future of WPF: Is WPF Dead? - SciChart

• microsoft-ui-xaml (WinUI) Repository - GitHub

The Spirit Lives On: Avalonia and OpenSilver

While WPF remains a Windows-only affair, its XAML-based spirit is finding new life in cross-platform frameworks. Avalonia proudly calls itself the open-source WPF successor and even offers a product, XPF, designed to take your existing WPF applications and run them on macOS and Linux in minutes. It’s what Microsoft tried—and failed—to do with "WPF Everywhere" back in 2006, a project that morphed into the ill-fated Silverlight. And just like WPF, Silverlight's spirit has been resurrected by the community in the form of OpenSilver, which is picking up where Microsoft left off. For developers who honed their XAML skills on WPF, these frameworks offer an exciting path forward without abandoning their expertise.

• OpenSilver - A modern, open-source reimplementation of Silverlight

• Xamarin.Forms Platform Support - Microsoft Docs (Historical)

The Verdict

So, is WPF dead? No. But it has probably flatlined.

Its spirit, however, has broken free from its Windows-only confines and lives on in modern, cross-platform frameworks. The transferrable design patterns, XAML, MVVM etc are reusable across Uno and Avalonia today, even as .NET MAUI sails off into the sunset.

View this post in mega cringe video form:

Onto this week’s news:

JetBrains releases ReSharper for VS Code

For veteran developers, the news might bring a wave of nostalgia. ReSharper was, for many, an indispensable part of the C# development experience. The cry of "Please, a ReSharper license!" from a new team member was expected.

I’ve given it a go and you need to disable Microsoft's own C# and C# Dev Kit extensions, as ReSharper apparently prefers to take full command of the C# experience. This in itself signals the potential for a fascinating dynamic in the VS Code tooling space.

Once installed and your solution is loaded (perhaps after the classic ReSharper cache processing warms up, a sight familiar to Visual Studio users), the experience aims to be classic ReSharper. The "ReSharper Solution Explorer" makes an appearance, which basically mirrors the C# Dev Kit Solution Explorer. I had great success with the iconic "Initialize field from constructor" shortcut, a beloved time-saver, and it works just as well as it did in VS.

This move by JetBrains is particularly interesting given Microsoft's recent efforts to monetize the C# experience in VS Code through the C# Dev Kit, which is tied into Visual Studio subscriptions. I do think this will get somehow squashed by MS, there was a reason JetBrains announced in 2021 that they weren’t going to bother.

Relevant Links:

• JetBrains ReSharper in VS Code Public Preview Announcement https://blog.jetbrains.com/dotnet/2025/05/19/resharper-comes-to-microsoft-visual-studio-code/

• ReSharper on the Visual Studio Code Marketplace: https://marketplace.visualstudio.com/items?itemName=JetBrains.ReSharper-VSCode

SQL Server 2025 gets decent JSON support

I’ll ignore the AI stuff for this update.

Fascinating to me is the new sp_invoke_external_rest_endpoint stored procedure. This has serious potential. For years, reaching out to external web services from within SQL Server has been a clunky affair, often requiring complex CLR assemblies or other workarounds. Now, developers will be able to directly call secure HTTPS REST endpoints (supporting GET, POST, PUT, etc.) from stored procedures, triggers, or functions, and directly process the response. Imagine enriching your data in real-time by calling an external API, or triggering a workflow in another system based on a database event – all natively within SQL Server. Scary.

Complementing this external connectivity is a long-awaited enhancement to JSON support. SQL Server has had rudimentary JSON capabilities for a while – parsing with OPENJSON and formatting with FOR JSON – but it always felt like a bolt-on rather than a first-class citizen. Developers often looked to databases like PostgreSQL for more robust native JSON handling. With SQL Server 2025, that changes. The introduction of a native JSON data type aims to bring SQL Server to feature parity with competitors, allowing for more efficient storage, indexing, and querying of JSON documents directly within the relational database.

When you combine these two features – the ability to call a REST API and get a JSON response, and then store and manipulate that JSON natively – the possibilities are quite exciting, and perhaps a little "scary" in terms of the complex logic that might now reside in the database tier.

The "AI-ready" stuff extends to integrated vector database querying capabilities and other GenAI model integrations and obviously they added GitHub Copilot to the beloved SQL Server Management Studio.

Relevant Links:

• Official SQL Server 2025 Public Preview Blog: https://cloudblogs.microsoft.com/sqlserver/2025/05/19/announcing-sql-server-2025-public-preview/

• SQL Server 2025 Public Preview Discussion on Reddit: https://www.reddit.com/r/SQLServer/comments/1kqfecc/announcing_the_public_preview_of_sql_server_2025/

Windows Update Gets an Update

In a spell of wishful thinking, MS looks like they’ll try to cajole the 1000s of disparate update mechanisms on Windows to all hook into Windows Update.

This sounds like a nightmare to me but you can read more about it on “Introducing a Unified Future for App Updates on Windows” at their blog: https://techcommunity.microsoft.com/blog/windows-itpro-blog/introducing-a-unified-future-for-app-updates-on-windows/4416354

Thanks for reading and continuing to subscribe. For a video version of this post, check out:

Azure AI Foundry Local

One significant announcement is Azure Foundry Local. Think of it as a mini-version of Ollama, allowing you to run AI models locally. It's designed to work seamlessly with Azure AI Foundry and even includes an SDK for C# (though it's not yet on NuGet). This means you can integrate AI capabilities directly into your C# and .NET applications, running models on your local machine, even with full Mac GPU support. Imagine asking a question like, "Is .NET and C# cool and popular?" and getting an AI-powered "Yes!" from your local setup just to help alleviate your anxiety.

It provides a fully OpenAI Chat Completion API compatible local endpoint when you run it, so you can actually point existing apps (assuming you can change the model name) at it and get started.

The docs are here: https://learn.microsoft.com/en-gb/azure/ai-foundry/foundry-local/get-started

.NET Aspire rolls on to 9.3

No Blazor, MVC, Razor Pages or any other content really - just .NET Aspire.

In a sign of insane irony, they’ve actually embedded GitHub Copilot into the Aspire Dashboard, which loops through the C# Dev Kit and the GitHub Copilot extension in VS Code.

I know the KPIs at MS are brutal but this is really quite something.

Azure App Service: Faster, Cheaper, Better!

Now for something positive! Azure App Service is easily my favourite service on Azure that just keeps getting better. Microsoft announced a new service plan that promises significant improvements:

• 24% cost savings on Windows for better cost-performance.

• Faster temporary storage.

• A wider range of CPU and RAM options, from modest setups to massive 256GB configurations.

• Finally, high availability with only two availability zones. This means you no longer need three nodes on your web tier to achieve a 99.99% SLA, potentially cutting a third off your App Service bills.

Most projects, and I do mean like over 90% of them, should be running on Azure App Service in my opinion. It really is that good.

Thank you for continuing to subscribe to the newsletter. If you’d like this post in slightly ironic video form, check out the below:

VS Code 1.100 sees GitHub Copilot get absorbed totally

In a masterclass of product reclassification, VS Code is now being referred to as an “AI Editor”.

Tracing the history here is fascinating. In June 2023, v1.80 release notes still referred to the GitHub Copilot as a separate extension:

But by v1.100, updates to the AI chat function is now indistinguishable from core functionality:

My view is that this is purely a response to Cursor and Windsurf. The GitHub Copilot extension is not open source, and now VS Code bundles a huge closed source extension along with it. VS Code is no longer “open source” by any definition.

Layoffs hit MAUI, TypeScript teams

Just in time for Microsoft Build next week, Microsoft has decided to lay off engineers across the firm, including “folks” in their TypeScript and .NET Android and MAUI teams. I believe the .NET MAUI team has been totally gutted.

This poor chap has been at Microsoft for 18 years and worked on the TypeScript compiler being rewritten in Go:

I guess the beatings will continue until morale improves.

.NET 10 Preview 4

Two main new features I like in this are new async methods for Zip folder creation, plus Minimal APIs get another boost with validation for Record types.

You can now do the following:

using System.IO.Compression;

await ZipFile.CreateFromDirectoryAsync("photos", "we-have-to-go-back-async.zip");

Whereas you were stuck with non-async versions in .NET 8.

As always, I do appreciate you continuing to subscribe. For a more visual version of this post, check out the YouTube version below:

Onto the Microsoft developer content…

.NET Conf “Focus on Modernisation”

CSharp “Jeff” Fritz hosted a special .NET Conf this week aimed at showing the latest techniques and tools available to upgrade the considerable estate of legacy .NET apps out there. Even Scott Hanselman dug out his Baby Smash app for an update!

A central tool highlighted was the .NET Upgrade Assistant, available as a Visual Studio extension and a CLI tool, designed to analyze projects, identify potential issues, and aid in the upgrade process for various project types like WPF, WinForms, and older ASP.NET MVC apps. The Upgrade Assistant isn’t new - its been around for donkeys years - but they have now added Github Copilot to it to provide AI generated agent-like upgrade step generation.

I remain skeptical about AI being help to help much here considering the lack of publicly available training data for this process - upgrades from .NET Framework to the latest .NET versions are the equivalent of open heart surgery and to do correctly is one of the hardest things a .NET Developer can do. It requires over a decade of archeological knowledge about .NET versions and their upgrade paths - where is this training data coming from? CodeProject blog posts?

One wild demo was the ability to embed Blazor components in a classic WebForms app. I highly suggest you watch the video as it really was a tour de force of proper .NET boomer content:

Azure releases its own MCP server

Previously this functionality was limited to Copilot within Azure itself, but to score internet points the Azure team have released a new MCP server that allows local agents, either Copilot in Agent mode, Claude, Cursor or other MCP clients to access information about your Azure infrastructure.

What’s more impressive is that it is built in .NET 9 and C#! Yes! No JavaScript or Go cop-outs here. What is wild is the way they’ve wrapped npx and the node package manager around calling different .NET binaries for each platform. I think its time that .NET had an npx equivalent.

They have been good and for now restricted the operations to read-only. But this is only a short leap away from the MCP server being able to do tasks like creating resources and then its just another short leap away from deleting them. The team know they are on the edge of something pretty crazy here, so have added one of the best worded disclaimers I’ve ever seen:

MCP as a phenomenon is very novel and cutting-edge. As with all new technology standards, consider doing a security review to ensure any systems that integrate with MCP servers follow all regulations and standards your system is expected to adhere to. This includes not only the Azure MCP Server, but any MCP client/agent that you choose to implement down to the model provider.

Basically trying to pass on any blame if something goes wrong.

One amazing example of Microsoft left hand not talking to the right hand is that the MCP server they’ve built isn’t currently compatible with their own Semantic Kernel framework due to the function names having hyphens instead of underscores, which means they’ve only tested it using the VSCode/Github Copilot MCP client and not their own .NET agents framework. Classic.

Azure MCP: https://github.com/Azure/azure-mcp

Days since Microsoft open source drama: 0

The author of popular Kubernetes open source project Spegel saw parts of their project copied by the Azure team to a project called Peerd. Spegel is an OSS project released under the MIT license, so so what I hear you cry? Well the MIT license requires the copyrights of the author to remain in the source code and to be distributed with the software - the dev teams at Microsoft removed the LICENSE file from the “fork”, replacing it with their own, violating the license and therefore technically the copyright.

The blog post explains that MS “interviewed” the author before the “fork”, doing a brain dump from the author (probably recorded into OneNote and summarised by Copilot). A similar technique to the WinGet / AppGet clone drama.

The Hacker News outrage has been brutal and in my opinion justified. I also put the word “fork” in quotes because in reality it looks like the project was copy and pasted, which isn’t technically a “fork”. This Hacker News sleuth figured it out.

Based on the commit history of Peerd essentially being a single person, I think that someone thought this was a slam dunk project for a promotion. Well, they’ve just set MS’s trust with the open source community back several years instead.

The post: https://philiplaine.com/posts/getting-forked-by-microsoft/
The Github meltdown: https://github.com/Azure/peerd/issues/109
The damage control PR reply: https://news.ycombinator.com/item?id=43755745

Thanks for reading as always! For a video version of this post, be sure to check out:

This week has seen a couple of interesting emissions from the MS teams. I’ve read about them so you don’t have to. Thanks for remaining a newsletter subscriber as I try out this new format - let me know if it works for you.

.NET 10 Preview 3 lands

Microsoft just dropped the third preview of .NET 10, the latest sneak peek at the next Long-Term Support (LTS) version due later this year. LTS releases are very important as they are quite short lived (3 years) and every .NET 8 app will have only a year to update to .NET 10 before support stops, creating a bunch of activity. They’ve been busy…

Highlights:

• C# 14: Just what we’ve always wanted (!) - extension methods, which let you add static methods, instance properties, and static properties to existing types like Ruby Monkey Patching from 2014. There's also a cleaner way to handle nulls with null-conditional assignment.

• ASP.NET Core & Blazor: Blazor is still going (yeah), with some improvements to manage state. Blazor WebAssembly apps now get default HttpClient response streaming for better memory usage with large responses and support for fingerprinted static assets for better caching. Plus, built-in support for Server-Sent Events (SSE) is here for real-time updates - could this finally be the end of SignalR?

• .NET MAUI is still alive: MAUI devs will lament the loss of ListView, Cell and TableView as they are being deprecated. On the plus side, you get fullscreen video playback in Android WebViews and an easier way to check if location services are enabled with Geolocation.IsEnabled.

Helpful Links:

• .NET Blog Announcement: https://devblogs.microsoft.com/dotnet/dotnet-10-preview-3/

• InfoQ Article: https://www.infoq.com/news/2025/04/dotnet-10-preview3/

• .NET 10 Release Notes (GitHub): https://github.com/dotnet/core/tree/main/release-notes/10.0

• .NET Downloads: https://dotnet.microsoft.com/download/dotnet/10.0

Semantic Kernel adds MCP and Google's A2A for Python users

Microsoft's Semantic Kernel for Python just got a major upgrade, adding support for two important interoperability protocols: the Model Context Protocol (MCP) and Google's Agent-to-Agent (A2A) protocol - bringing it up to parity with the C# and .NET versions, which saw MCP capability added in March.

I’m normally super salty about this stuff, but seeing it come through first for .NET has been great, likely because they are using it for Copilot under the hood.

What does this mean?

• MCP: SK can now act as both an MCP host/client and an MCP server. Think of MCP like a "USB for AI" – it standardizes how AI apps connect to external tools and data. As a host, your SK agent can easily use tools exposed by any MCP server (like those for GitHub, Slack, or custom systems). As a server, you can share your SK functions, prompts, or even entire agents with other MCP clients, like Anthropic's Claude Desktop or potentially IDEs. This makes building complex, modular AI systems much easier if that is your kind of thing.

• A2A Integration: SK now also integrates with Google's A2A protocol , which is designed for communication between different AI agents. The example MS have provided shows a “travel manager” agent delegating tasks (like currency conversion or activity planning) to specialized sub-agents using A2A for discovery and routing.

Sources:

• SK MCP Blog Post (Python): https://devblogs.microsoft.com/semantic-kernel/semantic-kernel-adds-model-context-protocol-mcp-support-for-python/

• SK A2A Blog Post (Python): https://devblogs.microsoft.com/semantic-kernel/integrating-semantic-kernel-python-with-googles-a2a-protocol/

• MCP Official Documentation: https://modelcontextprotocol.io/introduction

• Google A2A Repository (with SK sample): https://github.com/google/A2A

• SK Python MCP Samples: https://github.com/microsoft/semantic-kernel/tree/main/python/samples/concepts/mcp/

• SK Python MCP Demos: https://github.com/microsoft/semantic-kernel/tree/main/python/samples/demos/mcp_server/

Copilot can now help with Azure SQL

Microsoft have added a load of new Copilot functionality to the Azure Portal, to basically save you a Google search or two.

You can now prompt it to help you…

• Troubleshoot SQL Errors: Get help diagnosing common SQL errors (like 10928, 18456, 40613) with explanations and suggested fixes.

• Optimize Performance: Identify potential bottlenecks like storage or I/O limits and get recommendations.

• Simplify Configuration: Get guidance on choosing service tiers or constructing connection strings.

• Manage Security: Get assistance with Transparent Data Encryption (TDE) issues or data replication problems.

Now originally they planned to allow you to use Copilot to directly write database queries in the Query editor within the Azure Portal, but it looks like they’ve decided to push this back and keep it exclusive to a future SSMS release. Seemed pretty useful.

More info:

• Azure SQL Blog Announcement: https://techcommunity.microsoft.com/blog/azuresqlblog/announcing-general-availability-of-azure-sql-database-capabilities-for-microsoft/4403518

• Microsoft Copilot in Azure Overview: https://learn.microsoft.com/en-us/azure/copilot/overview

• Copilot in Azure with Azure SQL DB: https://aka.ms/sqlcopilot

• FAQ: https://aka.ms/sqlcopilot-faq

• Copilot in SSMS Session (SQL Conf 2025): https://learn.microsoft.com/en-us/shows/azure-developers-sql-conf-2025/a-developers-guide-to-using-copilot-in-ssms

Here is a video version of this post:

If there is anything you’d like to see me cover next week, send me a DM on Twitter/X at @edandersen. Cheers.

The most significant update is that the service is now open to everyone, and you don’t need special approval to access it. Previously, to gain access to Azure OpenAI Service, you had to fill a special form and get approval from Microsoft. This was exclusive to Microsoft’s partners. But now, anyone with an Azure subscription can access the service, which is great news.

We also finally now have access to the retrieval tool in the OpenAI Assistant API, named the “file search” tool. This tool allows the LLM to search for file information inside files, a feature that was not previously supported. Users in Azure were left with no other option but to use the slow code interpreter tool before now.

However, the file search documentation still lacks some source code examples, especially for C# and .NET. Although Python and REST calls are covered, I really wish Microsoft would include samples in C# and .NET in their docs by default.

I already have a project on my GitHub where I used the old Code Interpreter tool to use the Assistant API to query for information in a file. Now that File Search is supported, it was time to take another look at it and update it!

To start, we’ll change the SDK package that is used, switching it over to version two of this top-level nuget package, Azure.AI.OpenAI, which now seems to include all of the Assistant stuff.

<ItemGroup>
  <PackageReference Include="Azure.AI.OpenAI" Version="2.0.0-beta.2" />
</ItemGroup>

Next up, load up an AzureOpenAIClient and get an AssistantClient from it. You’ll need to ignore the OPENAI001 warning at the moment.

using Azure.AI.OpenAI;
using OpenAI.Assistants;

AzureOpenAIClient azureClient = new(
            new Uri("https://your-deployment-url.openai.azure.com/"),
            new Azure.AzureKeyCredential("your azure open ai api key"));

#pragma warning disable OPENAI001 // Type is for evaluation purposes only and is subject to change or removal in future updates. Suppress this diagnostic to proceed.

var client = azureClient.GetAssistantClient();

#pragma warning restore OPENAI001 // Type is for evaluation purposes only and is subject to change or removal in future updates. Suppress this diagnostic to proceed.

We’ll grab the filename from the command-line arguments that we pass in.

var filename = args[0];

We’ll create an assistant that will answer questions from a user about the provided file using the file search tool. The model name here is your deployment name on Azure OpenAI service.

var assistantCreationOptions = new AssistantCreationOptions
{
    Name = "File question answerer",
    Instructions = "Answer questions from the user about the provided file.",
    Tools = { ToolDefinition.CreateFileSearch() },
};

var assistant = await client.CreateAssistantAsync("gpt4-assistant2", assistantCreationOptions);

Next, we’ll upload the file and print its name to the console.

var fileUploadResponse = await azureClient.GetFileClient().UploadFileAsync(File.Open(filename, FileMode.Open), 
System.IO.Path.GetFileName(filename), OpenAI.Files.FileUploadPurpose.Assistants);
Console.WriteLine($"Uploaded file {fileUploadResponse.Value.Filename}");

We’ll ask the user to provide a question about the file.

Console.WriteLine("Ask a question about the file (empty response to quit):");
var question = Console.ReadLine();

var thread = await client.CreateThreadAsync();

Then we’ll enter a loop in which we’ll create a message with the user’s question and an attachment to the uploaded file. We’ll start a run and print the run’s updates to the console. You’ll notice we can now using the streaming API from an Assistant context, which means we can print tokens out as they are generated, something that wasn’t previously supported.

while (!string.IsNullOrWhiteSpace(question))
{
    var messageCreationOptions = new MessageCreationOptions();
    messageCreationOptions.Attachments.Add(new MessageCreationAttachment(fileUploadResponse.Value.Id, new List<ToolDefinition>() {ToolDefinition.CreateFileSearch()}));

    await client.CreateMessageAsync(thread, new List<MessageContent>() { MessageContent.FromText(question)}, messageCreationOptions);

    await foreach (StreamingUpdate streamingUpdate
            in client.CreateRunStreamingAsync(thread, assistant, new RunCreationOptions()))
        {
            if (streamingUpdate.UpdateKind == StreamingUpdateReason.RunCreated)
            {
                Console.WriteLine($"--- Run started! ---");
            }

            else if (streamingUpdate is MessageContentUpdate contentUpdate)
            {
                if (contentUpdate?.TextAnnotation?.InputFileId == fileUploadResponse.Value.Id)
                {
                    Console.Write(" (From: " + fileUploadResponse.Value.Filename + ")");
                } 
                else 
                {
                    Console.Write(contentUpdate?.Text);
                }
            } 
        }

    Console.WriteLine();
    Console.WriteLine("Your response: (leave empty to quit)");
    question = Console.ReadLine();

}

Finally, we’ll clean up the file and assistant before exiting the application.

Console.WriteLine("Cleaning up and exiting...");
await azureClient.GetFileClient().DeleteFileAsync(fileUploadResponse.Value.Id);
await client.DeleteThreadAsync(thread.Value.Id);
await client.DeleteAssistantAsync(assistant.Value.Id);

By running this application passing the path to a local file as the first parameter, you’ll get a nice console prompt where you can ask questions about the file.

For a video version of this post, take a look at the following:

Thanks for reading!

In less than a year, .NET Aspire has made it from a preview release all the way through to General Availability and its inclusion in Visual Studio. The marketing keeps saying that the important part of .NET Aspire is that it makes apps “cloud-native”, but that is only a fraction of the story – and in my opinion the least important part.

It is my opinion that .NET Aspire is an attempt to bring order to the chaos of the last decade of .NET software development. The most important quote on the documentation is the following:

.NET Aspire is an opinionated stack for building resilient, observable, and configurable cloud-native applications with .NET.

https://devblogs.microsoft.com/dotnet/introducing-dotnet-aspire-simplifying-cloud-native-development-with-dotnet-8/

Note their emphasis on opinionated and not cloud. The last time I’ve seen an effort this concerted to have an opinion on how software should be built was when ASP.NET MVC was released way back in 2009. Let me explain.

.NET Aspire out of the box

When you create a new template with .NET Aspire and launch the “AppHost” project, you get the following:

• A full dashboard listing all services in the project, by default an API and a Blazor (…) UI project

  • It should be noted that these auto-run, no more faffing with launch.json or “Multiple Startup projects” in VS

• Live console output from each running service

• Structured logs and traces powered by OpenTelemetry

• Process metrics (requests per second, CPU usage etc) for each service

• Integration with Docker Desktop or Podman if installed

This is such a massive stake in the ground for what the .NET Development team sees as “best practice” that it puts many open source utilities, projects and cottage industries of internal “frameworks” out of business.

Pre-Aspire times

Released in 2004, Ruby on Rails was taking off as the “cool” web development framework by the late 2000s. All Microsoft had to offer at the time was WebForms on .NET Framework, originally released in 2002.

Ruby on Rails was an MVC based framework promising that every application would be broadly similar, because it favoured “convention over configuration“. This meant that Controllers were in one place, Views were in one place, Models were in one place, and this was common across every project you would encounter.

The .NET team at the time in Microsoft needed to compete with this. WebForms, with its code behind, viewstate and other “hide how HTTP works” horrors was not cutting it. They probably had the internal data that all these cool new startups were all using Rails.

So ASP.NET MVC was born and version 1 was released in 2009, bringing an “opinionated” MVC framework to .NET for the first time. Like Rails, Controllers were where you expected them to be in every project you came across. It was even actually made open source, unlike WebForms.

.NET MVC was wildly popular in the .NET world and continued through to version 5 and then merged with its “Web API” cousin for .NET Core. For a period of time .NET was sane. You could go into a project and – assuming the architects had not gone crazy trying to create job security – find things where they were supposed to be. With .NET Core, the .NET team even finally created a “blessed” dependency injection framework so you didn’t have to argue over NInject, Autofac, Castle Windsor etc.

Where it started going “off the Rails”

The issues with convention over configuration are that

• You have to learn the conventions

• it is hard for an architect to “invent” any new patterns

• There is a bit of boilerplate required to get started

And this is where I believe things started taking a turn for the worse.

The mid 2010s saw the birth of .NET Core, and the original versions looked like we were going to have a clean break from WebForms and other .NET Framework bleakness.

However, for some people following patterns and architectural principles was just too hard – and to placate the WebForms crowd who had been left out of the cold with the release of .NET Core, Razor Pages were born.

Razor Pages promised the same rapid application development experience as WebForms. It even had code-behind like WebForms. At some point during this journey Blazor was invented, putting Razor Pages on steroids and adding even more layers of abstraction and drag’n’drop goodness. Need to know where your business logic goes? Who cares! Just whack it in the file alongside your UI code! Or maybe not! Its your chance to create your own software architecture!

Minimal API project templates also now truly allow your application to be unique, and you can invent any number of ways to get data on the screen. Roll your own fake controller system? Why not! Directly call the database in your GET handler? Cool! Use fastendpoints to er, bring a hybrid Controller/Mediatr CQRS system back? Lets go!

Towards a better future with .NET Aspire (?)

Which is why Aspire excites me.

Who remembers ELMAH? Well, now you don’t need it as its built in to the Aspire UI.

Who remembers MiniProfiler? An amazing add-on that was ported from Ruby to .NET that showed tracing directly in the UI of your app? Well, thats also now built into Aspire via OpenTelemetry.

Previously all of these amazing tools were expected to be developed by the open source community, for free, to make .NET a viable platform. Now Microsoft are building those tools directly into Visual Studio templates, forcing applications to standardise on ways of setting up logging, monitoring and service discovery around best practices decided by the .NET team (with probably a bit of community input). No more Bobs-homemade-logging-framework, no more Garys-custom-OpenTelemetry-sink. If an application is Aspire compatible it will be expected to meet certain standards.

And this means the team have finally brought an opinionated system back to .NET. This is a beautiful thing, but what is next for Aspire?

The menu on the left of the Aspire Dashboard could easily fit in some new tabs. How about:

• Database access, built in CRUD admin panel (maybe I should port CoreAdmin to it…)

• User management

• API browser/test console (like Swagger)

• Visitor analytics

I’m sure a healthy ecosystem of “plugins” will be developed.

Final thoughts

Believe it or not I am actually excited about where Aspire is going. A genuine out of the box value add from the team, finally some standardisation around common components, the dev team having an opinion again, and a return to the days where projects would follow known patterns. Anything that aims to improve the state of .NET apps “in the wild” gets a thumbs up from me.

The Drawbacks of Microservices

Typically, a microservices infrastructure involves splitting your application into smaller, independent services, each running in its own environment and possibly using different technologies. For example, a user service might handle all user-related operations, running in its own Docker container with separate monitoring, deployment, and API documentation. As your application grows, you could end up managing a plethora of services like event, post, subscription, and billing services, each with its own complexities. This fragmentation can quickly become a management nightmare, especially for smaller teams.

Now with real interest rates, the backlash against microservices and the associated complexity is getting real.

Microsoft Orleans: A Simplified Approach

Microsoft Orleans (re)introduces the actor model that simplifies the design and deployment of distributed systems. In Orleans, entities like users are represented as grains, which are essentially instances of C# classes that can be instantiated as needed. These grains are identified by a primary key (e.g., a user ID) and can live in the system’s memory, being activated or deactivated as required.

You could call it a “distributed modular monolith”, in that there is a single deployable unit (unless you want to get fancy) but certain parts are activated on certain load balanced servers as required.

Benefits of Using Orleans

• Reduced Boilerplate: Unlike microservices, which require extensive setup for each service (Docker files, API docs, etc.), Orleans grains share resources within the same deployment, minimizing the need for additional boilerplate.

• Built-in Caching: The grain storage pattern keeps frequently accessed data in memory, eliminating the need for a separate caching layer.

• Automatic Scalability: Grains are automatically distributed across the available servers in the cluster, ensuring efficient use of resources without manual configuration.

• Ease of Testing: Since grains are based on C# interfaces, they can be easily mocked for unit testing, simplifying the testing process compared to microservices.

• It’s F5-able! You can just run it locally. No docker compose. No minikube. It just works and behaves just like it will spread over 50 servers. Nice!

Real-World Use Cases

Orleans isn’t just a theoretical solution; it’s used in major Microsoft products like Xbox Live and Azure, proving its effectiveness at scale. Its adoption underscores the framework’s reliability and performance, making it an attractive option for developers looking for proven solutions.

This is the key differentiator between Orleans and other products that Microsoft pump out (see MAUI, Blazor etc) – they actually use it themselves for large production public facing systems!

A quick Orleans refactor

Consider the scenario where a traditional MVC application accesses a database using Entity Framework for user management. We’ll see how this approach can be refactored using Microsoft Orleans.

Traditional MVC Users Controller

In a typical MVC application, you might have a UsersController that interacts directly with an Entity Framework DbContext to perform CRUD operations on users. This is an Index action that loads a single user from the database.

public class UsersController : ApiController
{
    private readonly ApplicationDbContext _context;

    public UsersController(ApplicationDbContext context)
    {
        _context = context;
    }

    [HttpPost]
    public async Task<IActionResult> Create([FromForm] User user)
    {
        _context.Users.Add(user);
        await _context.SaveChangesAsync();
        return Ok();
    }

    [HttpGet]
    public async Task<IActionResult> Index(string id)
    {
        return Ok(await _context.Users.FindAsync(id));
    }
}

Refactoring with Orleans

With Orleans, you abstract user operations into a grain interface and implementation, removing direct database access from the controller and instead relying on Orleans to manage user information in Grain state.

Defining the User Grain Interface and Implementation

First, define an interface for the user grain operations:

public interface IUserGrain : IGrainWithStringKey
{
    Task<User> GetUserAsync();
    Task SetUserAsync(User user);
}

Then, implement the grain:

public class UserGrain : Grain, IUserGrain
{
    private readonly IPersistentState<User> _userState;

    public UserGrain(
        [PersistentState("user", "userStore")] IPersistentState<User> userState)
    {
        _userState = userState;
    }

    public Task<User> GetUserAsync()
    {
        return Task.FromResult(_userState.State);
    }

    public async Task SetUserAsync(User user)
    {
        _userState.State = user;
        await _userState.WriteStateAsync(); 
    }

}

Modifying the Controller to Use the Grain

Instead of directly accessing the database, the controller now interacts with the user grain:

public class UsersController : Controller
{
    private readonly IClusterClient _client;

    public UsersController(IClusterClient client)
    {
        _client = client;
    }

    [HttpPost]
    public async Task<IActionResult> Create([FromForm] User user)
    {
        var userGrain = _client.GetGrain<IUserGrain>(id);
        userGrain.SetUserAsync(user);
        return Ok();
    }

    [HttpGet]
    public async Task<IActionResult> Index(string id)
    {
        var userGrain = _client.GetGrain<IUserGrain>(id);
        var user = await userGrain.GetUserAsync();
        return View(user);
    }
}

This refactoring moves the saving and loading out of Entity Framework and into grain state – which will be persisted to your preferred backing data store. Of course, ADO.NET / MSSQL is supported but also lots of cloudy blob storage solutions. One major benefit is that the user information here is cached – if the user does not change between calls to the grain, and it has not been deactivated, the result is served from memory. That’s your Redis cache you can send off to pastures new too.

The team behind it

The strength of a development framework is not just in its technology but also in the community and leadership behind it. Microsoft Orleans benefits greatly from the expertise and dedication of individuals like Reuben Bond and Brady Gaster. Reuben is not just a senior developer but a central figure in the Orleans community. His active participation in the Orleans Discord channel, where he answers questions and provides guidance, is testament to his commitment to the project. You can actually ask him questions!

On the management side, Brady Gaster’s involvement brings a wealth of experience. Known for his significant contributions to the .NET world, Brady’s role in overseeing Orleans’ development ensures that the framework not only meets current developer needs but also anticipates future trends and challenges. The collaboration between these two industry veterans, along with the broader team and community, is a significant reason why Microsoft Orleans has emerged as a powerful and reliable solution.

In summary

.NET dev shops wanting to build distributed applications should take a look at Orleans before going down the garden path of microservices. By abstracting the complexities of distributed systems into manageable grains, Orleans allows developers to focus on building features rather than managing infrastructure.

For those interested in diving deeper into Microsoft Orleans, take a look at the docs on the Microsoft website, which is pleasantly well written.

I won’t go into detail of the specs as you can find proper tech specs elsewhere, but this thing is small, around the size of a credit card with its 3 inch screen. It also has the headphone jack, dual SIM card support and SD card slot of the Xperia. The 48 megapixel single camera lens is passable and I have real cameras I need to use more of anyway. It is a full upgrade from the Jelly 2, with the only downgrade being the lack of FeLiCa support so no osaifu-keitai or Suica supporting model for Japan this time around.

It sat in a box until last month when I found myself with screen times of four or five hours a day on my phone, a mahoosive Sony Xperia 1 V. This isn’t a “Digital Detox” but more of a “re-tooling” and I just wanted to use my phone less whilst still remaining a functional member of society.

Re-evaluating what I need my “daily driver” phone for

When putting apps back on the phone, I wanted to carefully think about what I actually need this thing in my pocket to be able to do. The purpose was to change my phone use from this constant mental tether to the information super highway into just a tool.

Tools required to function in society

• WhatsApp, Signal, LINE – IM

• Primary daily use bank account app to check balance and move money

• Authenticator for 2FA

• Personal and work email

• Google Maps

• Fitbit for tracking and for topping up Suica on Fitbit Charge 5

• Companion apps for my Sony cameras to pass GPS info for geotagging

• DiDi/Uber for transport

• PayPay for shops that have been “coerced” into to only accepting it

• YouTube Music for gym bangers

What has to go nowhere near this thing

• Games

• Web Browser

• Social Media

• Slack

• Discord

• Non-primary banking apps (can stay on the old phone in a drawer)

In the end I had less than 20 apps on the Jelly Star, compared to way over 100 on the Sony.

The Web Browser is the hardest app to live without, but it also was the primary cause of phone overuse. You can be out somewhere and modern society expects you to be able to any of the following activities at a moment’s notice:

• Scan a QR code to order food from a menu in a browser

• Sign up to something for a discount

• Reset a password

• Book an appointment

I wasn’t going to compromise on being able to function, so the solution I found was to keep Chrome on the device, don’t sign in, don’t install any adblockers (which would make the web tolerable) and keep the browser Disabled. Some Android apps will just randomly crash with no available browser (for in-app sign up or some form flows) so I do have to go and toggle Chrome back to being active occasionally. If I leave Chrome enabled in this state, even the BBC News website is full of scammy adverts and is basically unusable.

“But why not just delete all this stuff from your big phone?” I hear you say. The point of having a tiny annoying phone to use is that even if I was to give into a moment of weakness and install a game or SNS, the experience is so awful on this device that I don’t want to use it. Most apps optimised for engagement now expect you to have a large phablet sized 6 inch beautiful OLED screen.

The benefits after 4 weeks

It took a while but I feel more present. I can actually go out for lunch with people and talk to them without being distracted by a ridiculously large pocket computer in my pocket. I don’t feel compelled to suddenly google information to settle arguments.

The battery life has been fantastic since I barely use the thing. It only has a 2000mAh battery but the aggressive app freezing (which needs to be disabled in some cases) and reduced usage makes the phone last just as long as my Sony Xperia 1 V with a 5000mAh battery.

Instant messages from WhatsApp, Signal etc do not always have to be responded to straight away, and the tiny keyboard makes this annoying anyway. You can just respond on the desktop apps when you get back to your computer and getting into this habit feels quite healthy.

How to stay connected

There are still some cases where it is perfectly acceptable to use a device for extended periods of time without upsetting the people you are with. Such as

• Your train commute assuming you are sitting down

• a 2 hour Shinkansen journey

• Reading before bed

• Alone in a coffee shop

It turns out I had the perfect device for this – an iPad Mini with 5G. This is big enough that you cannot get it out in public for a bit of news perusal unless its really appropriate and you are by yourself. Whipping the iPad out at dinner with your family would be a quick way of getting a divorce!

The 48MP camera on the Jelly Star is acceptable for a Chinese 30,000 yen phone, and is fine for taking pictures of signs and expense receipts. You can get away with the odd family photo but you’ll need a proper camera. The smallest real camera I have that I can sort of carry in a pocket is the Sony ZV-E10 with its slightly rubbish kit lens. I’m looking at getting a smaller camera that is truly pocketable to go alongside this phone. If anyone happens to be reading this and has any suggestions for a good pocketable “Everyday Carry” camera please let me know in the comments 🙂

So, the experiment continues. Having a smart phone is not really optional today sadly unless you want to struggle and do extra planning before leaving the house compared to other people, but the negative affects appear to be able to be tamed without having to go completely off grid with a “dumb phone” like the Nokia Flip. I would recommend giving it a go if you want to use your phone as a tool and not have your phone use you.

I’ll keep going with this until I crack and go back to the big Sony phone. Until then I’m happy to answer any questions you have about the phone in the comments below. Thanks for reading!

Here is a video on the topic:

Incompatible NuGet packages

For example as of time of writing Amazon.Lambda.AspNetCoreServer doesn’t work with Minimal APIs. If you didn’t know that Amazon.Lambda.AspNetCoreServer.Hosting was what you needed for Minimal APIs, you’d be stuck without converting to Startup.cs.

Needing to return to .NET 5

Again, as of time of writing, AWS Elastic Beanstalk does not support .NET 6 on runtime based deployments. So if you have built half your app in Minimal API style you’ll need to change it to Startup.cs to use .NET 5.

It is different to everything else in your org

Minimal APIs introduce new training overhead for teams used to Startup.cs. Remember, some people are only just getting their heads around Startup.cs which was a big (and brilliant) change from Global.asax.

It doesn’t match documentation

Most documentation out there still has instructions for Startup.cs. Figuring out how to apply the instructions in a Minimal API Program.cs can be a headache.

If you want to convert to a Startup class, here are the empty Program.cs and Startup.cs classes that will be useful

Program.cs:

using Microsoft.AspNetCore;
using Microsoft.AspNetCore.Hosting;

public class Program
{
    public static void Main(string[] args)
    {
        var host = CreateWebHostBuilder(args).Build();
        host.Run();
    }

    public static IWebHostBuilder CreateWebHostBuilder(string[] args) =>
    WebHost.CreateDefaultBuilder(args).UseStartup<Startup>();
}

and Startup.cs:

using Microsoft.AspNetCore.Builder;
using Microsoft.AspNetCore.Hosting;
using Microsoft.Extensions.Configuration;
using Microsoft.Extensions.DependencyInjection;

public class Startup
{
    public Startup(IConfiguration configuration)
    {
        Configuration = configuration;
    }

    public IConfiguration Configuration { get; }

    public void ConfigureServices(IServiceCollection services)
    {

    }

    public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
    {

    }
}

Here is a video walking through how to do it:

Looking forward to using these!

First, you need to head to the Nuget Package explorer by right clicking on the Dependencies node of your project tree selecting “Manage NuGet packages…”. Search for and install Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation. Install it and it’s dependencies into your project.

Then head to Startup.cs. Find the line within ConfigureServices() that says “services.AddControllersWithViews()” and add “.AddRazorRuntimeCompilation()”. You won’t be able to add this line without first installing the previous NuGet package.

Now run your app. You will see that changing the contents of Razor .cshtml files and refreshing the page will cause the view to be updated with your new content, without having to stop and recompile.

YouTube demonstration video

I found a blog post by Bohdan Benetskyi from March 2020, but it was geared for MvvmCross and not Xamarin Forms Shell. Here is how to adapt it.

Introducing IBackButtonHandler to your Page

If you have existing pages you can add an interface to them and implement it, for example here is a page from my app with IBackButtonHandler added to the class:

  [XamlCompilation(XamlCompilationOptions.Compile)]
    public partial class PostListSummaryPage : ReactiveContentPage<PostSummaryListPageViewModel>, IBackButtonHandler
    {

This can then be implemented however you like, returning true if the back navigation should be aborted, for example:

public async Task<bool> HandleBackButton()
{
    if (await ShouldNotGoBack())
    {
        return true;
    }

    return false;
}

public async Task<bool> ShouldNotGoBack()
{
    var response = await this.DisplayActionSheet("Would you like to discard any unsaved changes to this post?", "No", "Yes, go back");

    return response == "No";
}

Once that is done next up is wiring up the back buttons.

Handling the Android OS back button

To handle the OS level back button you’ll need to add the following to MainActivity.cs:

public async override void OnBackPressed()
{
    var backButtonHandler = Shell.Current.CurrentPage as IBackButtonHandler;

    if (backButtonHandler == null)
    {
        base.OnBackPressed();
        return;
    }

    var backButtonHandled = await backButtonHandler.HandleBackButton();
    if (!backButtonHandled)
    {
        base.OnBackPressed();
    }
}

Lets step through this. First up, it attempts to cast the current Shell page as IBackButtonHandler. This means that only Pages that implement this interface will have any change of behaviour here. If the interface is not implemented, the base implementation of OnBackPressed() is called. If it is implemented, the HandleBackButton method is evaluated. If it returns true, the back navigation is cancelled. If false, the base implementation of OnBackPressed() is called, continuing the back navigation.

Handling the Shell back button

This is the button on the top left that shows when you are more than one level deep in the navigation stack. Handling this is less clean as it requires adding a call to Shell.SetBackButtonBehaviour in the constructor of each page that requires this. For example, add the following to the constructor of your page, after InitializeComponent():

Shell.SetBackButtonBehavior(this, new BackButtonBehavior()
{
    Command = new Command(async () => {

        var backButtonHandled = await this.HandleBackButton();
        if (!backButtonHandled)
        {
            await Navigation.PopAsync();
        }

    })
});

After that, you’l get a nice prompt pop up whenever you hit the OS back button or the shell navigation back button, but only on pages that implement IBackButtonHandler.

Walkthough video

If you would like a video walkthough of the above, check out this video:

In RDP 10 it turns out this can be massively improved by enabling a screen encoding based on AVC/H.264 video. By enabling the group policy “Prioritize H.264/AVC 444 graphics mode for Remote Desktop Connections” under Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Remote Session Environment, I was able to get a glorious 60fps, almost double what I was getting before.

There is also another group policy to use your GPU to do the encoding, “Configure H.264/AVC hardware encoding for Remote Desktop connections”. Turn this on and you can see your GPU in task manager doing a little bit of work to encode the video, potentially saving the CPU from some effort. However in my testing I actually saw slightly worse performance in this mode, as you can see from this video:

I do wonder why this option is buried in Group Policy and not more user accessible – it appears to be enabled by default in cloud hosted environments with virtual GPUs (such as the Azure GPU instances). I also wonder if you can actually game using it?

Pre-requisites to register an app with Google

At this point in time you’ll need to do the following before you can register a Public app:

•  Create a project in GCP via the Google Developer Console

•  Verify a domain via the Google Search Console. To do this you will need access to your nameserver and DNS records in order to copy and paste a TXT record. Access this here.

•  Know the SHA-1 fingerprint of the key that will be used to sign your package

Getting the SHA-1 fingerprint used to sign a locally deployed debug Xamarin Forms app

You’ll need to do this:

•  In Visual Studio, go to Tools > Android > Android Adb Command Prompt

•  Navigate to C:\Users\{username}\AppData\Local\Xamarin\Mono for Android

Run the command

keytool -keystore debug.keystore -list -v

And when prompted enter the keystore password “android”.

You’ll see a result like this:

The SHA1 value is what you need.

Registering the application

You should have everything you need now. Go to Credentials in the GCP panel and create the OAuth consent screen. Fill in the details (you’ll need the verified domain you created earlier).

Then you can create an OAuth 2.0 Client ID. Select “Android” as the platform and enter the package name from AndroidManifest.xml and the SHA-1 fingerprint you figured out earlier. You’ll see something like the below:

Adding the code

The approach I have taken is to create a class in the main Android project to encapsulate everything, rather than putting the logic inside the Mobile/PCL project. This is because the Android version needs references to Activities and other Android-specific concepts to work effectively. It’s not just a case of adding Xamarin.Auth and calling a method unfortunately.

Using Xamarin Forms dependency injection I can refer to and call this class within the portable Mobile project when I need an access token from the API.

The token reader class

There are some nuget dependencies you’ll need for this – the “Google.Apis.Auth” libraries for the TokenResponse class (although you can probably remove the dependency from the below code if you’d like), “Xamarin.Auth”, “Xamarin.Auth.XamarinForms” and “Plugin.CurrentActivity”. The last one allows code outside of an Activity to get access to the current Activity.

    public class GoogleAccessTokenReader : IGoogleAccessTokenReader
    {
        public static readonly string[] GoogleAPIScopes =
        {
            DriveService.Scope.DriveFile,
            BloggerService.Scope.Blogger
        };

        public static TokenResponse Token { get; set; }

        public static OAuth2Authenticator Auth;

        public async Task<TokenResponse> GetOrNullAsync()
        {
            if (Auth == null)
            {
                Auth = new OAuth2Authenticator(
                "your-client-id",
                string.Empty,
                String.Join(" ", GoogleAPIScopes),
                new Uri("//accounts.google.com/o/oauth2/v2/auth"),
                new Uri("com.yourpackageid:/oauth2redirect"),
                new Uri("//www.googleapis.com/oauth2/v4/token"),
                isUsingNativeUI: true);

                Auth.Completed += OnAuthenticationCompleted;
            }

            if (Token != null) return Token;


            Xamarin.Auth.CustomTabsConfiguration.CustomTabsClosingMessage = null;

            var intent = Auth.GetUI(CrossCurrentActivity.Current.AppContext);

            CrossCurrentActivity.Current.Activity.StartActivity(intent);

            while(!Auth.HasCompleted)
            {
                await Task.Delay(500);
            }

            return Token;
        }

        private void OnAuthenticationCompleted(object sender, AuthenticatorCompletedEventArgs e)
        {
            if (e.IsAuthenticated)
            {
                Token = new TokenResponse()
                {
                    AccessToken = e.Account.Properties["access_token"],
                    TokenType = e.Account.Properties["token_type"],
                    Scope = e.Account.Properties["scope"],
                    ExpiresInSeconds = int.Parse(e.Account.Properties["expires_in"]),
                    RefreshToken = e.Account.Properties["refresh_token"]
                };

             }
         }

    }

Add the following dependency injection declaration to the namespace:

[assembly: Dependency(typeof(NetWriter.Mobile.Droid.GoogleAccessTokenReader))]

Where NetWriter.Mobile.Droid should be replaced with your namespace.

You can use this interface too as IGoogleAccessTokenReader (or change depending on your needs):

using Google.Apis.Auth.OAuth2;
using Google.Apis.Auth.OAuth2.Responses;
using System;
using System.Collections.Generic;
using System.Text;
using System.Threading.Tasks;

namespace BlogWriter.Shared.NetStandard.Interfaces
{
    public interface IGoogleAccessTokenReader
    {
        Task<TokenResponse> GetOrNullAsync();
    }
}

Add the activity that receives the response

Somewhere in your main Android app you should add the following:

 [Activity(Label = "GoogleAuthInterceptor")]
    [IntentFilter(actions: new[] { Intent.ActionView },
              Categories = new[] { Intent.CategoryDefault, Intent.CategoryBrowsable },
              DataSchemes = new[]
              {
                  "com.yourpackageid"
              },
              DataPaths = new[]
              {
                   "/oauth2redirect"
              })]
    public class GoogleAuthInterceptor : Activity
    {
        protected override void OnCreate(Bundle savedInstanceState)
        {
            base.OnCreate(savedInstanceState);

            Android.Net.Uri uri_android = Intent.Data;

            var uri_netfx = new Uri(uri_android.ToString());

            GoogleAccessTokenReader.Auth?.OnPageLoading(uri_netfx);

            var intent = new Intent(this, typeof(MainActivity));
            intent.SetFlags(ActivityFlags.ClearTop | ActivityFlags.SingleTop);
            StartActivity(intent);

            Finish();
        }
    }

The last three lines before Finish() are really important as they actually make the Google login window go away after logging in. if you don’t add them it will stay there and the user will need to manually close the window.

Retrieving the token from within your app

Using the Xamarin Forms dependency injection system, you can get an instance of the token reader like:

var reader = DependencyService.Get<IGoogleAccessTokenReader>();
var token = await reader.GetOrNullAsync();

Coming soon

Refresh tokens, remembering the login and other stuff. Oh my!

Demo video

If you want a walkthough of doing this, you can watch the following video:

Create a property to bind to

ViewModels and how they bind to your UI are out of scope for this post (as you’ll have already got this far). However, if you add a property to your view model like this:

        public string VersionString 
        { 
            get
            {
                return "hello";
            } 
        }

We can use this to test the binding before updating to the actual version number later.

Bind to it using UWP

For UWP you’ll need to use the TextBlock control and bind the Text property:

<TextBlock Text="{Binding VersionString}"></TextBlock>

Bind to it in Xamarin Forms

Xamarin Forms has a slightly different flavour, so you’ll need to use the Label control:

<Label Text="{Binding VersionString}"></Label>

Check the UI

You’ll see the following in your app:

Updating the binding to show the version number

Because getting the version number differs by platform, you should use the super awesome Xamarin Essentials library.

Add nuget package to your Mobile class library and your UWP app following the documentation.

Then add the following using statement to the top of your ViewModel:

using Xamarin.Essentials;

And update your property code:

        public string VersionString 
        { 
            get
            {
                return "Version " + AppInfo.VersionString;
            } 
        }

That’s it! Xamarin Essentials handles the cross platform bits.

Confirm the version number is displayed 

Relaunch your UWP app and you’ll see:

Launch the Xamarin app and you’ll see:

These values are pulled from Package.appxmanifest and AndroidManifest.xml respectively.

Demo video

Here is a nice YouTube Style™ video demo of the above:

CoreAdmin adds a nice set of CRUD screens to your .NET Core web app in one line of code!

Adding CoreAdmin to your app

Given a typical Startup.cs file, you will have a ConfigureServices method. You need to add the line services.AddCoreAdmin() somewhere near the bottom (at least after you register your Entity Framework DbContexts).

Then when you visit your site with /coreadmin on the end of the URL, you’ll see this:

On the left you can see your database tables (these are the DBSets in your DbContexts). Click one and you get:

From here you can Create new entities, Delete and Edit them. Full searching, sorting, filtering etc are also supported.

There are a few limitations on data types and primary keys (for example, entities with composite primary keys are not supported for editing or deletion yet) but this should be sufficient for basic quick and dirty editing of entities.

How to get it

CoreAdmin on Github

CoreAdmin on NuGet

Simply install the nuget package “CoreAdmin” and you are good to go!  

Or watch a demo!

Here is a YouTube Style video demo.