Certs are gonna get ya!

But not on Azure App Service. I just found a great feature of Azure's App Service and that's the ability to get a free SSL/TLS certificate for your custom domain names ... for FREE

Yeah, I couldn't believe it either, so I just tried and it worked fabulously and without issue. You will need to have a validated custom domain on your app service (but why would you try to do this if you didn't) and then it all just works. The only things to note are:

• No naked domains (e.g. http://example.org won't work but https://www.example.org is fine)
• No wild cards (but you can create one certificate per custom domain)
• Needs a Basic plan at a minimum to use certificate

This is truly awesome and a big plus to Azure App Service as I always felt like adding a custom domain only got me half way to where I wanted to be, because a custom domain without https was not quite good enough. Prior to this you couldn't secure the domain without paying to get a certificate or venture into the world of Let's Encypt (a great service but ultimately a little bit of work). Now you can literally have your custom domain and secure it too.

More details at https://docs.microsoft.com/en-us/azure/app-service/configure-ssl-certificate if you're interested.

Blazing a Trail - C# in the Browser

I realized, after re-reading, that I've been referring to Blazor when I should really be talking about Blazor WebAssembly. The other form of Blazor is Blazor Server. That's not what I'm writing about here.

I didn't come to .Net very willingly, I resisted the Microsoft technology stack quite strongly back in the day, when they were very monopolistic and I didn't like the lock-in that I felt when you entered their walled garden (I still don't like the Apple walled garden either, in case you're wondering). But something started to happen at Microsoft just before and since Satya took the reins. They started to contribute to open source and build tools for other platforms. They were contributing to projects and being (apparently) collaborative rather than combative where their tools overlapped with existing ones.

And one of the biggest places I saw this was in web tooling. Visual Studio started to consume some of the biggest and best open source web tools (Nodejs, Grunt, Bower, etc.). These were tools that web developers were already using in their own projects and which, I think, Microsoft realized were good quality and would actually ease the transition for many developers into a more Microsoft world.

And that adoption and acceptance of non-Microsoft tools hasn't slowed down. In some cases it has meant that the tools become part of the Microsoft (Github) and in other cases it has meant relying on tools produced by other giants in the technology space (SharePoint relies heavily on ReactJS from Facebook). This shows, to me at least, how Microsoft has changed over the past 10 years.

But this isn't a post about Microsoft, it's about web technologies and Blazor in particular.

Blazor? - It's Building a Web App in C# (literally)

But first, let's talk briefly about WebAssembly (WASM), a technology that essentially bypasses JavaScript to provide a new and highly flexible way to run code in a browser. Unlike competing languages (Dart) for the web, WASM instead provides the ability to run compiled code in a browser. WASM lives and works like the virtual machine in the JVM or the runtime in the CLR. If you compile your code against WASM then it will run in any compatible browser. It's the browser/web version of a virtualized CPU it is an assembly language for the web :o I wonder if that's how the figured out the name...?

So I've still not go to Blazor. Ha, that's because I think the introduction is needed so you grok what WASM is so that you can actually believe what follows and how it can be true. To me, it still feels incredible that I can do the things of which I am going to speak.

So I said you can compile whatever you like to WASM, so someone at Microsoft decided to try and compile the .Net runtime (the Mono runtime actually). And then what do you get? Well, you get a compiled output file (mono.wasm in this case) which can be downloaded into the browser and which will then run just like the .Net runtime does on any other platform (almost). Which means that I now have code, running in a browser, that can execute DLLs; the very same DLLs that I can run locally on my Windows machine.

I'm sorry to labor the point but these are C# programs compiled just like any other. They don't include any JavaScript, there's no transpilation, they are POCOs built using MSBuild and they can be run like any .Net code you could build. The only thing that's different is that with the browser version, they are executed by the Mono WASM runtime and not the .Net Framwork.

To me, that's huge.

So, Blazor?

Right, Blazor. Well now you appreciate the "What" about Web Assembly, then Blazor is your "How", the means to get it all working and get some value.

Blazor is the blending of Browser + (a hidden "L" that crept in there) + Razor

It's a framework for building web applications using C# and only C#. You can write components (a little bit like ReactJS components) in C# and consume them in C# and use Razor to integrated C# with HTML. If you're a C# ASP.Net or Web API developer already, you can just use the tools you already know.

I'm not going to go into detail on how the Blazor framework works, the documentation on MS docs is good and getting better all the time. The developers are active on Github, where the project (as part of ASP.Net Core) is being built, and seem to be very active engaging with the community. If you want to give it a go, check out the Get Started page in the docs and note that you will need to install .Net Core 3.1 to get Blazor WebAssembly.

I'm not sure what the long term viability of Blazor is, but I'm hopeful that WebAssembly will allow developers to explore real alternatives to running code in the browser. I'm excited to see what they come up with.

Don't forget your firewall settings

I've been working with migrating and discussion forum application into Azure over the past few months and yesterday ran into a perplexing issue when working from my computer on my home network. Using the .Net client library I was trying to connect to my database and kept receiving the error

Entity with the specified id does not exist in the system.

Which was most perplexing as it was all working fine earlier and I could browse the data via the Azure Portal. After much wailing and gnashing of teeth, I remembered that I had set the firewall on the CosmosDB to only allow Azure services and my work IP address (if you don't meet the IP address the REST call receives a 404 hence the 'does not exist' phrase in the error message). Adding my home address and waiting a few minutes soon meant that I was on my way.

So if you are getting this error and wandering why a database or collection that you know exists is returning this error, check your firewall ;)

Caught myself loving on an MS service

Now this isn't an opinion/emotion I am very familiar with, not being unkind to Microsoft, but I find (or have found) a lot of their services 'acceptable' but given a choice I would often go elsewhere. Not so today.

Today, I was speaking to a colleague who is a .Net programmer but who chooses to use a mixture of the Atlassian stack and Github for; source control, issues, discussion, code reviews etc. After hearing how the various parts of this stack are integrated (or not) and the hoops that are jumped through the get the thing to just work (and the resulting fagility of the system) I asked if he'd looked at VSTS.

Now I realise VSTS doesn't cover all of the aspects of the process that he is using, but talking to him about what it could do and how it could integrate with, for example Github if you really wanted to continue to use that for source control, without compromising the rest of the product integration, I found myself being very supportive of the platform.

And I think what really struck me was that Microsoft have done such a great job in making VSTS so flexible and capable. Use your own source control, use your own build agents, use your agents inside your own network and deploy to Azure or deploy to in-house servers, it's all possible and embraced by VSTS.

You even have the ability to build your own custom build and release steps if you feel so inclined! And the ones that are available are all on Github to be inspected and reviewed.

Well done Microsoft, you've given me a first and I am pleased to speak on behalf of VSTS in future. Keep up the good work.

Provisioning Virtual Directories using ARM Template in Azure

This is as much a means to record what to do as to post a blog, but I recently ran into a requirement to deploy web packages to an Azure Web App using MSDeploy where the packages were to be uploaded to virtual directories/applications. The web app was being deployed using Azure Resource Manager (ARM) and I was struggling to find the correct syntax on how to define these directories.

After some searching I found this answer from David Ebbo with a PowerShell way of doing the same thing and wandered if I might modify this to work inside an ARM template.

https://social.msdn.microsoft.com/Forums/azure/en-US/990f41fd-f8b6-43a0-b942-cef0308120b2/add-virtual-application-and-directory-to-an-azure-website-using-powershell?forum=windowsazurewebsitespreview#0435503d-032e-429d-93ff-e106be04f556

It turns out that you can and the answer is quite straight forward. Rather than using the PowerShell structure, define your 'props' as JSON instead and since this is deploying a resource type of 'Microsoft.Web/sites/config' the whole configuration struct can be placed inside your website section as follows:

{
"type": "Microsoft.Web/sites",
"name": "[variables('requestSiteName')]",
"apiVersion": "2015-08-01",
"location": "West Europe",
...
"properties": {
"name": "[variables('requestSiteName')]",
...
},
"dependsOn": [
...
],
"resources": [
{
...
},
{
"apiVersion": "2015-08-01",
"name": "web",
"type": "config",
"properties": {
"virtualApplications": [
{
"virtualPath": "/",
"physicalPath": "site\\wwwroot"
},
{
"virtualPath": "/foo",
"physicalPath": "site\\bar"
}
]
}
}
]
}

Updating Publishing Page attribute in SharePoint Online

We have moved over to using the Patterns and Practices approach to SharePoint site deployment, with the exception of a few older or more complex .wsp based sites and for one product we are using post-provisioning tasks to modify the values of a custom content type based on values passed through PnP by storing them in the property bag.

Initially, the site template we were using was a vanilla Team Site, however, it was deemed necessary to enable publishing to achieve certain goals. Once this was done, we needed to checkin/checkout/publish the page in order to make and save the changes. This was failing with the save operation complaining that the page was checked out. Initially I was shouting at SP because I knew the page was checked out, because I had asked for it to be, however, it seems that this wasn't the checkout SP was referring to.

Finding this post on Stack Overflow (http://sharepoint.stackexchange.com/questions/59177/check-out-update-then-check-in-a-file-in-sharepoint-client-object-model) it seems that the flow needs to be:

• Check out
• ExecuteQuery()
• Modify
• Update()
• ExecuteQuery()
• Checkin
• Publish
• ExecuteQuery()

When we did this the page was successfully updated. One thing that I additionally did was to wrap the checkout/executequery in a try/catch so that if the page was already checked out, it would carry on and run the update. However, this will probably only be a solution if the user who has the page checked out is the same as that running the current update.

Credential Error with VS 2015 multiple accounts

Strange one, but I was trying to log in to my personal MSDN Azure subscription from Visual Studio 2015 in order to deploy a web app, something I've done many times before, and it asked me to refresh my credentials. However, every time I tried, I would receive the error

"We could not refresh credentials... multiple_matching_tokens_found" (or something along those lines, apologies I didn't get a screen shot).

So Googling I found the following issue which was closed as 'Not Reproducible', but in this case I could reproduce, and I followed the suggestions.

https://connect.microsoft.com/VisualStudio/feedback/details/1052566/multiple-matching-tokens

Can you try one of the following workarounds to see if your issue is resolved?

1. Go to https://msdn.microsoft.com/en-us/library/vstudio/dn872465(v=vs.140).aspx, and follow the instructions described under "Add a second user account to Visual Studio" to open the Visual Studio Account Manager
2. In the Visual Studio Account Manager, remove the accounts used to access the affected Azure subscriptions shown under the "All Accounts" section of the dialog
3. Re-add the accounts you had just removed
4. Close the Visual Studio Account Manager
5. Try using your Azure subscription again

If that does not resolve your issue:

1. Close Visual Studio
2. Open the Windows File Explorer
3. Go to %USERPROFILE%\AppData\Local\Microsoft\VSCommon\VSAccountManagement
4. Rename or delete the AdalCache.cache file
5. Restart Visual Studio
6. Try using your Azure subscription again, and enter your account credentials if prompted

For me, the second option, deleting the credential cache worked.

I just wanted to record this somewhere as there are obviously some people suffering from this but it's unlikely to be solved.