For this blog, I will be using an already pushed IIS image to the docker Hub. The application image uses microsoft/iis as a base image.

Let’s get started.

Step 1. Open Visual Studio 2017 and create a Service Fabric Application.

Step 2. Now choose the Guest Container feature and provide valid Image Name and Click Ok. The image name is the one we published to Docker Hub in the previous exercise.

Step 3. Once the application is created and loaded, add the following endpoint information into ServiceManifest.xml

Step 4. Now let’s add following section into ApplicationManifest.xml to add Hub Credentials and Port Binding endpoint information.

Step 5. We are ready to Publish our application to Service Fabric Cluster now. Right click on the Application and Publish to Azure Service Fabric. Make sure when you create the Service Fabric cluster, you pick the option to create it with Windows Server 2016 with Containers.

Step 6. First let’s see our application deployed using Service Fabric explorer.

Step 7 Now, lets browse to our application on Service Fabric. You should see your IIS  application running on Service Fabric.

As you saw in this blog post we can use Service Fabric for Container Orchestration for newer and legacy applications. More coming in next blog on Container Orchestration capabilities like DNS, Scaling, Labels etc.. Stay tuned!]]> https://docs.microsoft.com/archive/blogs/monub/docker-blog-series-part-2-build-deploy-asp-net-core-docker-image-on-service-fabric Sun, 28 May 2017 01:46:38 GMT https://blogs.msdn.microsoft.com/monub/?p=535 Service Fabric programming model is also able to orchestrate container based services across a cluster of machines. Service Fabric can deploy services in container images. In this blog post, we will see how to use Service Fabric as an orchestrator for Windows based Docker images. The images will be published to Docker Hub and consumed by the Service Fabric orchestrator. We will build an ASPNET Core Web application, Dockerize it and publish it to Docker Hub. Finally we will publish the image to a Service Fabric Cluster. Step 1: Create a ASPNET Core Web Application using Visual Studio. Step 2: Select Web Application template. DO NOT  check “Enable Docker Support” Step 3: Once the application is loaded in Visual Studio add a Dockerfile to the root of the project. Step 4. Open the Dockerfile in Visual Studio and add the following steps in the Dockerfile and Save the Dockerfile.

FROM microsoft/dotnet:1.1-sdk-nanoserver ENTRYPOINT ["dotnet", "bin/Debug/netcoreapp1.1/DemoCoreApp.dll"] WORKDIR dockerdemo ADD ./DemoCoreApp . RUN dotnet restore DemoCoreApp.csproj RUN dotnet build DemoCoreApp.csproj EXPOSE 80 ENV ASPNETCORE_URLS https://0.0.0.0:80

Step 5. Open Powershell in Admin Mode and browse to the project folder. Step 6. Execute Docker build command to build image from the Dockerfile. Include tag name in the build command as shown below. Step 7. Exexute Docker run command to create the container using the image previously created as shown below Step 8. Inspect the IP address on which the container is running by executing network inspector nat command. Step 9. Open the web browser and navigate to the IP address and you will see the ASP.Net core application running. Step 10. Publish the image to Docker Hub so that it can be consumed from Service Fabric. Before pushing login to Docker Hub using login command Now we will use the  image from Docker Hub to deploy to a Service Fabric Cluster. Let’s begin building the Service Fabric Orchestration piece. Step 11. Open Visual Studio 2017 and create a Service Fabric Application. Step 12. Now choose the Guest Container feature and provide valid Image Name and Click Ok. The image name is the one we published to Docker Hub in the previous exercise. Step 13. Once the application is created and loaded, add the following endpoint information into ServiceManifest.xml Step 14. Now let’s add following section into ApplicationManifest.xml to add Hub Credentials and Port Binding endpoint information. Step 15. We are ready to Publish our application to Service Fabric Cluster now. Right click on the Application and Publish to Azure Service Fabric. Make sure when you create the Service Fabric cluster, you pick the option to create it with Windows Server 2016 with Containers. Step 16. First let’s see our application deployed using Service Fabric explorer. Step 17. Now, lets browse to our application on Service Fabric. As you saw in this blog post we can use Service Fabric for Container Orchestration. More coming in next blog on Container Orchestration capabilities like DNS, Scaling, Labels etc.. Stay tuned!]]> https://docs.microsoft.com/archive/blogs/monub/145 Tue, 20 Sep 2016 01:57:10 GMT https://blogs.msdn.microsoft.com/monub/?p=145 ‘Docker for Windows’ Visual Studio Tooling. Along with that, we will see how to build ASP.NET core application with Docker Support Tooling Before talking about containers, let’s take a moment to understand Microservices. Microservices and micro services style architecture is about decomposing monolithic application into smaller services. This enables versioning and deploying these services independently. Building microservices based applications helps accelerates agile delivery within an agile engineering teams. Now let’s talk about containers. Containers provide a mechanism to run software reliably when moved from one computing environment to another. Simply put, containers are a portable unit of application and its underlying dependencies packaged (container image) together. By containerizing the application and its dependencies, the OS and underlying infrastructure differences are abstracted away. Containers isolate applications from each other on a shared OS. Additionally, we can get more isolation using Hyper V Containers. The micro services based services are a perfect fit for containerized applications. Why should we be interested in containers? Let’s look at some of the value proposition around it. - The containers enable ‘write-once, run anywhere’ apps. - They enable microservices style architecture. - It is also great for dev/test of apps and services. - From the operations standpoint, this is great from portability and enables higher compute density. We can also scale up and down containers in response to the business needs. Docker is platform for running these containerized applications. Docker is becoming the standard for implementing containers across the industry. There are different ways to run hosting containers within Docker.  

