DEV Community: Tim Heuer

Deploy a Blazor WASM site to Azure Storage using GitHub Actions

Tim Heuer — Wed, 18 Dec 2019 21:50:44 +0000

I’ve been spending a lot of time looking at the GitHub Actions experience for .NET developers. Right now I’m still using Azure Pipelines for my project, Alexa.NET, in building, testing, and deploying to NuGet. As the tools and process for using DevOps tools for CI/CD have so vastly improved over the years, I’ve become a huge advocate for this being the means for your build/deploy steps…YES, even as a single developer or a smaller team. It simply really helps you get to a purer sense of preserving the ability for your code to live on, for others to accurately build it, and for you to have peace of mind that your code works as intended. I’m just such a huge fan now. That said, I still think there is a place for ‘right-click publish’ activities in inner-loop development. In fact, I use it regularly for a few internal apps I’ve written. For simple solutions that method works well, but I certainly don’t think I can right-click-publish a full solution to a Kubernetes environment though. I’m currently researching new tooling ways to help those ‘publish to CI/CD’ from Visual Studio (would love your opinions here) so I’ve been spending a lot more time in GitHub Actions. I decided to look at publishing a Blazor app to Azure Storage as a static site…here’s what I did.

Setting up the Storage endpoint

The first thing you need is an Azure Storage account. Don’t have an Azure account, no worries you can get a Free Azure account easily which includes up to 5GB of Azure Blob Storage free for the first 12 months. Worried about pricing afterwards? Well check out the storage pricing calculator and I’m sure you’ll see that even at 1TB storage it is cost-effective means of storage. But any rate, you need a storage account and here are the configuration you need.

First, you may already have one. As a developer do you create your infrastructure resources or are these provisioned for you by infra/devops roles in your company (leave comments)? Earlier this year at Build we enabled static website hosting in Azure Storage. You first create a Storage resource (ensuring you choose v2 which is the default, but that is the version that enables this feature). After you create your resource scroll on the left and you’ll see ‘Static website' section. Here’s what the configuration looks like and let me explain a few areas here:

All of this configuration is under the Static website area. First you obviously need to enable it…that’s just toggling the enabled/disabled capability. Enabling this now gets you two things: 2 endpoints (basically the URI to the website) and a specific blob contianer named $web where your static content needs to live. The endpoints default map to this blob container without having to add a container name to the root URI. Remember the resource group you’ve given to your storage instance here, you will need that later.

NOTE: You can later add CDN/custom domain to these endpoints, but I’m not covering those here.

The second thing you need is to set a default document and error page. The default document for your SPA is your root entry point, and for most frameworks I’ve seen this is indeed index.html. For Blazor WebAssembly (WASM) apps, this is also the default if you are using the template. So you set the default document as ‘index.html’ and move on. The error document path is another interesting one…you need to set this for SPA apps because right now the static website capability of Azure Storage does not account for custom routing rules. What this means is that storage will throw an HTTP 404 error message when you go to something like /somepage where it actually doesn’t exist but your SPA framework knows how to handle it. Until custom routing works on Azure Storage your error document becomes your route entry point. So for this set the error document path to also be index.html for Blazor WASM.

NOTE: Yes this isn’t ideal for routing. On top of that it still does show an HTTP 404 actual network message even though your route is being handled. Azure Storage team has heard this request…working on advocating for y’all.

That’s it. Now you have a storage endpoint with a blob container that you can begin putting your content in and browse to using your endpoint URI provided from the portal. For a simple tool to navigate your storage, I’ve been using Azure Storage Explorer and it is intuitive to me and works well to quickly navigate your storage account and containers (and supports multi-account!).

Setting up your Azure Service Principal credentials

The next thing you will need is a service principal credential. This will be used to authenticate with your Azure account to be able to use DevOps tools to work on your behalf in your account. It’s a simple process if you have a standard account. I say this only because I know there might be some configurations for environments where you yourself don’t have access to create service principals and may need someone to create one on your behalf, or also there might be credentials you can already use. Either way here is the process I used.

I used the Azure CLI so if you don’t have that installed go ahead and grab that and install it. This should now be in your PATH environment and using your favorite terminal you should be able to start executing commands. To start out, login to the CLI using `az login` – this will launch a browser for you to authenticate via your account and then issue the token in your environment so that for the remainder of your session you’ll be authenticated. After logging in successfully running `az account show` will emit what subscription you are using and you’ll need the subscription ID later so grab that and put it somewhere on your scratch notepad for later command usage.

NOTE: If you have more than one subscription and have not set a default subscription you should set that using the `az account set` command.

Now you can use the CLI to create a new service principal. To do that issue this command:

