Category Archives: microsoft

GitHub reliability and scalability: a consequence of AI and too much for free

GitHub’s CTO Vlad Fedorov has posted apologetically about the 17th August outage which, he said, “lasted 7 hours and 47 minutes. It disrupted github.com, authentication, GitHub Actions, APIs, pull requests, issues, and Copilot, affecting developers and organizations around the world.”

As if that is not bad enough, Fedorov also apologised for a failure of Actions on August 6th; and GitHub users will be aware of other incidents over the last few months that have tarnished the company’s reputation as well as being costly for its customers.

GitHub is owned by Microsoft and there is a narrative that says: under Microsoft GitHub has lost its best engineers and is now suffering from that as well as issues with the Azure platform.

There may be something in that, but there are more obvious reasons for GitHub’s difficulties. Specifically, Fedorov states that “since April, monthly commits have grown from 1.4 billion to 2.9 billion.”

That is a rapid growth in demand for a platform that was already under stress. Agentic AI appears to be a large part of the reason. Pull requests and requests are no longer generated mainly by humans, but are now programmatic and therefore created more quickly. In addition, AI-driven development means that it is no longer necessary to be a developer in order to create software projects; more people are creating more software with AI assistance.

GitHub has long had an amazing free offer. Take a look: free plans include unlimited public or private repositories as well as 2,000 CI/CD minutes every month, or unlimited for public repositories. For just $4.00 per month those limits increase. Competitors such as GitLab have reduced their free offer but GitHub has not.

GitHub’s generous free plan

GitHub is Microsoft and can afford it, right? True but free (or too cheap) has a hidden cost, if scaling problems impact paying customers, as has happened.

A way of managing this is to run isolated platforms within GitHub such that an issue affecting some users does not automatically impact all users. It appears that GitHub’s architecture prevents this at the moment.

Part of the answer, as Fedorov discusses, is to improve and expand GitHub’s scalability. A post in April describes this work and includes the comment that “we started working on path to multi cloud,” meaning that Microsoft is willing to pay competitor cloud companies in order to fix these issues.

It seems to me though that Microsoft/GitHub also need to restrain agentic AI by means of quotas and higher prices, in the interests of maintaining the stability of the platform. If that also means reducing the free offer that is understandable; better to have a reliable platform than a free one. Docker, for example, went through this kind of transition, though in that case it was a matter of financial necessity.

In the meantime Cursor (now part of SpaceX) has introduced Origin, now in public beta as a “git forge for storing and sharing code”, which Vicent Martí described in technical detail as Git at any scale. Marti was formerly at Planetscale and before that, GitHub.

The technology is fascinating, but I suspect Cursor also has in mind not to replicate GitHub’s mistake in underpricing its platform.

Linux on the desktop: growing, but not by as much as some claim

My attention was caught by the claim that Linux desktop use “surged to 22% on one workday.”

Unfortunately the claim does not stand up to scrutiny. The figures are drawn from Cloudflare data and based on North America only. The 22% is there but only at 9:00 UTC, which is 4:00am on the east coast and 1:00am on the west coast, or in other words, when most of the USA is asleep. At 15:00 UTC on the same day, Linux share was down to 6%.

Figures showing Linux share of 22% in North America - but only when most people are asleep
Figures showing Linux share of 22% in North America – but only when most people are asleep

If you set Cloudflare to show global figures, they are more even, with Linux desktop usage tending to peak at around 7%. Windows remains dominant.

I agree though with reporter Steven Vaughan-Nichols that Microsoft has damaged Windows with intrusive advertising and other user-hostile moves, such as the wrecking of the Start menu, the central position for the taskbar, and the confusing repositioning of key options like Copy on the right-click menu in File Explorer.

Almost whenever I touch a Windows 11 machine on behalf of another person, I offer to move the taskbar back to left alignment, and so far every single person has preferred it that way. There’s a good reason: the left corner is easier to hit with the mouse pointer. The central position was a victory for cosmetics over usablity.

I digress though. Today it looks unlikely that Windows on the desktop will be displaced by Linux; however what is more important is the desktop computing continues to be displaced by mobile and web. The notion of a home PC died long ago, other than for gaming.

My bank is “improving” its web site for online banking, in fact making it worse for desktop users. It justifies this by saying it will be better on mobiles. It is annoying but may be the right thing from the bank’s perspective.