1. Docker for Windows, which uses Hyper V to run the MobyLinux VM or Windows Containers
2. Docker for Mac
3. Boot2Docker and Virtual Box for older scenarios.

b- Docker File. This file is used to build the docker images using the instructions in this file.

Step 4 :

All you need now is to run your Visual Studio Application and you are up and running with your ASP.NET Core application running on a Docker container. We can take a look at the running container using the “docker ps -a” command.

In this blog post, I will demonstrate using RM VNext for an OnPrem deployment using On Prem Build/Release Agents set up. We will be deploying a simple MVC application which will be packages as a zip file for Web Deploy deployment using OOB IIS Deployment Task. We will set up both Continuous Integration and Continuous Deployment for this sample application.

Create the ASP.NET Web Application

1- Create a  Visual Studio VS 2013/2015 ASP.Net Web Application.

2- Once the project is created, check in the Solution into the appropriate VSTS Team project. It is assumed here that you have a VSTS project in place.

Create a Build Definition for the Project in VSTS

3.1 We need to go to the Build TAB.

3.1 – Configure the Build Definition. I will be using Visual Studio Build for this example.

3.2- Set up the Repository for Build.

3.3- Set up the CI and Scheduled Build times if needed.

3.4- Set up the Agents for the Build. Agents for the build/release are setup through the Agent Pools Sub Tab within Control Panel. For more information you can go here - https://msdn.microsoft.com/Library/vs/alm/Build/overview

3.4.1 – Once you have build/release agents set up, you need to configure them for the Build using ‘General’ TAB.

3.5 – Set up the Index and Publish Symbols.

3.6 – Copy the Artifacts of the Build and Publish the Artifacts to Drop Location on the Server. This will be the location to later on pick the build artifacts for the Release.

3.7 – Queue up the Build.

3.8- Build should complete and artifacts should be available in the Drop Location on the server.

Create Release Definition

Next we will work on the Release part for Deploying the Application to an On Prem Environment using Release Management. We need to go to the Release TAB.

4.1- Create a Release Definition.

4.2- Configure Release Definition for an On Prem Deployment. Create Environment

4.2.1 – Configure the Environment with the Approvers, release Agent.

There are options for Pre-Deployment and Post-Deployment Approval. Agent options allow you to configure the Agent for release. The agent you configured for Build can be used for Release as well. You can also use Configure Variables option for tokenization of certain configurations which are environment specific.

4.2.2 – Add Tasks to the Release Definition.

4.2.3 - Create a Windows Machine File Copy to copy the Build Artifacts to a //Share location on the On Prem Machine

Keeping in mind when working on Prem Deployment, the Build/Release Agent needs to be configured on an On Prem Machine so that they have clear line of sight to the servers which need to be deployed which are on Prem as well.

4.2.4 -  Add an IIS Web Application Deployment task to do the On Prem Deployment

For enabling this, we need to create Deploy Machines which is a machine group which makes it easy to do the deployment. You can also specify the machines using the Machine IP’s or FQDN with ports but Machine group is recommended.

