This is the second post of a two part series on ASP.NET Core, Docker, and Docker Swarm. In our previous post, we created an ASP.NET Core Docker container and pushed it to Docker Hub. Along the way, we took a look at a couple third party tools, such as Yeoman. To continue our journey, we will take the container we previously created and host it in a highly available Docker Swarm cluster.
So far in this series, we have taken a look at the .NET Core Tools 1.0.0-preview2 (Visual Studio 2015) and the .NET Core Tools 1.0.0-preview4 (Visual Studio 2017). With both versions, we created a project with the command line tools and with Visual Studio. From there we spend some time analyzing each of the files and compared and contrasted the project structure.
In this post, we will take a look at migrating from preview2 to preview4 and discuss any nuances that come with it. This is the final post in a three part series. If you missed any of the previous posts, please feel free to take a look.
In the previous post, we took a look at creating new .NET Core projects with the .NET Core Tools (1.0.0-preview2) in both Visual Studio 2015 and the .NET Core Command-Line Interface. We broke down the project structure, dived into the new files, and compared the CLI projects to Visual Studio ones.
In this post, we will perform the same exercise with Visual Studio 2017 RC and the 1.0.0-preview4 version of the .NET Core Tools.
.NET Core is Microsoft’s latest development framework. It is open source, cross platform, and features many improvements from prior versions of the .NET Framework. I’ve been very excited about .NET Core since it was released in the summer of last year.
There are many new features and improvements but, in this series I want to focus on just one piece, the project structure. With Visual Studio 2015 (Core Tools 1.0.0-preview2), there were quite a few changes to the traditional Visual Studio project. Visual Studio 2017 RC 1 (Core Tools 1.0.0-preview4) introduces even more changes to this project structure.
I’ve observed a wide variety of methods for managing and deploying SQL (Sprocs, Schema, etc). I’ve seen methodologies from extremely elaborate home grown frameworks to managing custom DDL scripts like shown below.
DryIoc is an IOC container for .NET that is built for speed. Looking at the link we mentioned previously, you will notice DryIoc performs better than all the other containers that were examined. It is very focused, well maintained, and has complementary packages to tie it into ASP.NET Core, Web API, OWIN, etc. That said, my favorite aspect of DryIoc is its extensibility which makes it easy to use!
Why hello there! I’m Jason a software architect out of South East Michigan. While working in software development over the years, I’ve been able to consume a lot of material to help build my career. At first I started thumbing through technical books (my favorite publisher was WROX), then slowly I migrated towards Twitter, PluralSight, and various technical blogs. I’m grateful for all the amazing authors I’ve been able to learn from over the years! Some of my favorites include Scott Hanselman, Shaun Wildermuth, John Papa, and many others.