Could not load file or assembly 'System.Runtime, Version 6.0.0.0' with .Net Core

 It’s the story of couple of days back, where as usual I deployed my application on Azure App Service after testing it locally and then I was surprised when the application was not running as expected.

Since everything works locally so there were no reason to believe of any error on cloud environment too so I just do a google search and found lot of links related to this error but unfortunately none of them related to the problem I had. So with couple of my cool collogues, I started trouble shooting on this issue, and this is what all I did until I was able to drill down to the root cause.

1. Tried to get the actual cause by running the dll from Azure App Service => Console option, and it tells me the error as above screenshot. 
2. Deployment of the application to the Azure App Service was happening through CI/CD pipeline So I thought there could be something wrong going in there hence tried the deployment through visual studio to App Service and modified the appsettings.production.json through App Service => App Service Editor option (at the time of this article this feature is on Preview) manually.
   And result, it works then what the hell is going wrong with CI/CD deployment, and still no clue.
3. Tried the application to local IIS deployment and it worked here too. Oh my God.
4. After spending hours a random thought occurred, With the working application deployed in local IIS, I replaced the appsetting.Production.json file locally by copying it from Azure App Service => App Service Editor option (to use the one deployed to azure and created by CI/CD process).

Finally here I got some relief as issue was reproducible with local env and familiar too. Hence started debugging and While debugging I found that the issue was with below code throwing exception due the keyVaultUrl value is set to Empty character.

builder.Configuration.AddAzureKeyVault(
                    new Uri(keyVaultUrl),
                    new DefaultAzureCredential(new DefaultAzureCredentialOptions
                    {
                        ...
                    }),
                    new PrefixKeyVaultSecretManager(prefix));

So what was happening here is, In production, application was not using Azure Key Vault but the code was there and tried to build the configuration with AzureKeyValut and ending up throwing exception while starting the application.

CI/CD was creating the appSettings.Production.json and in this process it was replacing the keyvalut related setting to “ “ an empty character and this was the culprit.

Before I found this issue, it was looking huge but after I found it, I felt like Ahk!what the hell.

So if you ever encountered such error with production, My first recommendation would be to run the application locally with the same configuration and appsettings.json or web.config used in deployment/production and save your time. Sometime google also won’t be able to help you unless some people like me share his/her crazy experiences like this.

I too had no plan to share this :) until I got the below feedback from one of my reader for similar crazy issue related to docker networking.

Thank You All for such a beautiful feedback which turns as fuel for people like me to share more and more even it seems to be silly sometime.

Hope you enjoyed the content, follow me for more like this and please don’t forget to like/comment for it. Happy programming.

CI/CD with GitHub Actions to deploy Application to Azure App Service

 This is a follow up article of my previous article published here as CI/CD with GitHub Actions. There I was talking about basics of creating a GitHub action to automate project build and run tests.

In this article, I’ll be demonstrating a complete CI/CD to deploy a .net core web api project to Azure App Service.

Before jumping on creating a GitHub action to do so, first create a Azure App Service manually (as this is not part of this demonstration) with required configuration as per your .net project need.

Once Azure App Service has been created follow the below steps.

Step 1: Go to your Azure App Service Overview tab and download the publish profile from ‘Get publish profile’ option.

Step 2: Go to you GitHub project repo Settings tab and create a Action Secrets named as ‘AZURE_WEBAPP_PUBLISH_PROFILE’ and copy paste the entire content of downloaded publish profile file from Azure App Service in the value field.

Step 3: Go back to your Azure App Service Configuration section and add a new Application Settings as

This is to tell the App Service to use appsettings.production.json from the build for app settings.

Step 4: From previous steps it is clear that, we will be using the appsettings.production.json file which contains the settings required for application.

As part of security and good practice, DO NOT hardcode the sensitive data in appsetting.production.json and instead use the tokenized string which will be replaced with correct value from the GitHub CI/CD process. i.e. connection string in appsetting file as:

"ConnectionStrings": {
    "ConnectionString": "#{ConnectionString}#",
  },

Step 5: Go to your project GitHub repository’s setting tab and create an Environment against which we will define our secrets like connectionString for prod environment.

