MAUI App Accelerator v1.4

Consider this a low-key announcement that version 1.4 of MAUI App Accelerator is now available in the Visual Studio marketplace.

This version adds support for building apps with .NET 8.0. 

Replacing occurrences of "net6.0" with "net8.0" might seem very simple, and probably is, but there was a lot more involved in the changes for this new version. 55 commits were made over 286 files.

There's also been significant testing involved. Combinations of all available options and just a single page produce 570 combinations in a generated app. And I also have tests for combinations of pages too!

A massive thank you to everyone who supports me via GitHub Sponsors. As a one-off or on a recurring basis (for any length of time), all sponsors make a massive difference and are a great encouragement. It's a pleasure to add each [non-private] sponsor to the list whose avatars are included at the bottom of the wizard.

When some people are so critical and demanding of open-source projects and developers (more on this soon), it's great to know that there are people who are supportive and encouraging of what I do.

Is MVVM still relevant or useful?

Thinking out loud (or rather through typing) here.

The MVVM pattern has a problem: everyone has a different definition of what it is and how it should be implemented.

"Everyone" thinks their understanding is the correct one, and doing it a different way isn't the "proper" way of doing it.

It was always intended as a loose structural guideline and principles rather than as a highly prescriptive way of writing code.

Maybe it's just me, but I still hear more discussion and focus on the use of MVVM as a "framework" than on other aspects of making a great app and creating an easily understandable and maintainable codebase.

Two key benefits that MVVM was initially intended to provide don't seem all that relevant either.

Reuse - When a ViewModel was referenced in separate solutions that each targeted a different platform, abstracting logic away from the UI to easily be reused in multiple solutions/apps made a lot of sense. When using MAUI, Uno, or Avalonia--where a single solution can produce apps for multiple platforms--using an architecture that structures code for reuse when none is needed risks adding unnecessary complexity.

Testability - most ViewModel code (still--sadly) goes untested. If you're the exception, congratulations. So, doing something for the sake of testability but then not creating tests seems a bit unnecessary. (At best.)

So what to do instead?

I don't have a single answer.

I know there are things like MVU and MVUX, but I just wanted to write this to get my subconscious thinking about the idea...

One test is never enough!

One part of creating coded tests for software is being able to know when something doesn't work as it should, not just confirming that something does work as expected. 

Imagine if you didn't. Consider a test that tries to verify that given X input you get Y output.

If you write a single test for this, you might be confident that when you input X, you do get Y out.

But, what if you input Z and still get a Y out when you shouldn't?

You probably also need a test for Z input too.

Actually, even having two test cases probably isn't enough.

If you're testing more than a simple boolean input, there are a lot more cases that you should probably be testing too.

I thought this went without saying.

I guess not. 

So now, I've said it.

This looks like a NuGet bug - but isn't

Error NU1301 The local source '[PATH]' doesn't exist.

I recently reported a bug where I was trying to use an updated version of a NuGet package. When I specified a new version of that package (in Directory.Packages.props), I got build errors complaining about a path to another project in the solution.

I got the error message shown above, but the path was relative to another project in the solution.

Very odd.

Why would the newly updated package version do anything with the referenced path?

It turns out it didn't.

But, it took me two days, and then the answer popped into my head while walking back from the shop, to explain what was happening.

A couple of days earlier I'd been testing the package created by another project in the solution.

To do so, I'd created a local package source that pointed to the output path of that project. [Those of you paying attention will have already guessed that this is also the path from the error message that started all this.] Then in a different solution, I could load my test project and add a reference to the package I'd built for testing.

All was good. I tested that package and carried on with my work.

Here's an example of the package source I created for testing. [Ignore the parts that are obscured. They're not relevant.]

See the path I'm setting in the image: "c:/source/MyProject/Release".

If this path doesn't exist when creating (updating) the source entry you get a helpful error message:

That's a good, clear error message. It clearly makes known what's wrong.

Now, guess what happens if that path exists when the source is created but is later deleted.

It's a reasonable scenario. Create a local package source for testing and then later delete the directory when testing is finished.

Or rather than explicitly delete it, maybe you reset a branch, and that causes the path to be deleted.

That's what I did.

Then, a few days later I try and add a version of a package I've never used before.

And that's when I got the error.

So, what's going on?

Well, what I assume is happening is that before downloading a new version of the package, it checks all the configured sources to see if it exists in any of them. It (the download manager) doesn't know that the package only exists on nuget.org and quite rightly checks all configured options before downloading something again unnecessarily.

Except, in my situation, it's now trying to look in a directory that no longer exists which causes an exception.

There's an argument that it might be good to add an option to ignore local sources that don't exist but I expect that to be likely to also cause a number of obscure exceptions that aren't obvious to diagnose.

I expect if I had tried to use the UI to update the package version rather than directly editing the props file I'd have got a different (and probably more helpful) error message. - [Actually, I've just checked and  it's the same error message but seeing that I'm using ALL Package sources may have helped me spot what's wrong.]

So, not a bug in the package I was trying to use, and not a bug in the projects that reference that package.

If anything, this is just a limitation of options for testing a package locally and poor error messages.

Or it's me being an imposter for thinking I knew how to use Visual Studio and NuGet. 

Or, it's me being stressed and making silly mistakes with configuration.

Or, it's another reason for someone to complain about my code. There's been a lot of that recently. :(

Or maybe it's a reminder for all of us to only keep local NuGet package sources enabled while they're needed.

Review: Learning WinUI3 (2nd edition)

I bought a physical copy of the first edition.

I was given an electronic copy of this (2nd) edition.

I twice tried to post a review on Amazon but they refused it based on unspecified "community guidelines".

Here's what I tried to say:

Probably the best book available on learning to develop with/for WinUI3. 

This updated version provides a comprehensive introduction to WinUI3 development and the broader required knowledge to help gain a firm grounding in its use.

The new and updated chapters help keep the book relevant with a platform and ecosystem that has evolved since the release of the first edition.

If you want to learn about WinUI3 from a book (rather than videos, etc.) then I recommend this one.

Amazon link