MAUI App Accelerator version 1.3 is now available!

TLDR: Go here and download it. In addition to bug fixes, it adds a new page and 6 new features you can add to the generated app. 

Yes, this list is getting very big!

I'll be honest; this release has taken longer than I expected and isn't as planned. If you're following the activity on GitHub, you'll have noticed that most of what was originally planned for the 1.3 release is now scheduled for v1.4.

That's probably not what you're here for though. Here's what's included in this release.

A new page: MediaElement

A simple page that includes the MediaElement control. This is for you if you want to play videos in your app.

New Features:

BenchmarkDotNet

Add an additional project to the generated solution that is set up to run performance benchmarks on your code with BenchmarkDotNet.

EFCore.Sqlite

Add a reference to the Entity Framework SQLite library so you can work with SQLite databases with Entity Framework.

Akka.Hosting.Maui

Use Akka.NET actors in your .NET MAUI app.

AlohaKit

Add a reference to the AlohaKit control library to use their controls in your app.

SimpleToolkit

Add a reference to the SimpleToolkit control library to use their controls in your app.

Uranium UI

Add a reference to the Uranium UI library to use their controls in your app.

If you've made it this far and haven't already, install the extension or update it if you already have it installed.

https://marketplace.visualstudio.com/items?itemName=MattLaceyLtd.MauiAppAccelerator

Suggestions for what else to add is appreciated, as are reviews, and sponsorship.

Three years with GitHub Sponsors

I'm trying to be a bit more intentional about my career, money, and where I spend my time/effort. As part of this, I thought it might be interesting to look at my sponsorships via GitHub Sponsors.

I know many people publish full income reports. I don't feel confident enough to do that, but I hope that some of this analysis will still interest others without monetary sums.

Here's the key graph. It's the total amounts received each month.

While not a smooth graph, it's definitely trending up!

Public vs private sponsorships

There are two broad ways of grouping sponsors. Those that are public or private; and those that are one-off or recurring.

Let's look at the public vs private distinction first.

It's easy to see who the public ones are. Their avatars are shown on my sponsor page.

To save you from having to count, that's 35 public and 12 private.

The only difference to me is that I don't publicly thank the private ones by name.

But are there any differences between the different types of sponsors?

Different amounts from different types of sponsor

The figures in blue (on the left) of each group are the averages from all sponsors. However, as the very spikey graph above might suggest, there have been a few sponsors choosing larger amounts which skew things slightly.
The orange bar excludes the largest and smallest value from each group when calculating the mean.

Recurring sponsors typically pay less each month than a one-off sponsor. This isn't surprising and is almost encouraged.

I found it pleasantly surprising that amongst one-off sponsors, private sponsors pay about 17% more. I'm unsure why or how to use this information, but it intrigues me.

I didn't separate the public and private recurring sponsors, as only one is private.

But averages don't tell the whole story.

Total amounts from recurring vs one-time sponsorships

Unsurprisingly, while I have many fewer recurring sponsors, and the monthly average from each one is less than a one-off sponsor, the total amount from them is nearly three times the amount from one-off sponsorships.

I'm not sure this graph needs a legend, but the blue wedge is the total from one-off sponsors, and the green section is from recurring sponsors.

Who I sponsor

I currently only sponsor 1 person through GitHub Sponsors, but I sponsor 6 people through Patreon. Again, without using actual figures, it's only in the last couple of months that the amount I receive through sponsorships is more than the amount I give via Patreon. It's the circle of creative people supporting each other.

Other "interesting" things I noticed during the analysis

One person has made multiple one-off sponsorships.

One person started out by making a one-off sponsorship and, a few months later, came back as a recurring sponsor.

Recurring sponsor durations vary greatly. From 2 months to 3 years (and going). I see no discernable pattern to this.

In summary

While I'm not giving actual figures, I will say that the total for the whole period is about half of what I'd earn in a typical month of paid work. However, over the last three years, this has still been really helpful. As in the last 3.5 years, I've only had paid work for 8 months. (Yay, COVID!)