Step 6: Go inside the create Environment and add secrets with name as “CONNETION_STRING” and in the value field, paste the connection string value required by your application.

Step 7: Create your .yml file and define the environment:Production to fetch secrets from prod environment (created in above step) and add a steps to detokenize your appsettings.production.json to replace connection string from secrets.

Note: Please follow my previous article if are new to GitHub Actions.

jobs:
  build:
    runs-on: windows-latest
    environment: Productionsteps:
      - uses: actions/checkout@v2
      
      - name: Replace token for appsettings.Production.json
        uses: cschleiden/replace-tokens@v1.1
        with:
          tokenPrefix: '#{'
          tokenSuffix: '}#'
          files: '["src/DemoAPI/appsettings.Production.json"]'
        env:
          ConnectionString: ${{secrets.CONNECTION_STRING}}

Make sure, you use the name of the token (left part) as part of env exactly as it is defined your appsetting.production.json. i.e. in my case it is #{ConnectionString}#, and value part (right side) will read the secrets using the key as defined, in my case it is CONNECTION_STRING.

Step 8: Now we will define steps to setup .net core, build project, publish project and finally upload artifacts for deployment as:

      - name: Set up .NET Core
        uses: actions/setup-dotnet@v1
        with:
          dotnet-version: ${{ env.DOTNET_VERSION }}
          #include-prerelease: true
          
      - name: Build projects
        run: |
          dotnet build src/DemoAPI/DemoAPI.sln --configuration Release
     
      - name: Publish Project
        run: |
          dotnet publish src/DemoAPI/DemoAPI.csproj -c Release -o ${{env.DOTNET_ROOT}}/myapp      - name: Upload artifact for deployment job
        uses: actions/upload-artifact@v2
        with:
          name: .net-app
          path: ./myapp

With these steps, our artifact (deployment packaged in zip format) is uploaded to github cloud server used in this build pipeline under ROOT/myapp folder.

Step 9: Add the next job to deploy the package to Azure App Service as:

deploy:
    runs-on: windows-latest
    needs: build
    environment:
      name: 'production'
      url: ${{ steps.deploy-to-webapp.outputs.webapp-url }}   steps:
      - name: Download artifact from build job
        uses: actions/download-artifact@v3
        with:
          name: .net-app
          path: upload_artifact      - name: Deploy to Azure Web App
        id: deploy-to-webapp
        uses: azure/webapps-deploy@v2
        with:
          app-name: 'DemoAPI'
          slot-name: 'production'
          publish-profile: ${{ secrets.AZURE_WEBAPP_PUBLISH_PROFILE }}
          package: upload_artifact

As part of deploy job, the first step is for downloading the artifact and key thing to take care of is, the name: .net-app should be exactly same as you defined the name while uploading artifact steps from build job.

and the second step is for, deploying the app to Azure App Service (we created) and the key things to notice here are the package name, should be exactly same as you define as part of path in previous step, and second thing is publish-profile value reading correct secrets to connect to Azure App Service (which is downloaded publish profile details).

And we are done.

Hope you enjoyed the content, follow me for more like this and please don’t forget to like/comment for it. Happy programming.

CI/CD with GitHub Actions

 If you are working with GitHub Actions, you might too get confused with the term Workflow vs Actions. Here I’m gonna explain the difference as well as also giving you example to create your first CI/CD, even if you have never done it before.

GitHub Actions

In Github, Actions is the entire platform which automate the build, test and deployment pipeline. That means in GitHub, we create an Actions to automate our CI/CD pipeline.

The GitHub Actions consists several components as:

1. Events
2. Workflows
3. Jobs
4. Actions
5. Runners

Actions is the component of GitHub Actions, aah this is confusing. Also if you notice in the github UI, you will see as:

Here with the help of a simple GitHub Action which will just build the project and run Tests, we will discuss about above mentioned components and also clear the confusions/doubts too which arises due to naming as we talked.

Our requirement is: Create a GitHub action to build the project and run the test and will call it “Build and Test workflow”. Workflow, because GitHub calls it as workflows which is a GitHub action consisting all components as we defined above.