az ad sp create-for-rbac --name "myApp" --role contributor \
                            --scopes /subscriptions/{subscription-id}/resourceGroups/{resource-group} \
                            --sdk-auth

Note on line 2 here that you need to replace {subscription-id} with your own actual subscription id (the GUID) and {resource-group} with the resource group name where your storage account is located. On line 1 the “myApp” can be anything but I recommend making it meaningful as this is basically the account name of the principal. The output of this command is your service principal. The full JSON output. Save this off in a place for now as we’ll need that later to configure GitHub Actions properly. Great now to move on to the app!

Create your Blazor WASM app

I assume since you may be reading this far you aren’t new to Blazor and probably already have the tools. As of this writing, Blazor WASM is still in preview so you have to install the templates separately to acquire them to show up in `dotnet new` and in Visual Studio File…New Project. To do that from a terminal run:

dotnet new -i Microsoft.AspNetCore.Blazor.Templates::3.1.0-preview4.19579.2

Then you will be able to create a new project. I’m showing Visual Studio here and this is the WASM template:

In the dialog here you will see Blazor WebAssembly App and that’s what you will use. Now you have a choice to have it ASP.NET Core hosted using that checkbox, which if you were going to do other things in ASP.NET maybe that’s what you want. For the purposes of this article we are talking about just having the WASM app and having a place to host it that isn’t a web server with other content…just hosting static content and using storage to do so…so we aren’t checking that box. The result will be a Blazor WASM app with no host. Now let’s add that to GitHub. If you are using Visual Studio 16.4+ you’ll be able to take advantage of an improved flow for pushing to GitHub. Once you have your project, in the lower right click ‘Add to Source Control’ choosing Git and then you’ll see the panel to choose GitHub and create/push a repo right away. You don’t have to go to GitHub site first and clone later…all in one step:

Great! Now we have our WASM project and we’ve created and pushed the current bits to a new GitHub repository. Now to create the workflow.

Setup the GitHub Action Workflow

Now we’ve got an Azure Storage blob container, a service principal, a Blazor WASM project, and a GitHub repository…all set to configure the CI/CD flow now. First let’s put that service principal as a secret in our repository. In the settings of your repository navigate to the Secrets section and add a secret named AZURE_CREDENTIALS. The content of this is the full content of your service principal (the JSON blob) that we generated earlier:

This saves the secret for us to use in the workflow and reference as a variable. You can add more secrets here if you’d like if you wanted to add your resource storage account name as well (probably a good idea). Secrets are isolated to the original repository so no forks get the secrets at all. Now that we have these let’s create the workflow file.

Today, Visual Studio isn’t too helpful in authoring the YAML files (would love your feedback here too!) but a GitHub Action is just a YAML file in a specific location in your repository: .github/workflows/azure-storage-deploy.yaml. The file name can be anything but putting it in this folder structure is what is required. You can start in the GitHub repo itself using the Actions tab and through the online editor get some level of completion assistance to help you navigate the YAML editing. Go to the Actions tab in your repository and create a new workflow. You’ll be offered a starter workflow based on what GitHub thinks your project is like. As of this writing it thinks Blazor apps are Jekyll workflows so you’ll need to expand and either find the .NET Core one or just start from a blank workflow yourself.

Four my workflow I want to build, publish and deploy my app. I’ve separated it into a build and deploy jobs. You can read all about the various aspects of GitHub Actions in their docs with regard to jobs and other syntax as I won’t try to expound upon that in this article. Here is my full YAML for the entire workflow with some key areas highlighted:

name: .NET Core Build and Deploy

on: [push]

env:
  AZURE_RESOURCE_GROUP: blazor-deployment-samples
  BLOB_STORAGE_ACCOUNT_NAME: timheuerblazorwasm

jobs:
  build:
    name: Build
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v1
    - name: Setup .NET Core
      uses: actions/setup-dotnet@v1
      with:
        dotnet-version: 3.1.100

    - name: Build with dotnet
      run: dotnet build --configuration Release
    
    - name: Publish with dotnet
      run: dotnet publish --configuration Release 
    
    - name: Publish artifacts
      uses: actions/upload-artifact@master
      with:
        name: webapp
        path: bin/Release/netstandard2.1/publish/BlazorApp27/dist

  deploy:
    needs: build
    name: Deploy
    runs-on: ubuntu-latest
    steps:

    # Download artifacts
    - name: Download artifacts
      uses: actions/download-artifact@master
      with:
        name: webapp

    # Authentication
    - name: Authenticate with Azure
      uses: azure/login@v1
      with:
        creds: `${{ secrets.AZURE_CREDENTIALS  }}`

    # Deploy to storage using CLI
    - name: Deploy to storage using CLI
      uses: azure/CLI@v1
      with:
        azcliversion: latest
        inlineScript: | 
          # show azure account being used
          az account show
          # az storage account upload
          az storage blob upload-batch --account-name `${{ env.BLOB_STORAGE_ACCOUNT_NAME }}` -s webapp -d \$web
          # az set content type of wasm file until this is fixed by default from Azure Storage
          az storage blob update --account-name `${{ env.BLOB_STORAGE_ACCOUNT_NAME }}` -c \$web -n _framework/wasm/mono.wasm --content-type application/wasm

