Azure App Configuration service

The other day I was asked if it’s possible to put objects, arrays, etc as the value for a configuration variable. Hm… Good question.

Figured, how about JSON to the rescue? And it worked.

I created a simple .NET Core console app that reads a JSON string from Azure App Configuration service and parses the JSON into an int array.

In App Configuration service…

  • The Key name is: foo

  • The json string looks like this: {“value” : [0,1,2,3,4]}

  • I set the Content type to JSON, but that isn’t required.

The output from the program is:
this is a test: {"value" : [0,1,2,3,4]}
element is: 0
element is: 1
element is: 2
element is: 3
element is: 4

The sample program is located in my GitHub repo here.

Here are a couple of handy references:

Enjoy!

New domain name servers

I just now created a DNS Zone in the Azure portal to take care of Snowstormlife.com. Then I copied the name servers from Azure and updated the ones in GoDaddy. Didn’t take long at all.

Grabbed the name servers in the Azure Portal
image

And updated the ones on GoDaddy…
SNAGHTML1f5371b8

Big change of direction…

Over the past two weeks I’ve been doing a lot more AKS studies, which included this excellent MS Learn content. It walks you through creating an well-featured AKS cluster, soup to nuts. You owe it to yourself to take a look.

But I’ve also been doing a lot of studying of the Microsoft Power Platform, specifically Power Apps, Power Automate, and Power Virtual Agents. No code, low code environment, which sounds nice and easy, but the learning curve has been larger than I expected. I recently found a bunch of YouTube videos that I’m working my way through.

Anyway, that’s been taking up a lot of my time. Soooooo, I decided to shift gears regarding this AKS project.

Miniblog is a nice engine, but all my content is currently at jimblizzard.wordpress.com. I didn’t want to have to try to migrate all my old posts into Miniblog, so I used the WordPress bitnami image and threw it into an AKS cluster, and pointed my old domain name snowstormlife.com at it. I then exported all my wordpress content from wordpress.com and imported it into snowstormlife.com. Worked like a charm. These instructions gave me a great head start. And I pointed Open Live Writer to it so I can compose from my laptop. Easy peasy.

I still need to . . .

  • [] create a post about my adventures in converting Miniblog into docker-able source code and putting it into an AKS cluster
  • [] create a post about creating the Azure DevOps pipeline from the Azure DevOps Service in the Azure portal – 5 minutes and done. Maybe a video would be better, since writing all the stuff down would take a lot longer.
  • [] and a few other odds and ends.

So, head on over to SnowstormLife.com and enjoy. . .

A new domain. . .

I mapped my old domain name snowstormlife.com to the app service plan. So there’s another item for the TODO list once I get external storage set up:

– [] Copy all the blog posts from jimblizzard.wordpress.com over to snowstormlife.com.

I’m not Scott…

Scott Hanselman has very good guidance on his website here and here about setting up a home environment for webcasts, video recording, etc. I wanted to use my iPhone for my camera input to Camtasia running on my Windows PC. I found a way, made a recording, and put it on YouTube. And no, I’m definitely not Scott. Winking smile

Baby steps on the journey . . .

The site in it’s brand-new-baby form is alive and running in a Linux container-backed Azure website here. Again, just getting started with it, so nothing fancy at this point. I’ve learned a ton of stuff just getting this far — not just following some hands-on lab or quickstart tutorial, but having to look things up and try things out. Lots to blog about. I’ve been keeping a blog for forever on WordPress, but I’m going to use the new site to blog about this process.