In my own area, software development, desktop PCs remain more suitable than any other form factor, though I confess to using a Mac most of the time now (Windows 11 was my break point). On Windows, WSL (Windows subsystem for Linux) has become near-essential.

I also still use Word, Excel and Outlook so Microsoft continues to get money from me.

First steps with MAUI: some friction

I am evaluating Microsoft’s MAUI (Multi-platform app UI) for use on a cross-platform project. I mainly develop on a Mac with Visual Studio Code.

Setup for MAUI development is well explained here though getting everything in place for Mac Catalyst, iOS and Android is tedious. There is a tricky issue related to Apple’s Xcode, needed for MAUI for the Apple targets. Apple’s recommendation is that you install Xcode from the App Store. As you would expect, it updates quite frequently and always when there is a new version of macOS. The version on my machine is therefore 26.6. After installing MAUI for .NET 10 I got an error when trying to build, stating that I had the wrong version (mine was too new).

The workaround for this is either to install multiple versions of Xcode, which is fiddly, or to set ValidateXcodeVersion to false in the .csproj project file.

As it turns out, there is another fix. The .NET for iOS SDK (used by MAUI) was updated last month to require Xcode 26.6. Note: require, not support. Each version of the SDK requires one and only one version of Xcode, and there is a lag between Apple releasing a new version, and Microsoft updating its SDKs.

My instinct is to set ValidateXcodeVersion false during development and to watch out for strange errors that might be fixed for a production build, using the correct Xcode version.

Microsoft’s MAUI SDK engineering lead said:

Updates can include different things that amount to varying levels of work. Sometimes there’s api changes in the SDKs Xcode ships that we need to account for, sometimes they change Cli tools or break things in other ways. Depending on the changes it can be a little bit of work or a lot. 

Lately minor version updates to Xcode tend to be somewhat compatible with existing MAUI (Mac/ios) workloads and you can technically force trying to use it with the right build settings, but we generally advise not installing Xcode from the App Store so that it isn’t silently updated and you can install updates when you know they’ll be supported by MAUI instead.

This is friction, though it comes with the cross-platform territory. Note that Apple insists on building with the latest Xcode for store submission.

With that out of the say, I started building an experimental app. This is not Windows and conceptually one should think of the app UI as a single page, mobile app style, even if developing for Windows and Mac Catalyst. I decided to use a Tab Bar for navigation, but ran into an issue: when debugging the app for Mac Catalyst, the Tab Bar did not appear.

I thought this was something I was doing wrong, even though it was a simple and basic case. Then after digging a bit I discovered that it was a bug, that I was not the first to hit it, and that it was fixed with a workaround late last year.

The solution is to run: dotnet workload update from the command line to get the latest version.

Both issues are a reminder of how tricksy cross-platform development can be, particularly for frameworks like MAUI which use native widgets rather then drawing them from scratch like Flutter or Avalonia UI.

The solution, it seems to me, is to keep the user interface simple.

Running Visual Studio 2008 in Windows 11

One thing Microsoft is generally good about is keeping old applications running. Applications built with Visual Basic 6.0 (first released in 1998) still run well (in most cases) on the latest Windows.

I maintain an application which is not quite that old, but which was built with Visual Studio 2008 and .NET Framework 2.0. It still runs but needs modernizing and taking cross-platform.

I tried opening the project in Visual Studio 2026 but the automatic project conversion failed and it was proving difficult to fix up. Maybe it would be easier to keep it as-is and import it piecemeal to a new project, converting the database from Access MDB to SQLite along the way.

To this end, I decided to install Visual Studio 2008 on Windows 11. One can still download the trial from Microsoft as this Stack Overflow thread discusses, and upgrade to full if you have a valid key. I had to disable Windows 11 Smart App Control in order to mount the .iso files.

I installed both VS 2008 and the SP1 patch, as well as the MSDN library. Remarkably everything worked smoothly, with the exception of SQL Server 2005 (installed by default) which Windows warns will not work correctly.

My project loads and runs perfectly and the old Visual Studio is delightfully responsive to use.

The presence of local help is nostalgic:

One of the first things I did was to write code to export the MDB to SQLite, an important step forward in the modernization journey, and the task was completed in less than a day.

Getting started with Azure Artifact Signing

