I look at my Azure bill each month and cannot make heads or tails of it because each service I use in Azure is so broken down into such fine pieces that it makes no sense to me. I mean take a function, you pay for the memory it consumes, the CPU cycles it consumes, the bandwidth it consumes, and the total number of times it is executed each month. Come the fuck on! How much finer can you break a service down and charge separately for each component and then charge excessively for each component and then advertise it as a single item?

Seriously! I have spent the last month talking to Azure Sales, Microsoft Partner Solutions (I’m a partner I must admit), and Azure Billing trying to get an accurate quote for 4 C# functions executing 14,400,000 times a month consuming less than 128MB ram and using less than 512MB of bandwidth a month. After a month my answer is that no one CAN TELL ME! I was taken aback by that and told to try the pricing calculator after being told in a round-robin fashion to talk to so and so and then that person would refer me to another section and they would refer me back to another section that I had talked to two weeks earlier. It is just sad that they are billing this stuff and the people who are selling it and generating the billing statements don’t know how to generate a quote based on numbers calculated by their own pricing calculator LOL!

It all goes back to my post title, cloud companies have micro-segmented everything they sell down so far to their basic components and are charging outrageous prices for each and then advertising them as a whole package with no price tag on it. They just say, “Hey we got Serverless Functions! They’re easy to set up and use!” They don’t tell you that they are gonna bill you out the ass for each individual little piece that makes up the total function in that pitch or that they can’t honestly quote you an accurate price other than say get on a pricing plan and pray you don’t go over and end up paying Consumption Tier Pricing for going over your cap.

Apps are going the same way with micro-billing and features but I’m not going that way with mine. I’m going subscription in order to keep them updated and be able to keep my backends up to date and development environment current but I think I charge a reasonable price. That is what I am trying to do now with my upcoming app to bring the subscription cost down to a reasonable cost but Azure will literally eat 75% of the revenue generated from the individual subscription as it currently stands and I can’t bring the cost down enough to really make it more appealing to the end user. That is fucking sad.

Four C# functions should not cost $9500 a month for just an estimated 1000 users…… even when it takes them only 6 seconds to execute a task per user, per function…….ever…..

John

I had some issues at first with compiling after doing my first migration from Xamarin to .NET MAUI with Mobile.BuildTools but I went back to some of mother other apps and found my old solution to a new problem.

The nuget works great in MAUI and I am more comfortable with it than some of the newer methods to keep secrets out of your source. So here is a quick overview of what it takes to configure it and get it working in your .NET MAUI or Xamarin app.

Understanding the configuration file for the nuget is key. There are some subtle things in the config that need to be set properly in order for it to work right. Here is an example config for your to look at.

So in the JSON file the basics I commented on are to set the project name, class name (I made a folder called Helpers and put “Helpers” there in that spot), and root namespace of the app. Then you can enter in your secret NAME/TYPE pairs, so it can be a string or whatever. Generally, it will be strings for your secrets but what you name them here is a reference in the actual secrets file itself.

The secrets file should be named after the class name you defined in your JSON file. So if you called it AppSecrets then you would name your secrets file “appsecrets.json.” Pretty straightforward forward but it can lead to problems later on that are hard to figure out without some debugging. In your secrets file you use the NAMES defined in your config as KEY/VALUE pairs in it and it is formatted in ordinary JSON format like below.

Now in code, you refer to your secrets by the Class Name then a dot then the Secret Name you input into your config. So you would refer to ApiKey as “AppSecrets.ApiKey.” So in your code, you can refer to it like this, “var myapikey = AppSecrets.ApiKey.”

The rest can be ignored if you are not using the full capabilities of Mobile.BuildTools.

If you run into a compile error complaining about build tools that refer to some weird message about build properties, here is what you need.

Name it like in the gist and then place that file with your .sln file in the root of your project so MS Build can find it. Then the error should go away, I don’t remember the exact specifics of it but the file remedies that.

So you might circle back to it to see what’s been added!

It’s not well documented and I had to scrape stuff together from several sources and post on a couple of different forums but I have a working foreground service that puts up a notification in the notification tray that is tappable to reopen the app after you close it. Here is the code to enable it by file in your project:

They are out of order for some reason but first, you want to create the interface in the root of your project called IService.cs with two methods Start and Stop. Just copy the example and adjust the namespace. After that is done, in your android folder create the foreground class, name it what you want but use the inherited interface and Service class. Once that is done, edit MauiProgram.cs to add the entries I have in the example for the service, the property, and the two builder services, and then end as I have it where it calls those services and then calls app. On your home page make a property referencing the service and then also a reference to them in the constructor as well to initialize the service.

