Spent the Sunday from (7:30 this morning – 18:30) dealing with build problems on Visual Studio for Mac – trying to build Maui. I built perfectly at 7:30 then something went horribly wrong (all code changes were rolled back, but that didn’t matter)
I have mentioned before that the dotnet tooling in VS 17.xxx on Mac it totally unpredictable and the quality of the Studio and plugins is mysteriously horrible.
So for the sake of web-indexing this article, “Is dotnet Maui production ready?” Absolutely not on Mac. Building solutions in Blazor (webassembly and server) is doable on mac using Visual Studio Code. Get used to work without code completion and strange indexing error and help in the UI – but with a deep barrel of patience – it is doable. (Have been developing in the Microsoft stack since 2002 and the current situation is the worst I have seen)
Can you develop Maui on Mac yet? Absolutely not! Dealing with build errors and strange behaviours in the build cache and some kind of memory caching is ok when you have a long-running development support community. Bugs tend to get fixed and internal testing usually covers developers ass when it comes to introducing new bugs on every change. Not so much the case with this environment.
My favorite build error of the day is that if you choose to embed a config file in a subfolder (e.g. /Resources) it results in this build error.
/usr/local/share/dotnet/packs/Microsoft.iOS.Sdk/16.4.7054/tools/msbuild/iOS/Xamarin.Shared.targets(3,3): Error: /usr/bin/codesign exited with code 1: /Users/myname/Code/MyCode/clients/com.mysolution.mobile/com.mysolution.mobile/bin/Debug/net7.0-ios/ios-arm64/com.mysolution.mobile.app: code object is not signed at all In subcomponent: /Users/myname/Code/mysolution/clients/com.mysolution.mobile/com.mysolution.mobile/bin/Debug/net7.0-ios/ios-arm64/com.mysolutionxmobile.app/Microsoft.CSharp.dll (com.mysolution.mobile)
The tail of the stack is irrelevant – just depends on what dlls are included. Tracing this to the embedded file took a long time … and left me writing this banter of an article to share sympathy with anyone in this situation.
If you are thinking about going with Maui on Mac – don’t! (I have no clue if it works on windows)
If you are stuck with Maui like me – tough luck! LOL 🙂
I am developing in dotnet every single day. For the last 18 months (approx since August 2021) I have been doing Blazor front end and for the last month I took the chance on MAUI as my PWA was not living up to my expectations. All this is is working with my dotnet REST API.
MAC is my development environment by choice. Long story short – I haven’t looked back since I tried MAC hardware in 2014. I used to work with Paralell – using Windows to develop on my Mac but since dotnet became available on Mac – I started to work exclusively on macOs.
I have done most of the development with VS Code – as VS 2022 wasn’t work ready but moving into MAUI and mobile development this is no longer an option.
The problemssss ….
Microsoft continues to deliver versions of Visual Studio for Mac – and from late last fall they started giving it names like Release Candidate and even Release – even though one could not rename or move files properly.
The whole time the parsing of Razor files has resulted in the infamous spinning wheel of death – for up to 52 seconds (the longest I measured) when just editing HTML tags.
The release notes continues to list fancy stuff which is of no value to the every day developer until the basic things are fixes and we can work 60 minutes of our hour – not work 20 minutes and wait 40 minutes.
The latest (preview) release (I also use the stable release channel) features an unusable project reference editor – meaning that the list of project references seems to have no connection what-so-ever with the contents of the actual XML in the project file – listing the project references the compiler is actually working with. This cost me several hours yesterday (Sunday) trying to figure out what the hell was actually going on – the compiler complaining about missing and incorrect references.
For me – the problem is quite obvious – there is nobody on the Microsoft Test Team actually working on real live projects using VS 2022 for Mac – the bugs they release – bear every indication that nobody at Microsoft is actually doing real Blazor and Maui development using this tool. They might be updating the demos and testing out some simple stuff – but nobody is actually doing real live refactoring with VS 2022 for Mac.
Please, please …
… Microsoft – make your development team use this product – we are dying of productivity losses over here in the real world. The excitement about Maui will evaporate quickly if it cannot be developed properly on Mac. Front end developers don’t work on Windows – they work on Mac and MAUI will never gain traction if you don’t fix these basic things properly.
In Visual Studio 2019 Mac – while building Theory based tests, using input object array
This will work perfectly
Trying to be a bit more robust (as we now property names will change) , replacing the static “Index” with something like nameOf() won’t work, resulting in the test disappearing of the radar in the test manager. This probably makes perfect sense (not allowing non-static variables in the Theory) – but I think the test manager (or VS somehow) should warn about this … ? 🙂
Just stumbled across my 2004 MS thesis – “A Case Study into the Effects of Software – Process Improvement on Product Quality” – as study into the effects of agile project process maturity on the types of defects that surface in a software product. Still interesting stuff (at least some of the principles discovered) almost 20 years later 🙂 #scary
When creating web applications, we all try to create good SEO tags in the header of each page. Modifying the meta tags based on page content is a standard practice. In Blazor, this is not obvious as the _host.cshtml is rendered before the Blazor execution pipeline.
There was a tag extension in the preview of Blazor 5 which didn’t make it into the release and there are no news if this is continued or not (just a note from a program manager that this didn’t make it into the release) … so I guess this will be solved across the board in next release …. ? 🙂
This works nicely if you make sure to use server prerendering as explained in the documentation. The default setup options result in (at least) the Facebook screen scraping does not collect the updated title and meta elements, but only the original ones (which are the site static default ones).
Google Authentication on my Blazor app worked locally but not live – hosted @DigitalOcean in Ubuntu Docker Containers.
Locally I was working https using devcerts and the https on the DigitalOcean droplet was faked using Cloudflare’s (super-nice) security features (where they basically hide your website behind ssl without any certificate installation.
I switched between two problems during my trial-error process
The google authentication callback came back to http (not https) – which my server is designed not to handle
If I directed the callback (using Auth parameters) to use https – the server responded with some Cookie not found messages and Exception: Correlation failed. (Probably due to the fact that the cookie was produced by http://
The solution process
So I thought I would document the process in case I have to do this again (which I already have – as I had to do this for the api server as now my domain Cloudflare settings requires all the domain servers to have a valid (self-signed at least) certificate.
4. Copy the cert into the cert folder (Ubuntu specific)
sudo cp site.crt /usr/local/share/ca-certificates
5. Update the certs reading on the host
6. Move the pfx into a /mnt folder on the host (as that folder will be mapped by the docker container and the certificate read during app startup)
cp site.pfx /mnt
7. Now the host has the certificate and trusts it – but the docker container does not. My strategy here is to do all this through command line when I start the dotnet core container. This might not be the industry standard, but it worked for me
For 3 hours I was dealing with the title error nothing seems to work until I read the answer from hikrikunen where the key was deleting the localhost certificates in the system keychain and then running
dotnet dev-certs https –clean
dotnet dev-certs https -t
Uptil the point of deleting the localhost certificates, the dotnet dev-certs commands were not getting me anywhere, telling me that there was no cert available, but refusing to add because there was a certificate available. Strange but I don’t understand fully what happened but now my API can be run on https locally again 🙂
Fun discovery of the day … when building Blazor – having a Pages subfolder called System will completely mess upp the application build.
Renaming the folder to SystemX (or anything else for that matter) will make those errors disappears 🙂
This is possibly a result of some local coincidence … but I can reproduce this over and over again – and there are no changes in my project file or any other project files. Made my day … feels like I have discovered an Easter Egg in Blazor 🙂