Signing applications is a requirement for deploying a desktop or mobile application and can be fiddly. Microsoft’s Azure Artifact Signing always looked to me like a good solution in that the pricing is reasonable at $9.99 per month for up to 5,000 signings, and it is run by Microsoft so one would think that the certificates will be satisfactory for Windows users.

This week I got started with the service. Microsoft has a handy quickstart guide and the first thing to note is that availability is limited to USA and Canada for individual developers, or USA, Canada, EU and UK for organizations. Luckily I work for a small UK limited company so qualify as an organization.

I also noted that a pay as you go Azure subscription is required; if you have a sponsored subscription that will not work.

The first step is to create an Artifact Signing Account. Billing starts from when this account is created, even if you are unsuccessful in obtaining a signing certificate. Should this be the case, make sure to delete the account.

Next, check the roles assigned to the user that will operate the code signing. There are two: Artifact Signing Identity Verifier and Artifact Signing Certificate Profile Signer. I assigned them both to my Entra ID user.

Now there are two steps to obtaining a certificate profile. The first is Identity Validation. In my case this is for an organization; you will need a DUNS number, two valid email addresses, a functioning web site, and the first and last name of the individual that will use the service. The organization address should match the one recorded at Companies House, even if day to day work is done elsewhere.

The organization identity verification automatically progresses to individual identity verification. In my case this was done by a company called AU10TIX and I was able to use a UK driving licence.

Next I hit what looked like a roadblock. I received an email asking me to verify my email address; however clicking the link got me a web page stating “the request is blocked” and “service unavailable”. Thinking that perhaps the service was unavailable, I tried several times and on different networks. I am not the first to experience this. I was on the point of raising a support case when I got a further email advising that validation was complete.

Once identity validation is complete you can create a certificate profile. The type I need is called Public Trust. I had several mysterious failures with uninformative errors; I suspect this might be to do with non-unique profile names but no idea really. Again I was on the point of contacting support when I tried a new profile name and it worked.

The quickstart guide ends at this point and the next document you need is the one on setting up signing integrations. You will need a recent Windows SDK including SignTool.exe, the .NET 8.0 runtime, and the Azure Artifact Signing client tools, if like me you want to sign a Windows executable.

Then you need to create a JSON file traditionally called metadata.json, and a command to sign the file. The command will be lengthy so fire up Notepad or similar and put it in a .cmd file or similar. You need to discover the location of SignTool and the location of Azure.CodeSigning.Dlib.dll and note that there are different x64 and x86 versions.

The command includes a timestamp without which the code signing is useless as the certificate has a lifetime of just three days.

I carefully assembled the command and I am happy to report that it worked first time.

Output from code signing command

So far so good. The whole process is somewhat intricate but I am hoping this will prove a good solution for Windows.

No Mono in Microsoft’s cross-platform MAUI framework on .NET 11 – and a quick hands-on

Microsoft has released preview 6 of .NET 11, for which release is expected in November, including a big change to MAUI (Multi-platform App UI): it now runs only on .NET Core, rather than the Mono runtime.

Principal product manager David Ortinau reports that “your app builds and runs on CoreCLR, the same runtime behind ASP.NET Core, your cloud services, and desktop .NET.”

According to Ortinau, performance is generally faster than Mono on iOS and Mac Catalyst. The implication is that it is slower on Android, though he does say that it is within 10% on startup and app size. Selecting Mono is no longer an option, and the only use of Mono in .NET 11 is for Blazor WebAssembly.

There is a key remark in Ortinau’s post. “We have worked closely with first party .NET MAUI apps validating our progress, and have received feedback from several others,” he says. The question developers may ask: what first party .NET MAUI apps? Microsoft does not use MAUI for its well-known cross-platform apps such as Teams or Office. In 2023, the company said it uses MAUI for its 365 admin, Azure admin and Store Commerce apps, though I do not know if this is still the case.

Slide from .NET Conf 2023 showing some limited use of MAUI at Microsoft

Developers would have more confidence in MAUI, both for its quality and its long-term future, if Microsoft itself made more use of it.

That said, the company does seem to be putting substantial effort into MAUI for .NET 11. Along with the CoreCLR work there are other updates in this preview. Microsoft states that the focus in .NET 11 is “to improve product quality” and this is something developers will be happy about; in some cases a statement like this might imply neglect but for MAUI it is exactly what is needed.