At this point, you can either call it through a button or have it launch automatically however you want it from that page or whichever page you choose.

Now I am assuming you are only targeting Android in your project, if you are not then your need to create dummy classes in your other project folders that reference the IService interface so that there are no issues and then in whichever page you choose to launch the service from use:

#if ANDROID #ENDIF around the Service.Start()/Service.Stop() to isolate to just Android or if you were smart and blackhole the interface references in your other classes’ implementations then don’t worry about it 🙂

John

Edit!

You need one more thing if you’re targeting Android 13 and up. That would be the Post Notification permission and getting that from the user. Currently .NET MAUI essentials doesn’t have that built in but if you dig into the docs on Microsoft you’ll find out how to create an extension class to add it. Also, in your AndroidManifest.xml you need to add the following:

Then just do like normal before starting the service, check for the notification permission and request it if it’s not granted.

Edit 2!

If you’re building a Shell App and you see a crash when bringing the app off the back stack then here is the work around!

In your MainActivity.cs add Launchmode = Launchmode.SingleTop where I have it in the example below and it should go away.

Edit 3!

Found this this morning during debugging! In your AndroidManifest.xml in the Application section add the following entry.

android:enableOnBackInvokedCallback=”true“

John

[wpedon id=3183]

If you were like me and trying to figure out how to implement the new entitlement to get the iOS and iPadOS Device Name Entitlement to work then look no further!

First after you get your entitlement approval, go to the developers portal and go to your apps Identification entry and a new tab for entitlements will have showed up. There you will find the UIDevice.Name entitlement. Check it and save it. Then go to your profile for development and deployment and just save them again to ensure the new entitlement are attached with the ID is secured to the profiles. I’m not sure if you need a new development and deployment certs but I would revoke the old ones and just make a new set to be sure.

Once that is done, go into the key chain on your Mac and delete the old certs and install the new certs. Export P12’s and import them into your Visual Studio IDE (I would clean out the old certs first under %APPDATA%/Local/Xamarin/iOS) so that is has them as well on the Windows side and reimport the profiles from the developer portal. I would reimport the profiles into XCode and also VS Mac as well.

Once that is done, on your Mac/Windows machine edit your Entitlements.Plist and add the following line to it:

<key>com.apple.developer.device-information.user-assigned-device-name</key> <true/>

Do a clean and you should be able to do a build and see the device name now if all went well. I went through so many iterations of trying things and not finding information on the internet for doing it through MAUI that I hope that I have guided you in the right direction!

John

The short answer is maybe and the long answer is no. I started my next project totally Xamarin but when the news hit that although they were not sunsetting it until the end of 2023, the last big update to Xamarin.iOS was the last.

So it quickly turned into a .NET MAUI project and the conversion process is not a “day long” event like Microsoft put in their blog. It was more like a month and spending 1700 bucks on new MAUI controls. So, no Microsoft it’s not a day to convert.

Speaking of controls Telerik needs to lower their price because what you’re getting is in beta at best.

App Center support is alpha at best and not all features implemented. And don’t even think of targeting .NET 7 either as they only started working on supporting 6.

So my summary is they pushed .NET MAUI as fast as they could leaving all the support entities behind. I mean really it’s like the control and other providers are playing catch-up and .NET MAUI just plows on leaving what makes an app complete in the dust.

John

After thought for me is AppCenter is a big mess and barely supporting. NET 6. They are never going to catch up with .NET MAUI. Crashes is weird and Analytics is throwing an exception whenever called. I’ve submitted bug reports on them, hopefully they’ll get fixed.

Azure SSM is nearly complete, just lacking queue support. I plan on doing that in December as there doesn’t seem to be much to it. Also, I’ll be converting it to MAUI since they have really killed Xamarin for good.

In the mean time I have been busy raising funds and working on my next big project. Is gonna be really nice I think.

John

The SDK is not the best to code against but they’re in the app now and it’s two thirds complete with the finish line coming in December with the final storage component to add.

I’ll be releasing it this week once I get directions and media done for the Share support. So be on the lookout for an update soon.

It will be important with File Shares to read the documentation as nested directories cause certain issues to arise and very specific procedures for dealing with moving and deleting them.

John

We have entered Phase II of development with the addition of File Shares support. I’m currently building out the backend right now but it will take about a month to be up to a beta version of the full release with blob and shares support in tandem!

John