So a few things going on here, let’s talk about them.

Lines 5-7: these are ‘local’ environment variables I set up. The storage account name is NOT the blob container name but the actual storage account name. This ideally probably should be a Secret as mentioned above. Environment variables can be set here and then placeholders reference them later.
Starting at line 9 is where the ‘build’ portion is here. We checkout the code, acquire the SDK and run the build and publish commands. On line 26-30 is a step where we put the publish output to a specific artifact location for later retrieval of steps. This is good practice.
Lines 40-42 is where we are now in the ‘deploy’ step of our CD and we retrieve those artifacts we previously pushed and we set them as a name ‘webapp’ that the later will use in deployment
Line 45 is where we are going to first authenticate to Azure using our service principal retrieved from the Secrets. The ‘secrets’ object is not something you have to define and is part of the workflow so you just add the property you want to retrieve
Line 51 is where we start the deployment to Azure using the CLI commands and our param ‘webapp’ as the source. This is the CLI command for uploading batch to storage as described in the docs for `az storage blob upload-batch`
Line 61 is an additional step that we need for .wasm files. I believe this to be a bug because there is logic in the CLI to correctly map the content-type but for some reason it is not working…so for now you need to set the content-type for .wasm to `application/wasm` or the Blazor app will not work

This is made possible through a series of actions: checkout, dotnetcore, azure…all brining their functionality we can draw on and configure. There are a bunch of Azure GitHub Actions we just released for specific tasks like deploying to App Service and such. These don’t require CLI commands but rather just provide parameters to configure. Because there is no Storage specific Action as of now, we can use the default CLI action to script what we want. It is an enabler in lieu of a more strongly-typed action. Now that we have this workflow YAML file complete we can commit and push to the repository. In doing that we now have a CI/CD action that will trigger on any push (because that’s how we configured it). We can see this action happening in my sample repo and you can see since we separate it in two jobs it will show them separately:

Summary

So now we have it complete end-to-end. And subsequent check-in will trigger the workflow and deploy the bits to my storage account and I can now use my Azure Storage account as a host for my static website built on Blazor WASM. This full YAML sample flow is available on my repo for this and you can examine it in more detail.

I would love to know how y’all are coming along using GitHub Actions with your .NET projects. Please comment below!

(this article cross-posted from timheuer.com)

Building and Customizing the new Windows Terminal

Tim Heuer — Tue, 14 May 2019 16:02:03 +0000

I don’t like C++. There I said it…got it out of the way. It’s not a fair statement, as I know many people who do and think I’m crazy for not only writing code in C++. As someone who didn’t come from a traditional computer science background, I just never ‘grew up’ on C or C++ as fundamentals.

NOTE: You can hear more about my journey (and others) to tech on the awesome CodeNewbie podcast. Here’s my episode right here: From police recruit to developer.

Go ahead, insert ‘you’re not a real programmer’ comments below. I’ve established enough thick skin over the years to hear that feedback. Anyhow, I digress. While I’m not a fan of C++ it really isn’t about the language but the iteration dev loop. I’ve often found it slower than what I’d like and the mix/match of toolsets, settings, etc. has left a lot to be desired to me. HOWEVER, all this said, looking at C++ code is an excellent way to learn and to actually appreciate more the language and code that others write. No better source of learning development exists than code.

Last week at the Microsoft Build conference a fun new project was unleashed to the developer community…a new Windows Terminal. AND it is Open Source!

I’ve never seen as much excitement about a terminal app in this ecosystem as I have the past 10 days. So much fun. First, here’s the team that brings you the Windows Terminal project:

Dear #Build2019 physical and virtual attendees & tweeps - thank you for attending our talks, visiting our booth, and asking/posting tons of great questions & comments. We appreciate you all.

With love from the #WSL and #Terminal teams

Until next year 😜 pic.twitter.com/VayHovDnNJ
— Rich Tur-minal-ner-d (@richturn_ms) May 8, 2019

Great people, passionate about making Windows a great development environment for no matter what you are developing. This is also the team bringing you WSL and the new capabilities there! So you want to try out the terminal…your first question is Where can I get it?

Building Windows Terminal