I have a demo MAUI project and decided to upgrade it to the new preview, working with Visual Studio Code on a Mac. It was not as easy as I had hoped. The process involved not only updating the target framework, but also the minimum versions of Android, iOS and Mac Catalyst. Then the Android SDK had to be updated, with an annoyance related to the recommended:

dotnet build -t:InstallAndroidDependencies -f net11.0-android “-p:AndroidSdkDirectory=[your path to the Android SDKs]”

The command failed with an error about the Android SDK licenses not being accepted. The fix is to set an environment variable:

export AcceptAndroidSDKLicenses=True

and then it works, though I’m not sure how this satisfies the lawyers. I also had an error where

builder.Logging.AddDebug();

could not find the AddDebug method; the fix was to add a package reference to Microsoft.Extensions.Logging.Debug to the .csproj file.

With all that done, the “Start debugging” command is not working for me in VS Code. I get a message that the “configured debug type ‘coreclr_mobile’ is not supported, and an instruction to install coreclr_mobile Extension; clicking this button gets me “no extensions found.” Update – this was resolved after updating both the C# and C# Dev Kit extensions to pre-release versions (.NET MAUI was already pre-release).

However, dotnet run from the command line works:

Demo of MAUI using .NET 11 Preview 6 on a Mac

I plan to do some more experimentation; note that this is a preview of .NET so some friction is expected.

JetBrains Resharper for Visual Studio Code adds C# debugging support

One of the oddities of Microsoft’s Visual Studio Code is that it is free to use for almost anything other than the company’s own .NET platform. That is, there is nothing to stop developers from coding in C# with VS Code and using the .net command-line tools without paying Microsoft for a license; but the official C# Dev Kit extension requires a license for teams of 6 developers or more:

For personal, academic, and open-source projects, C# Dev Kit can be used at no cost. For commercial purposes, teams of up to 5 can also use the C# Dev Kit at no cost. For 6+ developers, those users will need a Visual Studio Professional (or higher) subscription.

In addition, there are licensing restrictions on Microsoft’s .NET debugger which impact VS Code forks:

The C# extension for Visual Studio Code includes the Microsoft .NET Core Debugger (vsdbg). Unlike VS Code, and most other parts of the .NET Core ecosystem, vsdbg is not an open source product but rather is a proprietary part of Visual Studio. It is licensed to work only with IDEs from Microsoft — Visual Studio Code, Visual Studio, or Visual Studio for Mac.

JetBrains has now introduced C# debugging support for the ReSharper VS Code extension, which means there is now another high quality option for developers who either prefer not to use the C# Dev Kit, or are using a VS Code fork such as AWS Kiro, Cursor, Windsurf or Google Antigravity, for which the official .NET debugger is not licensed.

ReSharper is free for non-commercial use, or costs £119.00 ($149.00) per year for an individual or £295.00 ($389.00) per year for developers working for an organization. The cheapest standalone Visual Studio Professional plan is currently $540.00 per year, though some developers will get it bundled with other plans.

Leaving aside licensing and cost considerations, how does ReSharper compare to C# DevKit and the Microsoft .NET debugger? I have yet to use ReSharper so do not have a personal opinion; but will note that Microsoft’s recent change which removed the Solution Explorer is unpopular.

Finally, my personal view is that Microsoft has more to gain by making .NET and its tooling fully open, than by playing games with licensing restrictions in an effort to keep developers hooked to Visual Studio or VS Code.

TypeScript 7 is done

Principal product manager Daniel Rosenwasser reports that TypeScript 7 is now generally available – a big release, since this is the first to have the native port of the TypeScript compiler built in Go. Rosenwasser claims “speedups between 8x and 12x on full builds.”

There is a snag. Although TypeScript 7 is production-ready, it has no API; that will not come until TypeScript 7.1. It may come as a surprise to you that TypeScript has an API; it is not something highlighted in the TypeScript docs. You will find it covered in the official Wiki where there is an article on using the compiler API dated October 2023 and advising that “this is not yet a stable API.”

Despite the compiler API being somewhat obscure, Rosenwasser says this means that “workflows that use Vue, MDX, Astro, Svelte, and others will likely not yet be able to leverage TypeScript 7. Similarly, specialized type-checking within templates like Angular will also likely not use TypeScript 7.” That is a significant blocker to adoption.