Since all our GitHub actions are shown under workflows in UI, lets convince our mind to call the action as ‘workflow action’ to avoid confusion (fair enough) and to do this add a folder named as .github/workflows in your project repository and follow the steps:

Step 1: Create a .yml/.yaml file in .github/workflows folder and name it as build-and-run-tests.yml.

.github/workflows/build-and-run-tests.yml

Step 2: Create the workflow.

Workflow is all the tasks which has to be performed when the event (in our case, push event on the branch repo) occurs.

In other words these are the pipelines which performs the task like build (build pipeline), Tests (test run pipeline).

As workflow syntax concerns, it consists of name (name of the workflow), on (event for workflow to trigger) and jobs (tasks to perform).

For the first, here we create the .yml or .yaml (no other extension is recognized/allowed) and name the workflow.

name: Build and Run tests#define variables
env:
 DOTNET_VERSION:'6.0.x'

In this file we name the workflow action as ‘Build and Run tests’ and added a variable available to this .yml file only.

Step3: Create an Event .

An Event is something that happens in a GitHub repository. i.e. Push, Create, delete, deployment, fork, pull_request, workflow_dispatch etc.

This is our first component of GitHub action workflow.

So now we define the ‘on’ part of the workflow which will trigger the workflow whenever there is push to our GitHub repo:

name: Build and Run tests#define variables
env:
 DOTNET_VERSION:'6.0.x'on:
  push:
    branches:
      - master
  workflow_dispatch:

Here we say, whenever Push event occurs on master branch trigger the action workflow. I also used the action workflow_dispatch which allows user also to manually trigger the workflow action.

Step 4: Create Jobs to perform tasks.

A Job is a series of steps inside the workflow which are executed. Each step is either a script to be executed or an action that would run.

Note: Steps are executed exactly in the order they are defined and dependent on the previous step being complete. So if previous step fails and the next step will not be executed.

So as per our requirement, we will create a job, to build and run tests.

name: Build and Run tests#define variables
env:
 DOTNET_VERSION:'6.0.x'on:
  push:
    branches:
      - master
  workflow_dispatch:jobs:
  build:
   environment: Test

in above code, we created a job called build pipeline and defining the environment as ‘Test’ to use to look for secrets if I uses within the pipeline as ${{secrtes.MySecrets1}}, this you can can define from settings tab.

Separating secrets with environment is useful when you have multiple jobs for dev, test and production etc within a single workflow action.

Step 5: Define the Runners.

The Runners are the process on the server that runs the workflow. Runners are hosted in the cloud and we specify the name of the runner for job using runs-on syntax.

name: Build and Run tests#define variables
env:
 DOTNET_VERSION:'6.0.x'on:
  push:
    branches:
      - master
  workflow_dispatch:jobs:
  build:
    runs-on: windows-latest
    environment: Production

Every job can have only one runners and in our case we specified as ‘windows-latest’ and the rest will be taken care by GitHub engine.

By now, theoretically our workflow action is ready doing nothing. So lets add the step to build the project and run the test as steps of the job ‘build’ as per our example requirement.

name: Build and Run tests#define variables
env:
 DOTNET_VERSION:'6.0.x'on:
  push:
    branches:
      - master
  workflow_dispatch:jobs:
  build:
    runs-on: windows-latest
    environment: Production    steps:
      - uses: actions/checkout@v2      - name: Set up .NET Core        
        uses: actions/setup-dotnet@v1        
        with:          
          dotnet-version: ${{ env.DOTNET_VERSION }}       - name: Build projects
        run: |
          dotnet build --configuration Release      - name: Test with the dotnet CLI
        run: dotnet test

In above code, we have added 4 steps, out of which 1st step is for checkout the git repository and the other steps are as their name says.

Note: Based on your project structure you may have to define path of the .csproj/.sln in your repo for dotnet build and test command to run.

If I need to picturize the whole things, the way it works as:

Hope you enjoyed the content, follow me for more like this and please don’t forget to like/comment for it. Happy programming.

Bonus

Follow me here for my next article on CI/CD with GitHub Actions to deploy Application to Azure App Service