This is the next in a series of blog posts that will cover the topics discussed in the ASP.NET Community Standup. The community standup is a short video-based discussion with some of the leaders of the ASP.NET development teams covering the accomplishments of the team on the new ASP.NET Core framework over the previous week. Within 30 minutes, Scott Hanselman, Damian Edwards, Jon Galloway and an occasional guest or two discuss new features and ask for feedback on important decisions being made by the ASP.NET development teams.
Each week the standup is hosted live on Google Hangouts and the team publishes the recorded video of their discussion to YouTube for later reference. The guys answer your questions LIVE and unfiltered. This is your chance to ask about the why and what of ASP.NET! Join them each Tuesday on live.asp.net where the meeting’s schedule is posted and hosted.
This week’s meeting is below:
Glenn Condron joined us this week, and showed us some improvements the team has made to the .NET Docker containers.
Talking .NET published a post about integrating HangFire with Web API.
Shawn Wildermuth has a series about ‘What I learned while building with ASP.NET Core” and this week he’s covering routing.
Eric Anderson wrote a post about troubleshooting an issue with some code that he copied from one machine to another got an error starting dotnet.exe
Stefan Prodan published a post about doing continuous deployment with Docker Hub.
Amjad published a cool article showing nine different docker .NET application templates.
Steve Smith wrote an article for MSDN Magazine discussing feature slices for ASP.NET Core MVC. You can read it online or in the print edition.
Barry Dorrans announced that the ASP.NET Core bug bounty has been extended.
Jon Hilton wrote about using MediatR to extend your app with notifications
Some guy named Scott wrote about using ASP.NET Core on low price Linux hosting providers.
Brock Allen announced IdentityServer 4RC1 availability with compatibility for ASP.NET Core
Christos Sakells has been updating a sample application on GitHub that uses ASP.NET Core, TypeScript and Angular 2
Jerrie Pelser has launched a course that demonstrates how to build a contact list application with ASP.NET Core
James South published an article showing how to use .NET Core for image processing
Donovan Brown wrote a post about using the outputName property in the buildOptions element in project.json
The latest updates for log4net show that they are working on support for .NET Core
Simon Timms wrote an article about how to properly use HttpClient in .NET Core.
Accomplishments – Docker Discussion
Glenn announced that the team intends to publish a new ASP.NET Core specific container image. Currently the image is not ASP.NET specific but relates to .NET only and ASP.NET Core runs very well on the dotnet image. We think that there are some optimizations that can be made for an ASP.NET Core specific deployment that the community will find very valuable.
The new documentation about building .NET Docker images was just published and Glenn shared the link to the online version of this at: https://docs.microsoft.com/en-us/dotnet/articles/core/docker/building-net-docker-images
From the Microsoft/dotnet images page on the Docker Hub, Glenn showed us the differences between the various images available.
While it may look scary with a bunch of versions listed, they each have their own proper place. The Development images are for various versions of the .NET Core framework and provide full compile capabilities from within the image. The Runtime images are images that have the minimum software required to run your application after it has been compiled.
When you refer to the microsoft/dotnet image, you are presented with the most wide-ranging image that covers most scenarios. You can further optimize by using the microsoft/dotnet:<VERSION>-core image that contains the runtime, the OS dependencies, the dotnet executable, and enough to run your application. You can view the commands that were used to build the docker image by executing the docker history command, and you will see results similar to the following:
You can then clearly see, starting from the bottom of the list and working up, the commands that were added to build up the image. There is a no-trunc switch that you can add to this command in order to prevent the ‘CREATED BY’ column from being truncated so that you can read the entire command executed.
Glenn then showed us that building a simple Hello World console app and running it in the dotnet:core image without the compiler and SDK results in a 253MB image. The same application built with the dotnet image that does have the SDK embedded creates a 540MB image, almost twice as large. It should be noted, that your application will be much larger than a ‘Hello World’ console application, and these size measurements are a minimum number that your application will start at.
By comparison, we measured the size of some common language docker images and built the default ASP.NET Core web template into an image and compared their image sizes:
In reality, the sizes of these images are not a significant problem once the image is deployed to a server running docker. When a container is running, every instance shares the cost of the image and only needs disk space to manage changes to the image. The image size is only important when delivering the image and the network bandwidth needed to deliver that content.
A suggestion came in from the community that the dotnet image could be reduced in size by switching from a debian base to the latest ubuntu image that is 60MB smaller. The team hasn’t researched this yet, and think that it could be a viable change.
Glenn then showed us Troy Dai’s docker hub account and the prototype docker images he is working on.
- All of the ASP.NET Core NuGet packages pre-restored for the user
- Pre-cross gen’d cache of ASP.NET Core and all of the dependent assemblies so that you don’t pay that compilation task at start time
- Environment variables already set to listen to the public 5000 port
The production image includes a cache of runtime assemblies that have been pre-just-in-time compiled to help improve the startup performance when running in production.
Try some of these images and let us know what you think. The team is working to improve them, and we will report more details on these changes as they are published.