The most crucial point was when sponsorships helped pay the balance of an unexpected tax bill when I hadn't worked in nearly 2 years!

Now I'm nearly debt free again, and this makes me think about how I can (and should?) give more back to other creators who I want to support.

I also need to think about how, if at all, I can use the above analysis to help encourage more people (or organizations) to become sponsors. (Either of myself or others.)

Do you really need MVVM?

MVVM is a popular design pattern, but I think it is often misunderstood, and I frequently encounter people with strong opinions about how/when/where it should be used.

It's a powerful and useful pattern, but I meet people who use it that have never questioned if they should. It's just "what everyone does" and has become a default for many people.

It being a default isn't necessarily a bad thing, but never questioning decisions can be.

The MVVM pattern allows for separation between the UI/presentation layer and application or business logic.
It is commonly understood to provide 3 potential benefits:

1. Increased testability (for business/application logic).
2. Reuse of business/application logic in different projects/solutions/apps.
3. More easily allow different people to work on the UI and other layers simultaneously.

And yet, I see people who are the sole developers on a project, don't write any tests, and don't need to (re)use any of the code elsewhere being dogmatic about using a pattern for which they get none of the intended benefits.

I admit that there can still be other benefits to using the pattern, but it's always worth questioning whether you should use something if you're not getting (or don't need) the benefits it was designed to provide.

Are you strictly sticking to "rules" of "how things are supposed to be done" when you're not getting or using any of the benefits the pattern was designed to enable and encourage?

What if your XAML code was much simpler?

Over the last 6 months, I've given talks at a dozen user groups and conferences. 

In those sessions, I've discussed some of the thinking and experimentation I've done over the last couple of years, exploring ways of improving how we think about and work with XAML.

With each talk, I've refined and expanded my thoughts based on feedback and discussions with attendees immediately afterward.  (Yes, I'm prepared to drive 4 hours each way for the chance to talk about XAML--I get it; that makes me an outlier.)

I've been reluctant to share too much detail while I refine how I communicate these ideas. 

I can spend an hour talking about how C# best practices can be applied to XAML and how it makes a massive difference to the code you write, but no one wants to read that. (Please tell me if I'm wrong.)

I can also show you how I can take even a relatively simple XAML file and massively reduce the complexity. But the difference is so big it's easy to miss all the changes and understand why the differences are there.

As I start to work out how I can best share these ideas, I'm putting together small videos and pieces of writing to explain the differences and the tools I've made to help.

Here's a short video demonstrating one such tool that I released on my YouTube channel this week.

>

I'd love your thoughts on the video, and on the tool if you try it.

Thank you ElektroStudio for helping spread the VB love

I've built more than a few Visual Studio extensions.

Most of them only work with C# code.

I'd like to support VB.Net in more of them, but other priorities get in the way.

Const Visualizer is one that hasn't had the love it could have. It's really useful in some instances, but I haven't found the time to address the things about it that niggle at me when I use it.

Given that I haven't found the time to add the C# related fixes I want, you'll not be surprised to hear that VB support wasn't high on my priority list.

So, when I was asked about adding VB support, I had to acknowledge that it was only going to happen if someone else contributed it. Thankfully, ElektroStudios did just that, and now version 2 is in the marketplace with C# & VB.Net support.

I know that many people still use VB every day and that some of you even look to me for advice and tools on building with it. I wish I had more time to focus on supporting it, but maybe if more people contribute some of the work, we can build better tools for VB development together.

Whatever happens, thank you, Elektro, for your contribution.

global (and implicit) using directives - but for XAML?

One of the great things about .NET 6 and C# 10 was the introduction of global and implicit using directives. Namespaces that could be defined once and then made available to all C# files in a project.

These small features simplified code by reducing the boilerplate and noise at the top of each file.

As part of my exploration into how XAML files could be made better, I've been looking at whether something similar could be done and whether the duplication at the top of each file could be removed.

The five highlighted lines in the above image (and many like them) are in almost every file. I even have some files with many more aliases defined. 