The dedicated TypeScript 7/0 extension for Visual Studio Cdde

Users of Visual Studio Code should install the dedicated TypeScript 7.0 extension which already has enthusiastic reviews. “Saves us lots of time in CI/CD. The difference in speed is huge!” said one.

Personally I now use TypeScript rather than JavaScript almost exclusively, when targeting browser scripting, and will endeavour to switch to 7.0 immediately. I would much rather have the compiler find errors, than have them turn up in production.

Avalonia UI vs Microsoft’s .NET MAUI

What framework to choose for a cross-platform .NET GUI application continues to be awkward, with multiple good-ish options but no obvious first choice.

The three leading contenders are Microsoft’s MAUI (multi-platform app UI), third-party Avalonia UI, and third-party Uno Platform.

Joseph Tomkinson, head of software engineering at the British Heart Foundation, has an excellent post on the pros and cons of MAUI vs Avalonia UI, noting the fundamental difference that MAUI wraps native controls while Avalonia UI does all its own rendering. Tomkinson argues that MAUI has stronger mobile support (since this has only come recently to Avalonia) but that Avalonia has advantages in consistency, desktop performance, and Linux support.

A concern with Avalonia UI has been the drift towards important features becoming commercial-only, not unreasonable but a barrier to adoption for some developers. That has improved though since a sponsor appeared to fund Avalonia open-source development. CEO Mike James (formerly at Xamarin and then Microsoft) has posted about the difference this has made.

According to James, the Avalonia UI team has more than doubled, to 20 people, and now includes a QA lead. He says usage is growing:

“In the whole of 2025, Avalonia projects were built over 122 million times. In the first six months of 2026 alone, that figure has already passed 410 million.”

I am not sure exactly what this metric is counting – telemetry every time a developer builds a project? – but presuming it is like with like, that is impressive.

On the MAUI side though, one thing Tomkinson notes is that third-party components are more widely available, because it is an official Microsoft framework, and that quality is much better now than it was early on.

The BigCorp factor is not entirely in MAUI’s favour though. Microsoft might change direction and decide MAUI is no longer important, particularly as its own internal usage of the framework still seems minimal.

I am inclined to try building an example project in both frameworks to get my own feel for which would work best.

Microsoft authenticator cannot be backed up for Microsoft or Entra ID accounts

Multi-factor authentication (MFA) improves on username/password authentication by requiring the user to have a second proof of identity, traditionally “something you have” as well as “something you know.” In the Microsoft ecosystem MFA is typically implemented using an app called Microsoft Authenticator which generates one-time passwords (codes), used in addition to a password to sign in, or passwordless authentication where a request is sent to the authenticator app. The user enters a number displayed by the service they are signing into.

What happens though if you lose or replace your phone (iPhone or Android) that has the authenticator app on it? Microsoft has a post explaining how to restore account credentials from Microsoft Authenticator. The instructions differ for iOS and Android. They work for any codes you have set up in Authenticator for third-party accounts where you have configured MFA with the app.

One should pay attention though to the paragraph entitled: what account information is restored in Authenticator. In particular, for Microsoft personal accounts:

If the account also provides passwordless sign-in, then only the account name is backed up. When you restore, you will need to sign in again.

and for Work or school accounts, also known as Entra ID:

Only the account name is restored. When you restore, you will need to sign in again.

What does it mean, “you will need to sign in again?” How will you do this if you have lost access to the Authenticator which you backed up and restored?

The answer depends on whether any other authentication methods have been set up for the account. When the authenticator method fails, you can tap “Sign in another way” or “I can’t use my Microsoft Authenticator app right now”. If you have a phone number set up, it can send a code there instead (often by WhatsApp rather than SMS).

If you don’t have another authentication method set up, you cannot sign in. Contact your administrator.

You are the administrator? If you are the only global administrator for the Entra ID tenancy, you will have to call Microsoft’s Data Protection helpline and hope that you can prove your identity sufficiently that you can sign back in.

See here for an official response to this problem:

Therefore, if you are the only administrator in your organization, then you need to involve Microsoft data protection team. Please try to find the related hotline number to call the frontline let them raise a ticket for you: Customer service phone numbers – Microsoft Support 

It seems odd to me that Microsoft provides the ability to backup and restore all the Authenticator accounts except the ones it provides itself. And that when users register for MFA they are not able to to get recovery codes for that account.