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.
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.
Although I make mistakes when I write, it is an activity that comes easily to me. Sometimes it is difficult: finding the best title, opening paragraph, closing paragraph, how to express a thought with the right nuance; all these things can be hard. If I know what I want to say though, the words come naturally and I have never felt the need for AI assistance.
Nevertheless, AI can generate content, lots of it, and on the surface it is pretty good. Give it a task like, for example, writing a letter to a local politician expressing concern about a dangerous pedestrian crossing, it may well do the job quicker and better than the average person – better, that is, in terms of grammatical correctness, smooth writing style, and staying on topic.
AI can even write a novel; but publishers are wary. The topic is in the news because, apparently, a hot new novel entitled Call me, I’ll hide the body, sold according to “what sources said was a $2.4 million deal for the novel and a follow-up,” has been withdrawn by a foreign rights agent because of suspicion that AI was used “as a resource in the writing or editorial process.”
The use of AI here is not so much a problem of quality, but rather of copyright. Much of what we call artificial intelligence is based on searching and synthesising content harvested from multiple sources and an AI-generated novel might include text taken from existing works.
That said, if this novel was in part AI-generated but was nevertheless considered to have worldwide sales potential to merit a multi-million dollar advance, that is an impressive win for AI, even if the deal has now turned sour.
If I felt so inclined, I could instruct Chat GPT or similar to write a 500 word article on software development every morning and post it to this blog. I have just tried it; I will not bore you with the full results but in a few seconds I got a piece entitled AI coding moves beyond autocomplete: why GitHub’s latest enterprise push matters.
The AI-generated article looks OK on the surface but an editor would soon find defects. The fact that AI coding has moved beyond autocomplete is ancient history. The piece summarises some recent GitHub announcements but without any critique of how well the company is keeping up with the competition, or whether there are gaps between what it claims and what it has achieved, or what opinions practitioners and analysts have of GitHub’s latest AI features.
One must acknowledge though that regurgitating company announcements as news pieces is not only done by AI. Journalists do this as well sometimes; and if you are a journalist tasked with posting, for example, five pieces a day, this is hard to avoid, there being no time for thoughtful and well-researched analysis.
What if I worked on the Chat GPT output, submitted further prompts to ask for refinements, followed up the sources, added the results of my own research? Could it then merit publication?
It is not a path I want to travel, but perhaps it could.
Like many of us, I often consult reviews of restaurants and hotels before making a booking, and read online reviews of products before making a purchase. It is easy to tell which reviews are fake, being either disguised advertising or meaningless repetition of the official description; and which are based on actual experience of visiting the premises or using the product.
AI can easily create a fake review, but can never write a real one. The best it can do is to summarise and copy the reviews of others.
It is not easy for professional writers. First Google uses AI to borrow our content and show it in search results so that users do not visit the sites which monetise our work. And now AI creates complete works that seem almost like human writing. The key word though is “seem”. Much of the content is illusory and does not bear examination. It does not describe experiences or analyse facts or convey emotion.
For these reasons I consider that human writers have a reasonable moat to defend against AI replacement.
Vercel has previewed Scriptc on GitHub, a native compiler for TypeScript which is open source under the Apache 2 license.
Scriptc takes TypeScript code as input and outputs a native code executable, along with an embedded JavaScript engine if needed, using the existing QuickJS ng project. The JavaScript engine is needed if there is code included that cannot be statically compiled, including JavaScript code, such as npm dependencies, or code typed as “any” in TypeScript.
Scriptc runs on Apple Silicon and uses cross-compilation to target Linux and Windows. The project claims some big improvements in performance: startup time for an example workload reduced from 47ms to 2.4ms, memory usage down from around 100MB to 4MB, binary size reduced from around 80MB to 3MB.
How Scriptc compiles TypeScript to native code
The Node.js API is supported as well as the TypeScript language and the idea seems to be that server applications running on Node could be compiled to native using this tool.
Although this sounds promising, comments on Hacker News are not entirely favourable. “The architecture is idiotic, they have zero credible perf numbers,” said one, claiming that the “project reeks of weapons grade AI psychosis.” Expanding on this, complaints include the use of QuickJS, using floats for numbers, and resorting too quickly to an embedded JavaScript engine.
Vercel as a company is enthusiastic about AI and Scriptc appears to have been made largely with AI.
When Microsoft introduced a native code TypeScript to JavaScript compiler in TypeScript 7, greatly reducing compilation time, the awkward question was: if native code is so much faster than JavaScript, why not use a more performant language for the application code as well?
How did we get here? It all started with Brendan Eich’s LiveScript for Netscape Navigator, renamed JavaScript when first released in December 1995, and the beginning of interactive web pages. Part of the thinking behind JavaScript was that it could be used to script Java applets – Java components embedded in web pages – but JavaScript itself was always more popular. Adobe used a variant of JavaScript, called ActionScript, for its Flash add-in which at one time looked likely to dominate the web.
Using the web browser as an application runtime was critical for companies trying to bypass Microsoft’s desktop application dominance, and Google in particular invested in JavaScript, creating the V8 JavaScript engine for its Chrome browser, first released in 2008.
Then came Node.js, a server-side runtime for JavaScript based on V8 and first released in 2009 by Ryan Dahl. Dahl was particularly interested in improving concurrency in web applications, but another thing that drove adoption was that developers could use the same language both on the server and in the browser, and that JavaScript was an easy language to learn.
The mass adoption of JavaScript that followed also exposed its shortcomings. Microsoft’s Anders Hejlsberg, who also invented the C# language, believed that strong typing for JavaScript was essential in order to make large applications maintainable. He therefore came up with TypeScript, a superset of JavaScript with strong types that compiles to JavaScript for runtime compatibility.
TypeScript has proved wildly popular and most applications which target JavaScript are now written in TypeScript. If we add Scriptc or an equivalent into the mix, then the JavaScript element is all-but eliminated, though note that as currently designed Scriptc will run some of the code in a JavaScript engine so we are not there yet.
If you write in TypeScript and compile to native code though, why use TypeScript, why not use Go or Rust? Or if those languages are too demanding, Java or C# both of which have strong ecosystems?
The answer is the familiarity of TypeScript, the massive range of npm packages, and the ability to use the same language on the server and in the browser.
Nevertheless, the problem which Scriptc sets out to solve can perhaps be bettered simply by choosing a more performant application stack and reserving TypeScript for code that runs in the browser.
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.
Last week Moonshot AI introduced Kimi K3, with the promise that “the full model weights will be released by July 26 2026;” while Alibaba said on X that “Qwen 3.8 is launching and going open-weight soon”.
These are capable LLMs (large language models), and the open weights promise means that developers will be able to download them from Hugging Face and run them locally.
There are two reasons why local AI is inferior to pay-as-you-go cloud AI from one of the big providers: the LLMs are not as good, and the hardware is much inferior to data centres stuffed with massive amounts of RAM and GPUs.
However, there are also two reasons why local AI is much preferable to cloud AI: it is free to use, and more private. As an individual developer the notion of a constant trickle of spend while coding is disturbing, though I also see how the figures can make sense in a business context if there are corresponding benefits in productivity or staff numbers.
LM Studio using Qwen 3.6 to write some C# code
Joining the dots though, it seems possible that as local AI improves the premium (and uncertain) cost of what is sometimes called frontier AI will no longer be worth paying for.
Someone has to pay for the LLMs and there are political as well as technical aspects to this, as there are in other areas of IT. The implications of commoditised AI though are considerable, and means that we can expect further shifts in the tech landscape in this space.
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.
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.
Following a power outage, all my Windows servers (hosted on a single Hyper-V server) rebooted. They are configured to come back up, but I found that Remote Desktop was not working to many of them, including the domain controller.
I found a workaround using the Hyper-V manager on one server to which I could connect; this lets you connect via a different route.
Today I focused on what was causing the issue. Microsoft has quite a reasonable troubleshooting guide here which pointed me in the right direction: on the Mac I use for day to day work, for example, port 3389 was blocked on the target server. In the Windows firewall this port was open for private and domain profiles, but not for the public profile, which is what one would expect.
Microsoft’s guide says to enable port 3389 on all profiles but that seems wrong to me. Likely OK for a server, but not for a laptop, for example. And why would it matter?
The answer was that even on the domain controller, the local network was set to the public profile.
The local network on the domain controller I was trying to reach was set to the public profile.
Oddly, as I explored the network settings, this changed by itself to the domain profile, and Remote Desktop started working again.
There is a detailed post here on the intricacies of network profiles and why they can go wrong. It is potentially quite a tricky problem since of course you need access to the server in order to fix it, and if your setup is like mine, the servers do not have keyboards or screens attached.
Cloudflare’s vinext project, which implements the Next.js API using Vite as the bundler instead of Turbopack or Webpack, has released its first beta, suggesting (if there was any doubt) that this is a project intended for production use and not just an AI experiment.
Why does vinext exist? The introductory post grabs attention with its claim that using AI, Next.js was rebuilt in a week – though we note that some 20 weeks have passed since then, and here we are at beta 1.
The rationale for vinext given in that original post was that Next.js build output hooks it to Vercel’s platform – a problem that presumably matters to Cloudflare because it would like more Next.js projects to run on its own Workers platform instead.
The paragraph headed “Why” in the vinext readme has a different emphasis, claiming that “Vite has become the default build tool for modern web frameworks” and that vinext now provides a “full React Server Components framework on Vite.”
Neutral observers will note that whereas Next.js defaults to Vercel, vinext “natively supports Cloudflare Workers,” with support for additional platforms still in a planning phase. This is mitigated though by a Nitro plugin, Nitro being a server for Vite applications, that enabled deployment anywhere Nitro (or Node.js) can run. Cloudflare Workers is still recommended as the “best developer experience”.
Performance figures for vinext show that while builds tend to be faster and client bundle sizes smaller, Next.js is faster from a cold start. There is another nuance here: Next.js pre-renders static pages to HTML at build time but vinext does not; it caches them after the first request. There is an open issue to fix this.
The existence of vinext is a good thing for competition and will perhaps indirectly benefit the OpenNext project, in which Cloudflare is also involved, which takes another approach to making Next.js independent of Vercel, via a Next.js deployment adapters API which is now stable (since Next.js 16.2). Vercel has an incentive to make Next.js an open platform, to reduce interest in vinext.
That said, Cloudflare is a strong competitor because it owns its own infrastructure, whereas Vercel deploys to AWS.
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.