These lines add noise and distraction. Plus, inconsistent use of XML namespace aliases across different files can become confusing and lead to errors and unexpected behavior. 

What if we could have all the namespaces (and aliases) defined in a single place and available to all xaml files in a project? With a file like this:

I decided to see if I could make this possible.

Because I have previously spent time looking at the internal .NET MAUI code relating to XAML files, I started there.

In theory, this idea is applicable to any flavor of XAML, but I wanted to start by creating a working example of what I was thinking as after having talked to hundreds of developers about thinking of XAML in different ways, I know that many have a hard time even considering something different to what they've always done. I hoped that showing what was (or could be) possible might help open imaginations more easily.

But it's not valid XML!

Before I started, I knew that there would be objections to this idea. 

I knew some would not like it because it is different.

I know some would not like it because it technically makes the document invalid. XAML documents are (or should be) valid XML documents and, as such, cannot use undeclared namespaces (and aliases).

I pressed on regardless. I knew it will make the document technically invalid, but I hoped that the benefits it might bring could outweigh this.
If going back to the C# comparison, a C# file that relies on namespace directives that are implicit or defined (globally) in another file isn't much good on its own, either. Similarly, a XAML file that is "valid" but makes references to types that are in other files is of limited use by itself too.
This wasn't enough to stop me.

Going through the XAML source, I soon discovered that XAML files are potentially read (and things done with them) in many different places in the code and in different ways. The small chance that this would be an easy thing to explore and experiment with quickly got smaller and dissolved away entirely.

But I pressed on.

My goal of showing a working example was quickly scaled back to be just the smallest proof of concept appropriate.