4.2.5 – We now link the Release to the Build Artifacts.

4.2.7 – If you need Continuous Deployment, you can check the CD check box and provide the Build Definition.

This will ensure Release to the environments when build is kicked off and completed.

4.2.8 – For creating the Machine Group  Machines, we need to go to Test TAB and create a Machine Group under Machines sub TAB.

4.2.9 – The machine group  has name of the machines and the WinRM port with credentials for accessing them.

4.2.10- Create a Release by specifying the Build and the Environment to be released to.

4.2.11 – On Prem Release is successful.

Here is how the Build and Release Summary reports look. Great insight into the Changesets, Associated Work Items, Test cases run, Code Coverage reports.

Build Summary Report

Release Summary Report

You can also check out https://msdn.microsoft.com/library/vs/alm/release/overview for more information. Happy Releasing using RM Vnext service

In this blog post, I will demonstrate how to easily unit test an OData based Web API service which is consuming data from SQL DB using Entity Framework. The goal is to write unit tests which stub out the actual DB calls. We will make use of faking the DB Context and using a common DI pattern of construction injection. The result is a highly testable maintainable and cohesive codebase.

Create the ASP.NET Web Application

First, open Visual Studio VS 2013, create an ASP.Net Web Application, choose MVC and Web API template and check the Add Unit Tests checkbox.

Create the DB

Next, create a SQL Database as the backend for this project. Use SQL Server Edition of your choice. I am using SQL Server 2014 for this post. We will use Entity Framework(EF 6.0.0.0) to connect to this DB.

Let the DB name be ODataDB

Next up, create a Table in the database named Application with following properties.

Create the Application Table

Reverse Engineer Code First from the DB

Right Click on the Web API project we created to reverse engineer code from the database. You will need to install Visual Studio Entity framework extensions.
Make sure Entity Framework dll’s are referenced in the project.

We now have Application Map.cs and ODataDBContext.cs created and mapping created.

Create ODataController

Next up, install Web API OData Libraries from Nuget for the Web API project. I am using the latest version of ASP.Net Web API2.2 for OData v1-3

Now let’s create ODataController based on Entity Framework and call it Application Controller.

We will use ApplicationMap and ODataDBContext for Model and Data Context class respectively.

Now that Application Controller is created and we have our Get/Post/Put operations in place in the controller class.

Click F5, and the OData Service is up and running!

Create Unit Test for the Application Controller

Now that the application is running, we want to write unit tests for it.

First and foremost, we need to Fake Out the DB Context in our application. Instead of using the ODataDBContext, we will use FakeDBContext. In order to do that we first need to create an interface for ODataDBContext. We will call it IODataDBContext and have ODataDBContext implement from it.

Create Interface IODataDBContext

Implement IODataDBContext from ODataDBContext

Run the application to see everything works like before. Now that the IODataDBContext is in place, let’s create FakeDBContext in the Unit Test Project.

Unit Test Project Plumbing

Add the following to the Unit Test Project.

• Add FakeODataDBContext to the unit test project. Ensure that FakeODataDBContext implements the IODataDBContext Interface.
• Add Entity framework dll to the references.
• Add System.Web.Http dll to the references.
• Add System.Web.Http.OData dll to the references.
• Add FakeDBSet class to the project.
  

Notice the constructor in the FakeODateDBContext, it has a method called GetApp(), this method is used to create the Fake Application object which is returned to the Unit test when calling the ODataController for Application.

Below is the code for GetApp(), Here we are using the FakeDbSet to create a Fake Application Object in memory for the purposes of the Unit Test.

Before we start writing Unit Tests, we need to tweak the controller code to expose the ODataDBContext object as a parameter. This is classic case of constructor dependency injection which would make the code testable.

Now, let’s write the Unit Test for the Application Controller. Here is the Code for the unit test. The unit test  is a  Visual Studio Unit Test.

As you see above, we have successfully written a Unit Test for the ODataController Api. The above unit test will exercise the code paths of your controller code and also execute any logic inside it without having to make the actual Database call. The FakeDBContext lets you get/set  data in memory and disposes it once the unit test exits.

You can potentially create Unit Tests for all your Controller methods(Get,Post.Put,Delete) across all your application and ensure very high Code Coverage and a highly testable and maintainable application.

Hopefully this post helps you start writing Unit tests for ODataController Services using Entity Framework.