Well, for now it is source only. This will likely change over the course of the next few months, but for now if you really want to try it out, you need to build it yourself. The repository on GitHub has all the bits and instructions for you to do so. I jumped on this right away like others but ran into a few bumps because I was using Visual Studio 2019. Luckily this has been solved by this PR to help make the scavenger hunt for dependencies less painful.

SIDE NOTE: If you have an open source or team-based project, do yourself a favor and add a .vsconfig file now. Details: Configure Visual Studio across your organization with .vsconfig

Basically the steps are:

put your machine in developer mode
ensure you have some Git tools
ensure you have the C++ tools (compilers, etc.) (Visual Studio Community Edition is free to download/install and works)
clone the repository
update the submodules
build the repo (using VS or the tools\bcz script)

If you use Visual Studio 2019 (recommended by me) opening the OpenConsole.sln file should prompt you with a screen that will give you a note to ‘install’ the missing dependencies in the Solution Explorer:

If you click Install it will run you through the missing components you may not have enabled for completing the build. Finish that process. Once done, you will have all the bits and can go back to the OpenConsole.sln project and choose ‘Build Solution’ and start the process. Lots of stuff building for the first time so it will take a bit. Now what?

Deploying/Running Windows Terminal

Building is step 1, now you want to run it. Windows Terminal is a Universal Windows Platform (UWP) application and must be deployed first. The easiest way for doing this is from Visual Studio, but you may want to know what project!? The Terminal\CascadiaPackage project is the one you want and just right-click on that and choose Deploy. This will deploy it to your machine (assuming you enabled developer mode). And this will now be in your start menu:

Click/tap/whatever on that and you will launch Terminal for the first time!

Wait, where are the tabs I saw?

Ah, now that you have it running, let’s take a tour. The settings right now are a JSON file that you can access via the settings menu. How do you get the settings menu? Hit CTRL + T to bring up the tab view and then you should have a drop-down menu in the upper right area:

If you click Settings it will open up the profile.json file in the default editor on your machine configured for editing JSON files. For me this was Visual Studio, but you can use Code or other editor as well. This is editing your own profile for your terminal environment. By default this JSON is void of white-space so you may want to format it to make it more readable. In Visual Studio that is CTRL + K, CTRL + D and it will prettify it for you. You’ll then see some initial settings in the top of the file:

{
  "defaultProfile": "{a933a071-2a32-42c9-b03a-550845793252}",
  "initialRows": 30,
  "initialCols": 120,
  "alwaysShowTabs": true,
  "showTerminalTitleInTitlebar": true,
  "experimental_showTabsInTitlebar": false,

If you change line 5 here like I did to true then you will always start with tabs even if only one console host is running. When you save the profile.json file it will re-format to no whitespace FYI (there is a watcher on the file in the code) but the settings will become immediate.

Navigating the profile.json options

The profile file main meat is in the profiles themselves. These drive what shells/consoles you can launch and their configuration. For example here is a snippet of what mine looks like right now a bit:

{
  "defaultProfile": "{a933a071-2a32-42c9-b03a-550845793252}",
  "initialRows": 30,
  "initialCols": 120,
  "alwaysShowTabs": true,
  "showTerminalTitleInTitlebar": true,
  "experimental_showTabsInTitlebar": false,
  "profiles": [
    {
      "startingDirectory": "c:\\users\\timheuer\\documents\\github",
      "guid": "{b056b6a8-89ba-4868-86c6-2ea078cd4fdd}",
      "name": "cmd",
      "colorscheme": "UbuntuLegit",
      "historySize": 9001,
      "snapOnInput": true,
      "cursorColor": "#FFFFFF",
      "cursorHeight": 25,
      "cursorShape": "vintage",
      "commandline": "cmd.exe",
      "fontFace": "Cascadia Code",
      "fontSize": 12,
      "acrylicOpacity": 0.75,
      "useAcrylic": true,
      "closeOnExit": true,
      "padding": "0, 0, 0, 0",
      "icon": "ms-appdata:///roaming/cmd-icon.png"
    },
    {
      "startingDirectory": "c:\\users\\timheuer\\documents\\github",
      "guid": "{a933a071-2a32-42c9-b03a-550845793252}",
      "name": "PowerShell",
      "background": "#0C0C0C",
      "colorscheme": "UbuntuLegit",
      "historySize": 9001,
      "snapOnInput": true,
      "cursorColor": "#FFFFFF",
      "cursorHeight": 25,
      "cursorShape": "vintage",
      "commandline": "powershell.exe",
      "fontFace": "Meslo LG M for Powerline",
      "fontSize": 12,
      "acrylicOpacity": 0.75,
      "useAcrylic": true,
      "closeOnExit": true,
      "padding": "0, 0, 0, 0",
      "icon": "ms-appdata:///roaming/powershell_64.png"
    },

While I don’t have all options enabled a little spelunking the source code helps you know what other options exist:

name: the name of the particular profile. Right now this is what shows in the drop-down menu shown previously. There is an issue logged to perhaps make this the name of the tab as well.
guid: the unique identifier of this profile. Incidentally if you didn’t know and wanted to create your own profiles and need a GUID, VIsual Studio has a “Create GUID” tool available from the tools menu…choose registry format and then copy/paste
colorscheme: this maps to the color scheme for this area…which is an array of colors that maps to the various foreground/background/text/highlight/etc. settings that are also configurable. You can see in your profile file that Campbell and a few others (Solarized Dark/Light) are pre-configured. You can use iterm2colors values to create a new scheme.
foreground: the foreground, duh (overwriting colortable/scheme)
background: the background, duh (overwriting colortable/scheme)
colortable: an in-line version of the color array that would be within a scheme
historySize: I honestly haven’t looked at this one yet in the code to know
snapOnInput: I honestly haven’t looked at this one either
cursorColor: color of the cursor style you chose
cursorShape: different options to show the cursor: vintage (thick underscore), bar (vertial bar), underscore (thin underscore), filledBox, emptyBox
cursorHeight: height for the cursor
commandline: the command to run for the profile (full path or something that will be found in PATH)
fontFace: the fond to use for this profile. You may see in mine that I am using ‘Meslo LG M for Powerline’ to get the cool customizations of the prompt. Find more on how to do that here and it works in Windows Terminal

Note: the team will also be open sourcing a new font that will be used for the terminal, but is not yet available as of this post

fontSize: size of the font
acrylicOpacity: the opacity of the window if you choose to use the acrylic (transparency) feature. value from 0-1
useAcrylic: true/false if you want to use the transparency
scrollbarState: hidden/visible are the options
closeOnExit: true/false if you want the tab to close when you initiate the exit command for your host
padding: this affects some of the output but honestly not working well right now, recommend leaving at 0,0,0,0
startingDirectory: the startup directory for this profile. I have mine configured with my github directory where all my code is instead of $home (which is default)
icon: an icon that will show in the menu and the tab. These live in your RoamingState directory (C:\Users\<yourusername>AppData\Local\Packages\WindowsTerminalDev_8wekyb3d8bbwe\RoamingState) and the format for the value is “ms-appdata:///roaming/<yourfilename>”

For now these are the available options that you should fitz around with to customize what you need to change. I’ve messed around with these enough and got to where I want them to be for me right now.

Navigating the source and contributing

As I started this post about how I didn’t like C++, it is a good place to learn a lot. The Windows Terminal source is a maze of someone else’s code and right now without a clear map. So the best way is to really just dig in and follow a particular flow. I find this is the best way to navigate any project source code: find one feature and try to find and follow it in the code. For me, I was messing with the settings file so much and I hated using the menu with my mouse I wanted a keyboard shortcut. I knew that CTRL + T launched a new tab, so hey I could implement a keyboard shortcut to launch the settings file quickly. I first logged that feature as an issue on the project: Add keybinding for access to Settings and then went to work. I knew that the new tab shortcut existed so I took my own advice: follow the code! After a few tries and navigating all the headers and various code files I submitted a PR to the project for my own issue: PR#684. There were 6 files changed to add this key binding and if you look at the change I proposed, there was already a function I could call (same one the menu uses) and I really just needed to map the key binding and have it call the existing function. Simple, but I learned a bit of how the current code is structured in the repository.

So my recommendation would be to find something that you are seeing as a piece of existing functionality or something you want to add yourself and start looking at searching for where you think it might be. You’ll quickly find out some of the structure around TerminalSettings, TerminalCore, TerminalControl, etc. and play around with making some changes. Keep in mind this is active development and things will change around quite frequently. The team even indicates much:

⚠ Note: The Command-Line Team is actively working out of this repository and will be periodically re-structuring the code to make it easier to comprehend, navigate, build, test, and contribute to, so DO expect significant changes to code layout on a regular basis.

I have already been bitten a bit by a merge, but no big deal just fix up a few things and move along again!

What’s Next?

The team has a good aspiration of what they want to accomplish and just getting started. Quality will improve, bugs will get fixed, consumption of the terminal will be better, etc. Read the README file in the repository and engage with the team on Twitter (their contact info in the README).

Hope this helps!

(this article cross-posted from timheuer.com)

How I solved Jessica’s NYC Parking Problem with Twitter, Twilio and NO CODE

Tim Heuer — Fri, 19 Apr 2019 13:49:41 +0000

I’ve been reading a lot of great content on dev.to lately (seriously you should go check it out and follow some tags…great community there) and came across this great headline “How I Solved My NYC Parking Problem With Python, the Search Tweets API and Twilio” by Jessica Garson, a Developer Advocate at Twitter. Jessica was trying to solve a problem that NYC folks have when trying to determine when to move their street-side parked cars each night due to ‘alternate side regulations’ which determine when certain sides of roads can be used or the regulations won’t be enforced due to holidays, events, whatever.

She delved into using Python, the Twitter Search APIs and Twilio to tie these all together. Fun problem to solve and results in a text to Jessica whether she needs to worry about moving her car or not. Immediately after reading it I though of the game show Name That Tune.

The premise of the game show is that contestants battle it out to who can identify a song based on the fewest amount of notes in a song. So of course, it is 100% applicable to code, right? Anyhow I thought to myself Self, I can solve this problem in less effort and with NO code!

Immediately I went to work using Azure Logic Apps. Azure Logic Apps are a means to…well, let’s let the marketing people tell us what they are:

Azure Logic Apps simplifies how you build automated scalable workflows that integrate apps and data across cloud services and on-premises systems.

Lots of buzzwords there but basically it’s workflow/orchestration platform that allows you to use ‘connectors’ between various inputs and outputs. Logic Apps can be developed using code, but most are easily developed using no code and using the graphical connector tools. If you’ve ever used/heard of Microsoft Office Flow this is powered by Azure Logic Apps underneath! So immediately after reading the article I went to work. I knew that Azure already had pre-build connectors for Twitter and Twilio and that I should be able to do this easily. Connectors are pre-defined pieces of logic that help get access to events, data, and actions across other apps and platforms, in our case Twitter and Twilio!

Jessica’s problem was fairly simple: Watch when the @NYCASP account tweets and if it indicates rules are ‘suspended’ then alert her with a text message. Now this relies on @NYCASP account being consistent in their tweets and it turns out they are VERY consistent in them, so it’s easy to search for the simple terms as Jessica did. So let’s do the same.

To get started I needed an Azure account which is free to get started and there are a ton of services free that you can use forever. I also still needed a Twilio account like Jessica notes so you still need that to get your Twilio credentials…be sure you have that. With both of these in hand, let’s log in to the Azure Portal….we won’t even need any tools other than a browser to complete this app!

In the portal you’ll create a new resource in Azure…search for Logic App and it will show up:

You’ll need to provide a name, choose a resource group plan and a geographic location where you want this to live. If you’ve never created any Azure resources before, a resource group is a container for certain compute resources to leverage. For this, I recommend creating an App Service resource group and using a free plan that comes with your free trial account. Then you can use this resource group for your Logic App. Once you have that created navigate to that resource and you will see a page that welcomes you with a tutorial video and some options for pre-configured templates. Thankfully one of the starting options is “When a new tweet is posted” so let’s use that one to help us get started as it will default add the Twitter connector!

This dumps us into the Logic App designer, a graphical interface that helps us do the connections. You’ll immediately see the first ‘trigger’ which is our Twitter one and it wants you to sign in to be able to use the functionality (think of this as authorizing use of the API). Once you sign in click continue and you’ll get the options. Now basically we want to look for when a new tweet is posted by @NYCASP on a time interval. Their account is pretty consistent so I chose every four hours and used the ‘from:@NYCASP’ query language as the search text.

That’s it for Twitter. No code successfully so far! So now every 4 hours this will check for a new tweet from that account. Now let’s do something with it! In Jessica’s scenario we need to look at the tweet and act upon it only if a specific condition was met. So let’s use that little “+” symbol on the designer and add a new action. Search for 'Condition’ and you will see ‘Control’ come up as an option…select that, then you will see the Condition connector…choose that. The condition connector gives us a simple decision tree: what is the condition, what do you want to do if true, what do you want to do if false:

In the condition area where it says ‘Choose a value’ when you click in to there, data from the previous trigger will be made available to you and you can see all the details it exposes! We will scroll and look for Tweet text and select that. Change the oeprator to ‘contains’ and type in ‘suspended’ as the value. It should look like this:

Now we know that the tweet is telling us something about suspending…but Jessica wants to know if she has to move her car for tomorrow. Let’s add another condition to now check to see if it contains ‘tomorrow’ in the text. We follow the same steps in creating a new condition trigger and connecting it.

At this point we have a nested condition. Could we have put them in the same one? Probably, but I’m just following similarly Jessica’s flow.

It should look like this:

Now we know if both of those are true we need to send a text message. Click the ‘Add an action’ button in the True condition and search for Twilio and select the ‘Send a Text Message’ action. This will add the provided Twilio connector which provides this functionality (and more). Similarly like twitter you will see it and after selecting have to authenticate to your account to get the credentials.

After doing that you now simply enter the details of your text message. For Twilio the From number must be your account SMS number unless you have premium services that enables you to do something more. If you try to get fancy without premium services from them, this will fail. Don’t get fancy…we’re just moving cars across the street remember? Enter the text you want to send and to the phone number you want to send it to…done!

Now on the false conditions we do still have to tell the Logic App what to do. In these cases, unless you want to do more, again add an action and choose System, then look for ‘Terminate’ – it’s a simple action that basically just stops the flow and can log a message. I configured mine like this on BOTH false conditions:

That’s it, I’m done. No code. This took me longer to write this post then it did to actually do the Logic App the first time. Now I waited. And waited. And waited. I completed the logic app right after reading Jessica’s article and wanted to ‘naturally’ test this with the real deal tweets. But no parking regulations were suspended. My logs looked like this:

UNTIL A FEW DAYS AGO! My phone buzzed, I looked down and BOOM:

I wonder if Jessica got a text message too! I was so happy and I don’t even live in NYC or have to worry about moving my car to a different side of the street! The logs of Logic Apps are pretty cool as well and also graphically follow your flow and show you input/output state along the way:

So with no code and only a few steps to authenticate to Twitter and Twilio, I was able to use only a browser and complete the same task. Did I win Name That Tune? Who cares…doing software isn’t a competition, it’s fun and we get to use the tools and technology we feel most productive with. For me, this was just a gut reaction to see if could be done as easily as I thought and indeed it could. So yeah I won :-D.

Check out more about the pieces I used to put this together and get your custom logic apps working:

Azure Account – get one free
Azure Logic Apps (docs/tutorials)
Twitter connector
Twilio connector
Azure App Service (for the resource group)
Over ~200 built-in connectors provided for Logic Apps!

Hope this helps!

(this article cross-posted from timheuer.com)

Make people trust your NuGet Packages more with code signing!

Tim Heuer — Fri, 05 Apr 2019 15:58:36 +0000

Like most things in life, this all started with someone’s message on Twitter.

Blogged: Why NuGet Package Signing Is Not (Yet) for Me. https://t.co/4RSes2Bo4r
A close look at NuGet package signing feature, where it's useful, and in which ways it falls short.
— Boom Haackalacka (@haacked) April 3, 2019

You can code-sign a NuGet Package? I don’t know why I didn’t know that other than I figured I had no idea that I should care or have even given a second thought to it. But Phil’s article and subsequent discussion on Twitter made me just realize I should take a look at the flow. After all more sage wisdom from Phil kicked me over the edge:

There’s no harm to anyone if you do sign your package.
— Boom Haackalacka (@haacked) April 3, 2019

You’re right Phil, and how can you argue with that forehead…so let’s do this.

What is NuGet? NuGet is a package management system that was primarily developed for .NET developers and has now become a de-facto package/release mechanism for that ecosystem. What npm is to Node.js developers, NuGet is to .NET developers. More info at https://www.nuget.org.

I’ve got a little library for helping .NET developers be more productive with creating Alexa apps, Alexa.NET. When I started this project I used to just have this on my local box and would build things using Visual Studio and manually upload the NuGet package. Then people made fun of me. And I ate my sorrows in boxes of Moon Pies. Luckily I work with a bunch of talented folks and helped me see the light in DevOps and helped me establish a CI/CD pipeline using Azure DevOps. Since then I’ve got my library building, a release approval flow, automated packaging/publishing to the NuGet servers. I simply just check-in code and a new version is released. Perfect. Now I just want to add code-signing to the package. Naturally I do what every professional developer does and Google’d went to read the docs about code signing NuGet packages. Luckily there is some pretty good documentation on Signing NuGet Packages!

The first thing you need is a code-signing certificate. There are many providers of these and different prices so pick your preferred provider. I chose to use DigiCert for this one but have used other providers in the past. The process for getting a code-signing cert is a bit more than just an average SSL certificate so be sure to follow the steps carefully. Once you have that in place, export the DER and PFX versions as you will need both of these for this process. Your provider should provide instructions on how to do this for you.

Next up was to modify my Azure DevOps Pipeline. I do my NuGet activity in a Release pipeline after a successful build and an approval step to actually complete the deployment. My simple release pipeline looks like this:

The signing is provided by the NuGet CLI and so I just needed to add another task to this flow right? I added another one in and was going to just choose the ‘sign’ command as the configured option. Well, the ‘sign’ command isn’t a selectable option in the task. There is a request to make this one of the default options for the Azure Pipeline Task right now but it isn’t in there yet. So for this we will use the ‘custom’ option which allows us to pass in any command and args. The docs already told me the commands that I would need: a certificate file being the minimum I would have to have. Hmm, how am I going to have a certificate file in my CD pipeline?! As it turns out there is a secure file storage in Azure Pipelines I can use! This allows me to upload a file that I can later reference in a pipeline using an argument. Remember that PFX file we exported? In your DevOps project under Pipelines there is a ‘Library’ menu option. Going there takes you to where you can upload files and I uploaded my PFX file there:

The next thing I need to do is also provide my password for that exported PFX file (you did export it with a password right!). To do this I made use of variable groups in Azure DevOps, created a group called CertificateValues and added my name/value pair there, marking the value as a secret. As a variable group I can ‘link’ this group to any build/release definition without explicitly having the variable in those definitions. This is super handy to share across definitions. You can now link to an Azure KeyVault for secrets (more to come on that in a part 2 blog post here). I’ve got my code signing cert (PFX) and my certificate password stored securely. With these two things now I’m ready to continue on my definition.

Now how will I get the file from the secure storage?! As I read in the docs, there is a Download Secure File task that I can add to my pipeline. The configuration asks me what file to use and then in the Reference Name of the Output Variables area I give it a name I can use, in this case ‘Certificate’:

This variable name allows me to use it later in my definitions as $(Certificate.secureFilePath) so I don’t have to fiddle around guessing where it downloaded to on the agent machine. Now that we have that figured out, let’s move back to the signing task…remember that ‘custom’ one we talked about earlier. In the custom task I specify in the Command and Arguments section the full command + arguments I need according to the docs. My full definition looks like this:

sign $(System.ArtifactsDirectory)\$(Release.PrimaryArtifactSourceAlias)\drop\*.nupkg 
    -CertificatePath $(Certificate.secureFilePath) 
    -CertificatePassword $(CertificatePassword)  
    -Timestamper http://timestamp.digicert.com

To explain a bit I’m using some pre-defined variables System.ArtifactsDirectory and Release.PrimaryArtifactSourceAlias to help build the path to where the drop folder is on the agent machine. The others are from the secure files (Certificate.secureFilePath) and variable group (CertificatePassword) previously defined. These translate to real values in the build (the secret is masked in the logs as shown below) and complete the task.

Here was my log output from today in fact:

2019-04-04T19:10:44.4785575Z ##[debug]exec tool: C:\hostedtoolcache\windows\NuGet\4.6.4\x64\nuget.exe
2019-04-04T19:10:44.4785807Z ##[debug]arguments:
2019-04-04T19:10:44.4786015Z ##[debug]   sign
2019-04-04T19:10:44.4786248Z ##[debug]   D:\a\r1\a\_Alexa.NET-master\drop\*.nupkg
2019-04-04T19:10:44.4786476Z ##[debug]   -CertificatePath
2019-04-04T19:10:44.4786687Z ##[debug]   D:\a\_temp\timheuer-digicert.pfx
2019-04-04T19:10:44.4786916Z ##[debug]   -CertificatePassword
2019-04-04T19:10:44.4787190Z ##[debug]   ***
2019-04-04T19:10:44.4787449Z ##[debug]   -Timestamper
2019-04-04T19:10:44.4787968Z ##[debug]   http://timestamp.digicert.com
2019-04-04T19:10:44.4789380Z ##[debug]   -NonInteractive
2019-04-04T19:10:44.4789939Z [command]C:\hostedtoolcache\windows\NuGet\4.6.4\x64\nuget.exe sign D:\a\r1\a\_Alexa.NET-master\drop\*.nupkg -CertificatePath D:\a\_temp\timheuer-digicert.pfx -CertificatePassword *** -Timestamper http://timestamp.digicert.com -NonInteractive
2019-04-04T19:10:52.6357013Z 
2019-04-04T19:10:52.6357916Z 
2019-04-04T19:10:52.6358659Z Signing package(s) with certificate:
<snip to remove cert data>
2019-04-04T19:10:52.6360408Z Valid from: 4/4/2019 12:00:00 AM to 4/7/2020 12:00:00 PM
2019-04-04T19:10:52.6360664Z 
2019-04-04T19:10:52.6360936Z Timestamping package(s) with:
2019-04-04T19:10:52.6361268Z http://timestamp.digicert.com
2019-04-04T19:10:52.6361576Z Package(s) signed successfully.

Done! Some simple added tasks and reading a few docs to get me having a signed NuGet package. Now re-reading the docs on signed packages I have to upload my certificate to my NuGet profile to get it to be recognized. This time I only need to provide the DER export. Once provided and my package is published, I get a little badge next to the listing showing me that this is a signed package:

This was a good exercise in helping me learn a few extra steps in Azure DevOps working with files and custom task variables. Immediately as I was doing this, my friend Oren Novotny couldn’t help but chastise me for this approach.

I am
— Oren Novotny (@onovotny) April 3, 2019

So stay tuned for a secondary approach using Azure KeyVault completely to complete this without having to upload a certificate file.

(this article cross-posted from timheuer.com)