Rather than support multiple namespace aliases, I opted for just one. (xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml")

And I got there. 

Look, here's a file without the "x" alias defined, but it still works.

I know you're skeptical.

After all, look at those blue squiggly lines under the code where the "x" alias is used.

It turns out they're coming from the editor. It's trying to parse the document too.

As soon as I saw how frequently the MAUI code processed XAML content as XML, I thought this could be a problem. I had an increased concern that there could be a lot of other tools and features that relied on XAML files always being valid XML documents.

As a simple example, here's the dialog I see every time I save that file.

Very early on in my thinking about this, I did worry that additional tools needing to be able to process XAML files could be an issue. It quickly became a bigger issue than I expected.

I've looked at lots of code that works with XAML files (and written a lot, too), and the majority of it does treat XAML as XML and uses framework-provided functionality.
In fact, to get MAUI to treat my modified XAML documents as valid XML, I ended up having to add the missing namespace alias declarations into the document each time it tried to process them.

This wouldn't have been the end of the world if such a modification was needed in one or two places, but this isn't practical on a such a wide level. There is too much code (inside VS, frameworks, extensions, and other tools) that assumes XAML files will always be valid XML files too.

[Aside: I assume C# was able to add features such as global and implicit namespace directives as it is responsible for the entire toolchain that reads, parses, and complies '.cs' documents. Any 3rd party code that isn't using Roslyn/CodeAnalysis libraries to do the work has to take care of any special scenarios like this by itself, but I expect very few do. It's not like XAML which has been around for a long time and always supported files being treated as valid XML.]

So, my experiment was a failure.

In part.

I'd learned that this wasn't a practical thing to implement and that the impact on the wider ecosystem was almost certainly going to be too big for me to overcome.

Like all good experiments, I wasn't trying to do this. I was testing a hypothesis that it was possible and that it would be useful if it was.

I'd hoped to get to the point of starting a wider discussion on making global XML namespace aliases possible in XAML by showing that it was achievable. A discussion on how best to implement it while providing something that others could experiment with so they could experience the benefits is not to be.

But, as part of this experiment, I've become increasingly pleased by not having to look at all the noise the alias declarations add to the opening element of a XAML file.

Rather than remove them, what if they were hidden?

Well, this feels like a simpler thing to implement and with a much lower risk of side effects too.

Take a look at the following highlighted item. (It's in a WinUI3 project, but that doesn't matter.) 

Yes, it's a new outlining node.

Guess what it can be used to collapse... or look below.

Isn't that nicer?

And for completeness, here's the original document from above with the 5 long lines all now collapsed behind one short placeholder. 

I'll make this publicly available soon.

Of course, this doesn't address the duplication across files and the possibility of issues due to aliases being used inconsistently across files within a project, but I have separate ideas for addressing those.

But for that, and details of other ways to XAML can be improved (without needing to make changes to the frameworks being used,) stay tuned for future posts.

2 types of testing - but only 1 that AI can help with

There's currently a lot of discussion about using ChatGPT (or other, similar, AI tools) to create unit tests for code. 

This has the opportunity to be valuable, but it's important to consider that there are two broad categories of tests when it comes to software. Each answers one of the following questions:

1. Does the code do the right/correct thing?
2. Does the code not do the wrong thing?

At first glance, you might mistake these for being the same. But there's a subtle difference.

Does the code do the right/correct thing? 

Does it do all that it's supposed to?

Does it correctly implement all of the requirements?

By only looking at the code, it's impossible to know for sure. Well-written code should provide many indications about what it should do, and wider knowledge of the application and the domain to which it relates can also provide insight but without knowing the full requirements, you can't know for sure.

If all you have is the source code, you must assume it's correct. Until you find something wrong or that needs changing.

Does the code not do the wrong thing?

Sometimes the requirements for an app might include a statement that "the code should not crash unexpectedly" or "the code should be secure." Often this is just implied. Who wants an app that crashes or is insecure? 

Fortunately, these are the kind of things you can test for without any wider knowledge of what the code should do. This is how they're different from the first kind of tests.

AI (& other) tooling can be a really good way of creating tests that try and break code. If it finds something, and you fix the issue, you get better (more reliable) code. But be wary of relying on such tests alone.

Yes, having more tests is generally better. But beware of relying on these tests for identifying regressions and the introduction of bugs in the future.

One of the great benefits of having tests is that they not only help you verify the code is correct now but also that it isn't accidentally changed in unexpected ways in the future.

Having tests that verify the code does the correct thing (produces the correct output given specific inputs) is good. But, of greater benefit is that the tests can verify that the code still produces the correct output if you need to modify the internal code. Tests that only make sure that the app doesn't crash, given particular inputs, aren't as valuable in the long term.

It might be great to say you have lots of tests and to even have high test coverage, but if they're not helpful as the code changes, are they really all that useful?

Yes, "it depends"

It's not as black-and-white as I've laid out above. There are times when AI might be able to generate useful tests of whether the code is doing the right thing based on the names and patterns it identifies in the code. Or comments in (and around) the code may provide sufficient context to generate useful tests.

Your mileage may vary when it comes to having a tool (AI-based or otherwise) generate tests for you, but I've always found thinking about these 2 types of tests helpful.

You say "it's too complicated to test" but...

...I hear too complicated NOT to test.

If it's really that complicated, how can you ensure everything is correct?

If it's complicated, how can you be sure that you won't introduce unintended side effects (break something that works) when you make any future modifications?

If it's simple to do manually but would be difficult to automate, detailed manual instructions may be a suitable alternative. Just don't try to rely on remembering everything involved.

It may be difficult but would creating automated tests be really valuable and give you confidence that things work without a lot of repeated manual effort?

Dear developer, how will you know when you're finished?

That thing you're working on:

• How are you measuring progress?
• Are you making progress?
• Do others depend on what you're doing and need to know what you'll produce and when it will be finished?
• How will others test it when you've finished?
• How do you know you are going in the right direction?
• How will you know when it's done?

You should probably work this out before you start!

A few years ago, I was invited to give a talk at university. I was asked to talk about how to think about building software. Very vague, but I interpreted it as a reason to talk about the things I think about before starting to code. 

Among the things I mentioned was the Definition of Done. (The best thing Scrum has given us.)

The students had never thought about this before.

The lecturers/tutors/staff had never thought of this before.

If you're not familiar, the idea is to specify/document how you'll know that you're finished. What are the things it needs to do? When they're all done, you've finished. 

They added it as something they teach as part of the curriculum!

Without knowing when you're done, it's hard to know when to stop.

Without knowing when you're done, you risk stopping too soon or not stopping soon enough.

I like causing tests to fail

I like it when tests start failing.

Not in a malicious and wanting to break things way.

I like it when I make a change to some code and then tests fail.

This could seem counterintuitive, and it surprised me when I noticed it.

If an automated test starts failing, that's a good thing. It's doing what it's meant to.

I'd found something that didn't work.

I wrote a test.

I changed the code to make the test pass.

Ran all the tests.

Saw that some previously passing tests now failed.

I want to know this as quickly as possible.

If I know something is broken, I can fix it.

The sooner I find this out, the better, as it saves time and money to find and fix the issue.

Compare the time, money, and effort involved in fixing something while working on it and fixing something once it's in production.

Obviously, I don't want to be breaking things all the time, but when I do, I want to know about it ASAP!

Aspects of "good code" (not just XAML)

I previously asked: what good code looks like?

Here's an incomplete list.

It should be:

• Easy to read
• Easy to write
• Clear/unambiguous
• Succinct (that is, not unnecessarily verbose)
• Consistent
• Easy to understand
• Easy to spot mistakes
• Easy to maintain/modify

And

• Have good tooling

In thinking about XAML, let's put a pin in that last point (as we know, XAML tooling is far from brilliant) and focus on the first eight points.

Does this sound like the XAML files you work with?

Would you like it to be?

Have you ever thought about XAML files in this way?

If you haven't ever thought of XAML files in terms of what "good code looks like" (whether that's the above list or your own), is that because "all XAML looks the same, and it isn't great"?

Is manual testing going to become more important when code is written by AI?

It's part concern over the future of my industry, part curiosity, and part interest in better software testing.

AI generated this image based on the prompt "software testing"

As the image above shows, it's probably not the time to start panicking about AI taking over and making everyone redundant, but it is something to be thinking about.

If (and it might be a big "if") AI is going to be good at customer support and writing code, it seems there's still a big gap for humans in the software support, maintenance, and improvement process.

In that most software development involves spending time modifying existing code rather than writing it from scratch, I doubt you'll argue with me that adding features and fixing bugs is a major part of what a software developer does.

This still leaves a very important aspect that requires human knowledge of the problem space and code.

Won't we, at least for a long time, still need people to:

• Understand how the reported issue translates into a modification to code.
• Convert business requirements to something that can be turned into code.
• Verify that the code proposed (or directly modified) by AI is correct and does what it should?

Having AI change code because of a possible exception is quite straight-forward.  Explaining a logic change in relation to existing code could be very hard without an understanding of the code.

And, of course, we don't want AI modifying code and also verifying that it has done so correctly because it can't do this reliably.

There's also a lot of code that isn't covered by automated tests and/or must be tested by humans/hand.

Testing code seems like a job that won't be threatened by AI any more than other software development-related jobs. It's another tool that testers can use. Sadly I know a lot of testers rely heavily on manual testing, and so will be less inclined to use this tool when they aren't using any of the others already available to them.

5 reasons WE SHOULD think about how XAML could be better

 

1. Working with XAML can be hard.
2. Working with XAML can be slow.
3. There is "limited" tooling for working with XAML files.
4. There is a lot of existing code that uses XAML, which needs to be supported, maintained, and updated in the future.
5. It is still the most mature option for building native User Interfaces for desktop and mobile apps with .NET.

I'd love to hear your thoughts on how it could be better?

5 reasons NOT to think about how XAML could be better

1. Because no one else is thinking (or talking or writing) about it.
2. Because that's just the way it is.
3. Because if it could be better, Microsoft would have already done it.
4. Because we could use another language instead.
5. Because we're too busy doing the work to think about how the work could be better.

• Bonus: Because if we realize there's a better way, we might have to admit what we've been doing all this isn't the best.   

I didn't say they were good reasons....

Microsoft's Ability Summit has inspired me, again!

Microsoft's Ability Summit was last week, and it has, once again, inspired me to do more work on the tools I have in progress.

You can register via the above link to get to the official site, but the videos are also now available on YouTube.

It was inspiring to see the recently announced Accessibility Checker inside Visual Studio in action. It also showed me that it does have value. I had doubts about this as it's functionality that already exists elsewhere. 

This new tool allows you to run the same tests as can be run by Accessibility Insights, but from a button in the in-app (debug) toolbar (or Live Visual Tree window.)

I've got in the habit of using Accessibility Insights directly or via automated testing* to perform basic testing of an application.

* Yes, I have tests that run an app, navigate to each page, run accessibility tests against that page, and check for (& report) failures. It's not perfect, but it's much better/faster/reliable than doing it manually. 

It reminded me that I have code that can do much of this on source code.

Like this:

When the benefit of Visual Studio having an Integrated Accessibility Checker in the debug experience is that it makes issues easier for developers to see and fix because they don't have to go to another tool. And it makes them quicker and easier to fix by "shifting left" to be part of the debugging experience; how much better to shift further left to when the code is being written (before getting to the debugging step) and not putting the functionality behind another tool that must be known about and run but putting the information where developers are already looking?

I really must hurry up and get this in a state that I can make it public.

It's not as complete as the other tooling as it can't catch quite as many issues, but I think there's value in catching (and fixing) even some issues earlier. 

"It's as pretty as I'm able to make it" - An excuse that shows an opportunity

When a developer gives a demo that shows code with a UI, they invariably make no effort to make it look in any way visually appealing or show any indication they've done anything more than put controls on the screen.

They'll also excuse their lack of effort on the basis that they don't have the skills, knowledge, or experience to do any better. Also, maybe with a subtle joke that designers are somehow lesser. :(

With a little effort, presenters could significantly distinguish themselves from "all" the others who don't put in any effort here.

It would also be a great opportunity for showing something that easily makes a basic UI look better than many do by default.

My cogs are whirring.....

Please help improve the extensibility experience in Visual Studio

 

Have you ever seen the above prompt (or something very like it) inside Visual Studio?

It's displayed when a solution is loaded that requires workloads or components that aren't currently installed.

Those requirements are specified inside a .vsconfig config file.

The idea is that VS will tell you if you haven't got the things the project owners/creators/maintainers have specified as necessary to work with a project installed.
You can then click on the "Install" text link, and it will install the things you are missing.

But what if you want to require (or recommend) that an extension is installed to work with the solution?

Well, then you're stuck. 

You're forced to include this in the documentation and hope that someone looks at them. Ideally when setting up their environment, or--more likely--when things aren't working as expected and they want to know why.

Obviously, this is far from ideal and can be a barrier (I think) to the creation of specific extensions to fill the gaps in individual projects. - I have had multiple discussions where custom extensions were ruled out because it is too difficult to get everyone working on the code base to install the extensions. We ended up with sub-standard solutions requiring documentation ad custom scripts. :(

Wouldn't it be great if the existing infrastructure for detecting missing components could be extended to detect missing extensions too?

Well, it's currently under consideration. Maybe you've got a moment to help highlight the need for this by giving the suggestion an upvote. 👍

Thank you, please. :)

Do you know what good code looks like?

It's a serious question!

If you don't know what good code looks like, how do you know what you're doing is good?

What if it's not good?

What constitutes as good?

These are important questions when creating reliable, maintainable, high-quality code. 

This applies to any code or programming language, but especially to XAML.

The above quote was from a member of the audience after one of the first times I gave a talk about rethinking XAML. I now use it as an audience prompt in current talks.

I've met very few people who work with XAML who have given serious thought to what good XAML looks like.

Most XAML files look the same. 

And they don't look great.

They're not easy to read.

They're not easy to understand.

I don't think the solution is abandoning XAML. (Especially as there's so much existing code that needs to be supported, maintained, improved, and enhanced)

I think the solution is to change the way we write XAML.

More on this to follow...

In the meantime, what do you think "good XAML" looks like?

Three thousand .NET MAUI Developers can't be wrong!

 

Well, it's a milestone of sorts and, as such, is something worth celebrating.

Beyond this post, I've also just released an update that fixes a bug preventing the creation of apps with spaces in their name.

If you don't know what any of this is, the MAUI App Accelerator is a Visual Studio (for Windows) extension that provides a wizard to quickly scaffold a new .NET MAUI application by selecting from a number of options, pages, and features to include in a generated app.

Get it from the marketplace or provide feedback or suggestions on GitHub.

MAUI App Accelerator version 1.2 is now available - What's new?

Version 1.2 adds:

• 1 new Navigation Style: None (No Shell)
• 4 new pages: Map, NavigationPage, TabbedPage, & FlyoutPage
• 7 new features: FontAwesome, sqlite-net-pcl, AppCenter, Sentry.io, InAppBilling, StoreReview, & Audio
• Use of the newest versions of NuGet packages.
• Support OS-level Text Sizes in the wizard (for improved accessibility.
• Some bug fixes
• Improved testing (although you'll never see that)
• Images of new sponsors - a big thank you to all of them
• Support for all the sponsor images when the wizard is too small. 

Let me break that down.

New Navigation Style: "None"

Don't want to use Shell? - Now you have that option.

New Pages:

If you're targeting .NET 7.0 you can now create a page with a map on it (and the relevant package referenced and configured in the app Builder.)

This means you can easily create the following on Android & iOS.

But not on Windows--because it doesn't (yet?) have a native map control. :(

If you're not using Shell, you may also want to use one of the page types that aren't supported by Shell. Now you can:

New Features:

There are lots of new features that have been added.

Most of these add references/files and do essential configuration. 

Hopefully, this provides an idea of what's possible and hints at where I'd like to go with this in the future.

If it gives you ideas for what you want to see added to this list, please create a suitable issue.

Updated NuGet package references:

I find it very disappointing when you create a new project, and the first thing you need to do is update all the referenced NuGet packages to pick up the latest features, fixes, and security patches.

Well, not here. Everything 

Support for OS-level text sizing:

In the past, if someone had configured Windows to make text larger, like this:

Then the wizard could end up looking "less than ideal." All the buttons are at least accessible, even if you can't read all the text.

Most of this UI had come from Windows Template Studio and had design and accessibility reviews by the Visual Studio team. I was surprised this was an issue.

But, now it's not:

This isn't something I've ever considered previously. For the most part, addressing the issues was easy, but some things were harder than I would have hoped. This includes testing the related changes. I guess that part of the reason this hasn't been noticed before is that there are no automated testing tools for verifying this behavior, and to manually test requires changing an OS setting. Hopefully, this will change in the future.

New sponsor images & Improved handling of so many sponsor images:

Having a lot of people sponsor me via GitHub is a lovely thing. In appreciation of this, I tell them how to remove the prompt to become a sponsor that is shown in some extensions. And if their sponsorship isn't private, I add their avatar to the bottom of the wizard.

Like this:

However, when the wizard is made smaller, some of those images are obscured.

Hey, I'm not complaining. This is a nice problem to have, and I want to respect all my sponsors, not just those displayed on the leftmost edge of the screen.

So, now this happens when the screen gets smaller:

Yes, I have wasted several minutes watching as things overlap when the available space is reduced.

Please download version 1.2, try it, and tell me what you think. (If it's good, leave a review on the marketplace so others can see it too.)

Then, if you have suggestions for other things I can add, head over to the GitHub repo and create, upvote, or comment on a suitable issue.

Did you know that GitHub sponsors can be Private?

When you sponsor someone via GitHub Sponsors, there's an option to make your sponsorship public (so everyone can see it) or private (so only you and the sponsor know about it.)

Why might you want to keep your sponsorship private?

Well, you may have many reasons. 

If I had to speculate, one reason I've assumed is that you don't want other people asking you to sponsor them too, or questioning why you are sponsoring a person.

I've had a few well-known people (in the Microsoft/.NET world) sponsor me. This was very surprising and flattering, but I can easily see other people online reacting to this knowledge negatively or demanding that they sponsor them too.

All I can do is thank these secret benefactors.

Whatever your reason, I (or anyone else you chose to sponsor) will always be grateful for your sponsorship.

If you do sponsor me, you will get:

• My gratitude.
• The knowledge that you're helping me create tools to help more developers do more. (like this.)
• Details of how to remove the prompt to become a sponsor that's shown by some of my extensions.
• Early access to my writings and some tools via a private GitHub repo. (recurring sponsors only--for now, based on how the GitHub sponsors infrastructure makes this possible.)
• If not a "private" sponsorship, I display your avatar in some of my tools. As below. (Position and duration of inclusion depend upon sponsorship amount and if one-off or recurring.)

Any amount, one-off or recurring, for as long as you wish. Your sponsorship will be appreciated. :)

And a big thank you once again to all who have, are, or will sponsor my activities.

All my Visual Studio extensions now work on ARM64 - thanks to GitHub sponsors

Thank you, lovely sponsors!

My MacBook is broken. According to the "Genius" I spoke to, it's not dangerous, but if it gets worse, I shouldn't use it anymore.

My plan had been to replace that and then start thinking about getting an ARM64 device for Windows development and testing.

But then I started to get requests for supporting my Visual Studio extensions on the ARM64 version. In that, those sponsoring me on GitHub are primarily in response to the extensions I've made, it made sense to use the money they've generously provided to be able to enhance those extensions so more people can use them.

So I put the sponsorship money towards a Windows Dev Kit so I can test the extensions in a suitable environment. Technically, it's not needed for development, but I didn't want to release anything that isn't adequately tested.

So, what can you do?

Well, here are the supported extensions:

Warn about TODOs

Visual Studio automatically takes code comments that include TODO and turns them into User Tasks that are displayed on the Task List.

This extension takes those same tasks and also creates warnings for them.

You can also configure which items result in warnings (or Errors) being listed. Like here:

Error Helper

Make it easier to work with items in the Visual Studio Error List by copying or searching (with Ecosia, Bing, Google, or StackOverflow) for just the description of an error.

WaterMark

Display a text watermark over the Visual Studio editor.

C# Inline Color Visualizer

See samples of the colors you use within your C# code.

Never again be forced to remember what a named color looks like.

Clearly Editable

A Visual Studio 2022 extension to change the editor's background color to show which documents can't or shouldn't be edited. This could be because that are generated, read-only, or linked files.

String Resource Visualizer

Visual Studio extension that shows the text of a string resource (.resx) when used inline in code.

The default language value is displayed as a text string directly above where the resource is used. As shown in the screenshot below.

Use it in your C# files

and in .cshtml files with the ASP.NET Localizer

Const Visualizer

A Visual Studio extension to show the values of constants where they are used.

Comment Links

Create links between any files. Useful if your project or solution contains code in multiple languages or if you wish to link to documentation.

Watch an example on YouTube

Don't Copy Always

Automatically checks for files that have 'Copy to output directory' set to 'Copy always'.

Any affected files will be listed in the Output Pane.

Resource Pseudo Localizer

Testing localized string resources can be tricky, especially if you don't speak multiple languages. This extension adds a new context menu to RESX and RESW files in Solution Explorer that will allow you to pseudo Localize your string resources. Viewing the app with pseudo-localized strings makes it easy to spot any text that doesn't come from a resource.

Demo Snippets

Makes using code snippets in demos easy. Do real demos but without having to worry about typing or managing pieces of code to copy in from elsewhere.

Coming soon:

MAUI App Accelerator

Rapid XAML Toolkit

A big thank you to all my lovely sponsors. (You could become one too.)
Who knows what future sponsorship money will enable me to do.....?