Also, I used the Azure Portal’s DevOps Project feature to create the site with a docker container backing it, Azure Container Registry, an Azure DevOps CI/CD pipeline linked to this GitHub repo, etc. It took only 5 minutes to stand it up by answering 5 simple questions. (I’ll eventually put the blog in a Azure Kubernetes Service cluster, but I have a bit more learning / work to do so I don’t leave it hackable. 🙂

Update 2020.05.11 – I’m not going to keep snowstormlife.cloud. I’m too cheap to pay that much every year. 🙂 I’ve decided to revive my old domain name snowstormlife.com. I also bought a custom domain name, Snowstormlife.cloud, where it lives. Current next steps are to create external storage for the blog so it doesn’t get blown away with each new container deployment. It’s currently using storage within the container, which isn’t good. As in, when I commit this change to master and the CI/CD pipeline runs, it’s going to blow away the container and anything I’ve posted on the site. 🙂 And I need to add an SSL cert to the site so it can do https…..

Snippets in VS Code

I just discovered how to create snippets for VS Code. All this time I’ve been living without them. Why didn’t I look into this before? I don’t know.

To create / edit snippets, in VS Code, press Ctrl+Shift+p then type “snip”

To edit your snippets, select Preferences: Configure User Snippets, then select the snippets file or create snippets

In WSL Ubuntu, my c# snippet config file is located here: /home/jim/csharp.json

Here’s an example of a couple that I created:

{

    // Place your snippets for csharp here. Each snippet is defined under a snippet name and has a prefix, body and 

    // description. The prefix is what is used to trigger the snippet and the body will be expanded and inserted. Possible variables are:

    // $1, $2 for tab stops, $0 for the final cursor position, and ${1:label}, ${2:another} for placeholders. Placeholders with the 

    // same ids are connected.

    // Example:

    // “Print to console”: {

    //  “prefix”: “log”,

    //  “body”: [

    //      “console.log(‘$1’);”,

    //      “$2”

    //  ],

    //  “description”: “Log output to console”

    // }

    “Property”: {

        “prefix”“prop”,

        “body”: [

            “public ${1:type} ${2:MyProperty} {get; set;}”

        ],

        “description”“Create a property with ‘private type varName {get;set;}'”

    }

    “PropertyFull”: {

        “prefix”“propfull”,

        “body”: [

            “private ${1:type} ${2:myVar};”,

            “”,

            “public $1 ${3:MyProperty}”,

            “{“,

            ”   get { return $2; }”,

            ”   set { $2 = value; }”,

            “}”

        ],

        “description”“Full property with private backing”

    }

}

After you save the file, in the VS Code editor for your C# project, simply type the snippet prefix, such as “prop” or “propfull” then press tab and fill in the values

 

Snippets are such handy things…..

 

There are a bunch of topic-specific config files available for use, too. For more info, see: https://code.visualstudio.com/docs/editor/userdefinedsnippets

 

Enjoy!

 

And don’t forget to wash your hands.

 

.

 

VSTS–Mac build agent fail restoring NuGet packages

Heads up if you’re running VSTS build agent on a Mac for Xamarin.Forms iOS projects.

You may see this error message from the NuGet package restore step:
”To connect to NuGet feeds hosted in your Team Services account/TFS project collection with NuGet 3.1 or below, edit your build definition to specify a path to a NuGet.config containing the package sources you wish to use.”
 
And this error message in the agent’s _diag log file on the Mac:
                MsBuild.exe does not exist at ‘/Library/Frameworks/Mono.framework/Versions/4.4.2/lib/mono/4.5/msbuild.exe’.
 
It’s a closed issue on GitHub, but you’ll need to do a workaround.
 
See https://github.com/Microsoft/vsts-tasks/issues/2828 for details. The issue was opened about 10 days ago.
 
I hadn’t changed anything with my build definition, source code, or build agent, but the build failed this morning. (It had been a couple of weeks since I’d run it, and it had always worked before. Quite a surprise.
 
I ended up putting this in the VSTS NuGet package restore step and it resolved the issue for me:

2016-10-17_10-26-36

Note from Joe Sauve:

You can also use:
“/Library/Frameworks/Mono.framework/Versions/Current/lib/mono/nuget/NuGet.exe”

Note the “Current” instead of a specific version number. There should be a symlinked “Current” folder in there that always points to the most recent version.

Thanks Joe!

bliz

Android Keystore file and password in VSTS builds

I was on site with a client last week working with them on DevOps for Xamarin.Forms builds using VSTS. The question came up of what to do about the Android Keystore file and its password – where to put them, keep them safe, etc.

Keystore file
If you’re running the build agent on a local build server (or Azure VM), the keystore file can be placed in a secure location on the build server. If you’re using the hosted build controller the Keystore file could be put into source control with limited access given to that file.

Keystore file password
For the Keystore file password, create a private variable in the Android build definition . Once the variable is set it cannot be displayed again. Then set the permissions in VSTS so only those who have Build Edit permissions can change this variable, and restrict who you give those permissions to accordingly.

clip_image001
The build step with a reference to the Keystore file in VSTS source control and a variable for the password.

image
The Keystore password saved as a Variable in the build definition.

Then you’ll need to set the security on the Build itself to limit who is allowed to edit the build definition.

image

image

And that’s it. Setting up the VSTS build in this way will keep the Keystore file and password safe in your Xamarin Android build definitions.

Enjoy!
–bliz

Building cross-platform Xamarin.Forms apps in VSTS

The other day I wanted to create a DevOps CI / CD pipeline for a simple Xamarin.Forms app that I’d created. The Visual Studio solution contains project files for the PCL, Android, iOS, and UWP projects. The CI / CD pipeline would include VSTS for source control, build, and release, my Mac for the actual compile and packaging of the iOS app, and HockeyApp for beta version management and beta user management. It’s not that difficult to set up, but there are a few places where it would be easy to get hung up.

For my Xamarin.Forms project I created three VSTS build definitions, one for each platform. This allowed me manage the pipeline for each platform separately. Two separate build agents are required to build the solution. The Hosted Pool and Agents can build for UWP, Android, and a number of other platforms, but they can’t build for iOS. A different Pool and Agent has to be set up for iOS, pointing to a Mac environment such as MacInCloud, or to your local Mac.

The solution in Visual Studio needed three Build Configurations: one for Android (without UWP or iOS), one for UWP (without Android or iOS), and one for iOS (without Android and UWP).

VSTS Agents and Build Definitions

So with that, let’s take a look, first with the VSTS Build setup. . . (FYI, I’m currently not using Release Management to publish the app to HockeyApp. I’m going to add that process later.)

I downloaded an Agent to my Mac and configured it to run using a pool other than the Hosted pool. I chose to use default pool. In the following image you can see that I have a number of Agents defined in the “default” pool. “MIC_VSTS_snow…” is set up to use MacInCloud. The other three point to different Agent configurations on my local Macs. (I’m going to write a future post about how I configured the Agent on my Mac.)

image

I defined a User Capabilities variable for each Agent so my build definitions could demand which particular Agent to use from the default pool. For instance, I created a User Capability called MacinCloud for the agent associated with MacInCloud. I created a Capability called NewMac for one of the agents that lives on my MacBook Pro.

image image

In the VSTS build definition I added a Demand for “NewMac” “exists” so it will run a particular agent on my MacBook Pro. (You can have multiple agents running on your Mac if you want to, and point to them this way.)

image

In my build definition I also created a variable called BuildConfiguration so I can identify which which Build Configuration in the VS solution I want the VSTS build to use. (I’ll show those settings in VS in just a bit.)

image

I pointed the build to my Xamarin project repo and set it to have a continuous integration trigger. In the Build Task I used the $(BuildConfiguration) variable for the Configuration.

image

I set up the Android and UWP VSTS build definitions similar to the iOS definition. Biggest difference was that I was able to use the Hosted agent.

Visual Studio Build Configuration

Let’s take a look at the Build Configuration in Visual Studio next.

As I mentioned I created three VS build configurations to be used by the three VSTS builds, “iOS Release”, “Android Release”, and “UWP Release”. In the VSTS build definition for iOS above, I used the “iOS Release” configuration. Here’s the definition in Visual Studio. The “XamarinFormsIosAndroid” project is the PCL project, and the “XamarinFormsIosAndroid.iOS” project is, yep, the iOS project. Notice that the Droid and UWP projects are not set to build (checkboxes are unchecked) in this configuration.

image

For the Android and UWP build configurations I took the same approach: build the PCL project and the .Droid or UWP project as appropriate. Here’s the screenshot for the Android build. Notice that I left the “Deploy” checkkbox unchecked for the .Droid project. There’s no need to deploy it during the Build task in VSTS.

image

And that’s pretty much it…. at least as far as setting up the build goes.  : )

I haven’t shown it here, but you can add a step for Xamarin Test Cloud (automated testing) and a step for deployment to HockeyApp (for beta distribution and user management). Or even better, create a Release Management definition to handle the deployment to HockeyApp. More about those topics in a future blog posts.

References

Here are some references you’ll probably find useful when setting up your VSTS builds for Xamarin.Forms.

Enjoy!
-bliz