[Webinar Recording] Who needs Visual Studio? A look at using .NET Core on Linux

And why stop there? .NET Core is cross platform, so in this webinar, our guest speaker Chris Gomez will do all of the development and testing on Ubuntu Linux.

This session is perfect for .NET veterans who are brand new to .NET Core and want to see what the brave new world looks and feels like. It's okay if you're unfamiliar with Linux, but are interested in having options available to you. We'll even learn how Microsoft Azure can make the heavy lifting to production much easier.

Watch the webinar and learn:

• What the brave new world coming with .NET Core looks like
• The acquisition and use of .NET Core on a Linux VM untouched by a Visual Studio installation
• How things work under the hood if you work with .NET Core more directly
• Development tools such as Visual Studio Code and how you can contribute to the .NET Core and tools ecosystem

Who needs Visual Studio? A look at using .NET Core on Linux on Vimeo.

Video Content

1.  What is .NET Core? (5:03)
2.  What about .NET Framework? (12:37)
3.  What is ASP.NET Core? (13:04)
4.  Prerequisites & Acquiring .NET Core (14:49)
5.  Development Experience (17:30)
6.  Q&A (47:20)

Webinar Transcript

Introduction

Tony:

My name is Tony and I'll be your moderator today. I work as a software developer here at PostSharp and I'm excited to be hosting this session today. I'm pleased to introduce today's speaker, Chris Gomez. Chris is a senior software architect and today he's going to share how to get started with development and deployment on Linux using .NET Core.

Before I hand the mic over to Chris I have a few housekeeping items to cover about this presentation. First, this webinar is brought to you by PostSharp. PostSharp is an extension that adds support for patterns to C# and Visual Basic, so if you are tired of repeating yourself in your code, you may want to check this out – as the folks at Microsoft, Intel, Bank of America and others who have been using PostSharp in their projects to save development and maintenance time.

Customers typically cut down their codebase by around 15% by using our product so feel free to go to our website, www.postsharp.net for more details and you can get a free trial there and try out PostSharp. And next, today's webinar is being recorded and the recording will be available after the live session so you will receive an email with the link to the recording.

And last, we'd love to hear from you during today's presentation, if you have any questions for our speaker, please feel free to send them through the questions window in GoToWebinar application, which is at the bottom of your player and we will be answering your questions at the end of the session.

And also if we have more questions than we can handle during the webinar we will make sure to follow up with your questions afterwards so you will have the answers along with the link to the recording. Without any further ado I'd like to kick things off by welcoming Chris Gomez. Chris, over to you.

Chris:

Great, thank you, Tony, and thank you PostSharp for having me today. Let me introduce myself real quick. My name is Chris Gomez and the first software I ever wrote was in BASIC on DOS 2.1 quite a while ago. Been writing software professionally for Windows since '93 and I'm currently a Microsoft MVP in Visual Studio tools and Development Technologies, which is a big mouthful for helping developers get their work done.

And then because I copied this slide from another slide, the next bullet point isn't important but I'm also a contributor to the Static Void podcast, which you can listen to at www.staticvoidpodcast.com. A couple of good friends of mine in the local Philadelphia region and I get together and we talk about topics that we think affect .NET developers at work, so we try to think a lot about trying to take the technologies we learn about at webinars and conferences, how do we actually take those to work. So that's what that podcast is all about.

Before we get started I want to let people know that today's slides are available on my blog at www.chrisgomez.com. The first post today is the link to the slides hosted out on Slideshare and a couple other interesting links, so don't forget to check that out if you think you're being overloaded by all the information and you wanna rush and copy the links that you see here, don't worry about it, just head over to my blog afterwards at chrisgomez.com and you can find these exact slides.

Today we're gonna talk, very briefly about .NET Core because what we really want to get into is how you acquire .NET Core on Linux, and what's the development experience like. And then there are so many different ways to publish your work, even if you've spent your whole entire development experience in Linux, never touched Windows, never touched Visual Studio, there are different ways to deploy your finished .NET Core apps and I'm gonna show you one of those at the end. Those are the things we're gonna cover. It's gonna be a pretty quick survey, there's a ton of content and we should go ahead and get started.

What is .NET Core?

Let's talk real quick about what is .NET Core. .NET Core is a brand new platform. This is not the next version of .NET Framework. You're gonna hear me use the two terms today, .NET Core and .NET Framework, and I'll go into a better definition coming right up.

.NET Core is a cross-platform implementation of the same .NET concepts that we're all familiar with, a CLR, a Common Language Runtime that supports multiple languages, garbage collection and other .NET idioms and concepts that we're all used to, including similar base class libraries. It runs on Windows, several Linux distributions and the Mac, and currently there's support for 64-bit, you do get 32-bit support on Windows, so just in case you're wondering the Ubuntu Linux image you're gonna see today is a 64-bit image. I think that's pretty common now.

So .NET Core is biased towards being platform agnostic. There are two major workloads that I think you can use today. There's a console applications and then the ASP.NET Core models on top of it. We're gonna talk about the ASP.NET Core framework. That's what most people are gonna be doing when they actually settle down and say, "Hey, I wanna get some work done." You can build services using the console model but today we're gonna focus on the ASP.NET Core model.

It's open source, so you can contribute to the code, you can contribute to the documentation and there's the link to get to the .NET repository. Today there's language support for C# and F#. You'll see in the documentation that Visual Basic is listed as future support, that's all the information that I have there.

A lot of people ask why do we need a second .NET? Well, it turns out we've already had many .NETs. And here's just a small sampling of some different .NETs that we have today. Besides the Mono implementation that was created very early in the .NET Framework's life, we have the traditional .NET Framework. It runs on Windows. It's gonna continue on and only run on Windows and it supports app models that you might be familiar with such as WPF, ASP.NET, Windows Forms and some other services like WCF, they're very popular.

.NET Core is currently, that I know of, being used in three places. It's being used for the ASP.NET Core workload, the Universal Windows Platform workload, which is listed here as UWP, and then it's not on this slide but I do believe that Xamarin Forms is taking advantage of UWP. And to give you an example of who else is taking an advantage of it, the Unity folks for the game engine. When you create a store app they use the Universal Windows Platform.

We've already had many .NETs but .NET Core, as shown in the previous slide, is trying to accomplish some new goals, such as achieving cross-platform, lightweight, being flexible.

Tony: Excuse me, Chris, may I have a question here?

Chris: Yeah.

Tony:

Are you sure that .NET Core goes along with .NET Framework and you've been talking about Mono as well. Is it really an extra framework along with those or does it use also .NET Framework or Mono on the respective platforms?

Chris:

.NET Core is a brand new framework, a brand new platform. That's probably a better word, to call it a platform. It has its own set of base class libraries that map there in the CoreFX repo on GitHub and then new app models are being built on top of it, and today we're gonna focus on ASP.NET Core but your question is a great one because early in the life of ASP.NET Core you could build on Linux, you could build for both Mono and the emerging .NET Core platform. Essentially they were using Mono as a stopgap. They could keep working on ASP.NET Core, which is an app model on top of a framework, and you could get started using it and testing it and providing feedback while they were finishing up .NET Core support for Linux. There was a period of time that both were available.

Now, I'm pretty sure today I haven't seen any evidence that you would be able to use today's ASP.NET Core on Mono and I don't know if there's plans to bring it back as a second Linux target. So today you would be doing ASP.NET Core on .NET Core for Linux. Does that help, Tony?

Tony: Yes, thank you.

Chris:

Great, thank you. It was a good question. Let's talk about what .NET Core doesn't do. It doesn't mind meld into your machine the way that .NET Framework does. When you use the .NET Framework it come with many operating systems, it comes with many server OS versions but when the times comes to upgrade it you have to go and get an installer and it goes and adds assemblies to the global assembly cache and beginning with .NET 4 it's an in-place upgrade for every app running on the server.

If you had written an ASP.NET app expecting .NET 4.0, except that there's some other ASP.NET apps running on that same exact server, they don't even have to be ASP.NET apps. They can be Windows Services even but there's a need to upgrade .NET. Everybody gets that upgrade.

Now, Microsoft worked really hard to try and make those upgrades as backwards compatible as possible but you can certainly understand that from a developer point of view that we might like to have a system or a platform that's a little bit more forgiving.

So there are two models for deploying .NET Core. There is the model where you include .NET Core right in your app, that's a self-executing model, and as part of publishing, you basically say that you want the self-deployment option and you literally will have a folder that you could pick up and even port to another machine, stick it to another machine and it'll work just fine, as a famous demo that I see the product team doing all the time is they put it on a USB key and walk it across the stage.

You can also install shared .NET Core frameworks side by side on the same machine and different apps can target the ones they choose. So you have a ton of flexibility in the deployment models. Now, .NET Core also does not implement everything you remember from the .NET Framework. Some examples are there's no Code Access Security model, there's no WPF. WPF was built on DirectX, which is very Windows-specific. There's no WCF. Most of the items that have been left out are either had a strong Windows tie, they were using underlying Windows technologies that really strong tie, like WPF or for now they just may not be considered higher priority but customers have been providing feedback and many things have made it into the roadmap based on customer feedback of things they still wanna use in .NET Core and possibly on other platforms, OSes like Linux.

What about .NET Framework?

What does that mean for the .NET Framework? Well, real quick I just wanna let you know that .NET Framework 4.6.2 was released in August 2016 and .NET Framework 4.7 was released in April 2017 so it continues to be a framework for Windows, we're seeing new versions, one last month and I think as long as we have Windows operating systems there's going to need to be support for new .NET Frameworks to support those features.

What is ASP.NET Core?

I talked about ASP.NET Core. What is that and how does it relate to .NET Core? I talked about .NET Core but now all of a sudden I'm talking about building web apps on it. Well, .NET Core I consider a platform. Runs on Windows, Linux and Mac, as you can see on the diagram at the bottom. ASP.NET Core is an open source and cross-platform framework. And since it's a coding framework to help you build web applications or web servers, it actually has the benefit of it runs on both .NET Framework and on .NET Core.

So you can get started with ASP.NET Core now and still run them on Windows servers that are using .NET Framework without ever installing .NET Core on them. Or you can begin to move towards .NET Core and possibly look at deploying on other operating systems like Linux.

It contains a few components to help you build sites and one of those is the ASP.NET Core MVC. If you are familiar with ASP.NET then you probably are familiar ASP.NET MVC. So this version helps you build your presentation layers and it also helps you build web APIs. There has been a convergence in the two frameworks, MVC and web API, they were already pretty similar so you will use ASP.NET Core MVC whether you're building presentations for websites or whether you're building a back end web API. You'll also see in the docs Entity Framework Cork, a new cross-platform data access layer.

Acquiring .NET Core

So what do you need to get going? Here are some different options, things you can use. I am today using Virtual Box running on Windows. You could also use Hyper-V and you could use other virtual machine options as well, there's nothing exclusive about what I've chosen here in the options box, or you can just use your Mac. You'll get a very similar experience if you're using a Linux distribution. You can also use Linux right on the bare metal if you've already got it running on a machine or laptop and you can do all of the command line stuff you're seeing today on Windows too. If you wanna experiment on any of the operating systems, you're gonna find the commands are very similar.

For some of the things we're using today I needed Node.js and NPM, those were prerequisites for Yeoman. If you don't know what Yeoman is, I'll get to it when we start the demos. I also installed a Yeoman generator for ASP.NET and I installed Bower because that's the client side package restore for Yeoman. If you aren't interested in Yeoman at all, you can actually skip this page just to get things started.

To acquire .NET Core you can go to the home for .NET at dot.net and it'll take you to this page, click through to the download section and you'll see the Linux installation guide and you see there's several Linux distros supported, from Red Hat. Today I'm using Ubuntu but there's also CentOS and so on so you've got a lot of options and we'll see real briefly how that works.

When you acquire it, it's all using commands. Unlike the .NET Core SDK for Windows, which has an installer, on the web page you actually just see a list of commands and it brings down .NET Core for you, the whole process took me approximately three minutes, and that includes building the app, restoring NuGet packages.

We're gonna look at Visual Studio Code today. I'm gonna show you a little bit about the OmniSharp project and we're just gonna take a brief look at JetBrains Rider. If you used JetBrains Rider on Linux, I noted in the slides here there are two other prerequisites you have to go get. You need to go get mono-complete and the MSBuild package for that to work.

Getting Visual Studio Code's a piece of cake. You could Google for this very easily. The web page will help you install it. I actually really did go click on that button right there for Ubuntu installs. Before you get started, if you open any kind of C# project, it's gonna recommend you get the C# extension. You're gonna wanna do that because then you get some nice debugging support in IntelliSense.

Development Experience

Let's go take a look at what that experience is like. Hopefully we'd gotten through most of the boring slides, right? Let's take a look at an Ubuntu distribution here. You can see that I've got it running in a virtual machine. I'm using Ubuntu 16.04 but there is more support than just that one, I don't want you to think that's the only one you can use.

The first thing we're gonna do is let's just say you've gone ahead and you followed all the instructions and you've installed the .NET Core on your machine and you're ready to go. Just to show you what that looks like, if you followed through, you saw on the slide I had the installation guide and you saw some screenshots but these are the actual commands, it's real simple, you're just adding some new libraries for apt-get and you can build your first Hello World app real quick.

Let's go ahead and do that and in order to do that we're gonna use a utility that gets installed called .NET. This .NET command ends up being super important and you can read the built-in help just by doing .NET help. It's got some important commands and this is actually an extensible model. You can add your own commands to it as well.

I'm gonna say dotnet new. Actually what I'm first gonna do is let me make a directory for this and let's just call it consolenet and then cd to it and we'll say dotnet new and what I'm saying here is that I want a console app. A console app is a real simple Hello World style app, it doesn't do much more than just kind of get your feet wet and show you how it works.

So how did I know to do all that. Well, I showed you that dotnet -- help brought up some general commands but you can also dig in deeper. If I say dotnet new -- help and what I find out here is oh, okay, I can pass it a template that I want to be instantiated and there are even some options where I wouldn't have to have made the folder first.

Anyways, I have gone ahead and shifted into this folder. There's not much here, just a CS.proj file, which might not look super familiar if you're used to CS.proj files that looked more like this. The new .NET Core model, MS build and the .NET Core team have worked to try to make a CS.proj file have much cleaner defaults, be human readable and human editable. It doesn't mean you have to spend a lot of time working in here but certainly it's nice to know that maybe the days of all those GUIDS, all those ugly GUIDS are gone.

This is the program that we're gonna run. If you say dotnet new console, you're really just getting like a demo app. And the first thing you would do if you were in the Windows world is you'd have to probably restore NuGet packages.

Here from the command line we continue to use .NET, we say dotnet restore. And it's gonna go ahead and restore the packages for this project, didn't take very long and we can say dotnet run and all this app does is write out Hello World to the console so it'll do that after it compiles. That's the basic, you know, getting started but if you wanna see more options, it turns out that there's, let's see, if I say dotnet new ... there are a lot of different other template types. You can have it create you a solution file or you can even say, if you want to edit NuGet config, web config, and there's even other templates besides that.

If I say dot net new MVC, and this time instead of creating the folder first, I'm gonna go ahead and say, I'm just gonna call this New MVC App. I'm using -o, which is output, telling it don't put it here in my home folder on my Linux machine, don't put it there, go put it in New MVC App, and it's gonna get to work. And it creates a new ASP.NET Core web app, this is a different template. Let's click back into here and just take a look at what we get.

This might look a little bit more familiar. There's a controllers folder, there's a views folder. In the .NET Core world we put our static files in the www root folder. Now, this is configurable but by default it's the www root folder and it's not like before where you actually were just kind of putting your static files somewhere in your project. They might go in a scripts folder, they might go just right in the root, they were mixed in with everything. Now they're isolated and the static files that you need served have to go in there.

And then you get some other basic things to start so you could just begin working, I mean you could open up just command line tools right here but I think this is probably a good opportunity to shift over to Visual Studio Code. So I had installed Visual Studio Code and you can run Visual Studio Code from any folder that you're in just by saying code.

So it's gonna open up this brand new MVC app for us in Visual Studio Code. Now, Visual Studio Code's not an IDE. It's a lightweight editor. It's not intending to replace Visual Studio but what's great about it is it's cross platform. You can use this on a Windows machine, you can use it back on a Mac, maybe you're developing in a Mac client.

And when you open a C# project, it's gonna notice a few things. For example, just my sitting here talking, it noticed that we haven't run dotnet restore. I did that on purpose because it's gonna bring up and say well, just like if you open a Visual Studio project that you haven't run NuGet package restore yet, you haven't built, you get all the red squigglies saying, "Oh, I don't know what all these things are."

This runs dotnet restore for you. And if you wanna debug in Visual Studio Code it needs a little bit more information. If you go ahead and click yes here, it's gonna add a little folder to your project called .VSCode and these JSON files just describe simple tasks for building. You can add to these tasks, you can add testing support and also this gives Visual Studio Code what it needs in order to attach a debugger.

Yeah, I said that right, here in Visual Studio Code we're going to attach a debugger, it's pretty cool. What I'm gonna do is I'm gonna go to the home controller and let's go ahead and if I come to the left side, here's a debug button because of that launch.JSON that was created for me I've already got this set up, I can say, dotnet core launch, click the play button just as if I'm in Visual Studio and it's gonna build and run this. Won't be planning to build too many more after this though. Got some ready-made projects for us.

Alright. All .NET Core apps, including web applications are really console applications and we can see all the output coming through the debug console. I didn't make any changes to the default template so it went ahead and used localhost:5000, which it's connecting to right now and getting the first page. And here we go, there it is.

Really this was just a file, new project and I called it New MVC App so they put this up here but I wanna show you that you can debug into this. So if I set a breakpoint here, just the way I'm used to, just sort of click in the margin, get a little red dot and then go ahead and go to that controller. Instead of just immediately switching to the controller we're gonna hit the breakpoint.

Now, I don't have a whole lot in here to look at but I certainly do have these locals so I've got perhaps a poor man's variable window over here, I could interrogate model state, I could add my own watches, I can look at the call stack. For example, here's the model state if you're familiar with MVC. Not a whole lot going on here in this simple app.

That is some debugging support that you get just with Visual Studio Code. If you're working with one project and this simple startup home controller. Now, let's take a quick peek at how this looks. I talked about Rider. I have Rider running already and here is just a simple app that was built using Rider and in this particular case we've got a web API app and you can see that it's a more traditional solution with two projects and we've got a little service library that the PeopleApi depends on.

You might be wondering well, wait a second, back in Visual Studio Code, how would you be able to do that? Well, it turns out Visual Studio Code will go ahead and pick up a solution file if it finds one and it'll go ahead and use that to set up an experience with multiple projects sitting in one window here. You're not seeing that here because in this particular case what you may not have noticed yet is there's no solution file. That's a Visual Studio artifact, not necessary for .NET Core and so it's gonna let me work on this new MVC app self contained in this CS.proj, a much simpler looking CS.proj I might add. Here the NuGet package references and the fact that I'm targeting .NET Core 1.1 and that's all it needs.

Now, this talk is about who needs Visual Studio, so how did I create this? You could use Rider to create a solution with multiple projects but it turns out that all-powerful dotnet command is here to help us as well. One of the dotnet new commands that I think you saw, if we look at the help, was SLN. And that's seems kind of strange. What would I need with an SLN support?

It turns out that just to replicate what you saw there without actually going through all the motions, what I'm doing here is I'm saying I wanna create a new solution project and go ahead and put it in a folder called Solution just so that we remember where it is, and it says, "Yeah, sure, I did that for you", so we can switch over to it and take a look and all that's in here is just a solution file. And in fact it's pretty barebones.

Now, here's where you might be thinking, "Oh, great, so I'm gonna add multiple projects to this, do I have to learn this solution file format?" And it turns out you don't because dotnet new is here to help you again. Dotnet new has a web API template, earlier I used the MVC template and if I wanted to replicate what I just showed you with that simple PeopleApi, I could do it this way. I could say I want you to create a new project called PeopleApi, I want you to put it in the PeopleApi folder, under the folder that I'm in and it does that and we can even see it already, it's already there. This is kind of the way Visual Studio sets up things, right?

And then the problem is though is if we take a look at the solution again, nothing's changed here, so how would it know? Well, there's a command for that too. .NET has SLN commands to help you manage your solution files in a folder and if I say dotnet SLN add, and I tell it, "What I need you to do is I need you to go dive into that PeopleApi folder and find the CS.proj in there." Then it says, "Okay, I'll go ahead and add it to the solution" and now the solution's getting too big to see just in terminal. Unless I make the window bigger.

So I'm gonna go ahead and open Code. And when Visual Studio Code opens you're gonna see that this time it says, "Well, wait a second, I see there's a solution file here" and the dotnet new command added everything that the solution file needed to add this project, you can even remove projects later. You get this command line Visual Studio add/remove project support and here is that PeopleApi. And I could come back out to the terminal and I think you saw in that example there was a class library. Well, there's a class library template too, it just provides you, if you're familiar with the class library template in Visual Studio, just a class, it's not trying to be ASP.NET MVC or anything like that but what if you have some kind of service library that your API called out to.

Then what I'm doing here is I'm saying, "Let's make that project. Go ahead and put it in that subfolder." It did it, we can see, we got PeopleApi and that simple service library so I can dotnet, I'm gonna add that to this solution with dotnet sln add. And tell it, "Dive into the service library folder and find the CS.proj file."

Once it does that, if I come back over here to Visual Studio Code, I need the Visual Studio Code we were working on though. The solution now knows about both projects. Both of these fields are here and when you build the solution, when you build, when I say dotnet build from in here it picks up that you have a solution file, builds dependencies, keeps track of all of that for you, I can go do that out of the terminal or I could even do that from within here. You can bring up an integrated terminal from within Visual Studio Code. If you ever forget what shortcut keys are like I have, I can do control+shift+P and bring up this command palette and say well, I wanna open a new terminal.

So right here inside Visual Studio Code, that's not what I wanted. I wanted ... there's built-in terminal. Looks like that's what I get for not remembering the shortcut keys, so what I'm gonna do is I'm gonna say I want .NET Core launch JSON and then it'll go ahead and build this. That's not what's super important here, I wanted to show that you can have multiple projects in a solution and the dotnet command is your pathway to managing projects and solutions if you don't have a tool like Rider or Visual Studio.

Now, the point of this talk is not to tell you not to use Sharp tools, not to use tools that do things for you. Part of it is to show you that this is all being built at a command line level using base tools that can be scripted, that might in build scenarios, in automated test scenarios or, eventually, those same tools can be implemented in IDEs so that when you say do something in an IDE, it does the exact same thing as if you do it from the command line, because how frustrating it is when that's not the case.

Publishing and Deployment Examples

Let's finish things off by taking a look at how deployment works. You can create new projects with the dotnet command, you can bring projects directly over from Visual Studio. I also showed that you can use JetBrains Rider and then there's the Yeoman Generator, where you can say yeoasp dotnet and you get a console experience to help you create your projects.

Now, you have a lot of options if you wanted to deploy to the cloud with ASP.NET Core. You could use Amazon Webservices, they even have blog posts showing you how you can deploy an ASP.NET Core application using Beanstalk, which is very similar to Azure Web Apps. They're both essentially about handing it over code and forgetting about the infrastructure and the scaling.

You can use .NET Core in AWS Lambda projects. You can use it with the Google Cloud platform. There's a demonstration Scott Hanselman did where he tried out the Google Cloud platform with ASP.NET Core. And on the Google Cloud platform blog they talked about using containers and Kubernetes all in their cloud environment.

Speaking of containers, containers, if you know about Docker and containerization and you wanna try this out, you don't have to get tied to any platform as a service offering, whether it's Azure Web Apps or Elastic Beanstalk or something on Google Cloud, you could say, "Hey, I'm gonna use containers on my own infrastructure, I'll use them on VMs", and all those clouds I just mentioned, they have options too for hosting containers in a more platform as a service model.

Let's take a look at how quickly you can take your .NET Core project, create Docker image and even get it published up to the cloud, and, again, you could use any cloud you want in this case. Let's see what that looks like.

What I have, let me fix this terminal up a little bit here, I have another solution called MVC2Docker, and it's based on that MVC template that you saw at first. I'm gonna go ahead, instead of trying to find the Visual Studio that has this running we'll just open another one. This is the MVC template with just a minor change, and you can see the change right here, the Docker file.

What's a Docker file? If you're unfamiliar with Docker, this is like the directive for how to build an image that'll become a self-contained Docker container, that the bits never change, they're immutable and you can basically send those off to either your own infrastructure, your own Docker hosting or use any Docker cloud provider here so it doesn't really matter.

It's a pretty simple format, it's pretty readable even. Microsoft has images and they have a .NET image, and I'm just saying here, go ahead and take the latest. You're seeing Visual Studio Code is giving me some IntelliSense on what these different commands do. Now, I have to tell it where do I wanna get these files from. Well, I'm gonna go out to the terminal in a second and you're gonna see how to publish.

Publishing is the act of using the dotnet command, once again, to publish out files into a folder that are ready to pick up and host somewhere. And in this case, we're gonna say, "Well, I want you to take those files and copy them into the container's App folder."

Now, you probably remember that our MVC app by default runs on port 5000 so we need to have the container expose that port and in order, there's an environment variable that I want set in order to make sure that 5000 is open and communicating with ASP.NET Core and then I gotta tell it, "Well, now what do you run to get things started?"

When you've published your app you don't need to use dotnet run, like I did in the very first demonstration. You can say dotnet and your second command argument is the DLL that you've created, so that's really what I'm saying here, is run dotnet MVC2Docker.dll.

In this MVC2Docker folder the first thing that I have to do in order to publish this is I need to say, I can say dotnet publish and once again it's another command with all kinds of help. You can pick the framework, you can pick the runtime, you can pick where you want it to be output but if you do nothing more than say, "I want you to do dotnet publish" then go ahead and do a release build, which is what I'm saying here with the -c option, then that's gonna go to work and it ends up putting that here in the bin release folder and then it takes the name of your framework and puts it in a publish folder.

So I already knew that that's where that was going to go so it was pretty straightforward for me to just copy that right into the Docker file. Now, I've already created the Docker image. It's time for me to start closing some of these Visual Studio Code instances, I think. Let's see if I can get control of my virtual machine here.

Sorry about this, it looks like combining the streaming with having a few too many things open here ... Okay. I think we're getting better. Yeah, let's go ahead and exit. Alright. Yeah, and the webpage is down so I expect this not to be building. Just for the sake of time, I've already gone ahead and built a Docker image, so let's take a look, if I say, docker run and what I'm gonna do just to kind of prove to you that I'm not using the same exact thing I did before is ... Okay. Do I already have it running? I suppose that's possible. Oh, look at that.

Okay, so I already have this Docker image running, I actually started it twice, it's called Azure Web App on Linux. It was created using the Docker file you saw and so that means that right now on my local machine that same exact app with just a minor change, it's currently running except I've mapped port 5000 to port 8080 so 5000 isn't gonna work anymore because we've turned off that web app, we're not using it so if I go ahead and say localhost:8080 then that's gonna come up.

And I've made just a minor change to this app, I didn't do anything drastic. I got rid of the carousel switching and I changed it to say that it can run in Docker containers just so we can see, like yeah, that's a different app, it's the MVC2Docker app, it's not the one you saw earlier.

I went ahead and I published that out to my own public repository, so I published this Azure web app on Linux. Why? Because I'm gonna use a preview feature in Azure app service called Azure Web Apps on Linux and it was very, very simple for me to just basically tell Azure Web Apps as part of the configuration, you say, "Where's the image?" Oh, it out on DockerHub and it's called azurespaceshot/azurewebapponlinux. Did that and you can see Azure took it, published it out to a URL of my choosing, whole process took about five minutes and here is Docker container running using the preview service, Azure web apps using the Linux containers running my special slight change to the MVC startup app.

Alright. .NET Core is lightweight, it's less intrusive than the .NET Framework, it's cross-platform. You acquire .NET Core on Ubuntu Linux using familiar tools like apt-get. The development experience is .. you can use Visual Studio Code, we took a look at that but you saw that there are other tools as well and I showed that there is a publishing and deployment process.

I made a Docker container. I could've used any cloud service to deploy it or even my own infrastructure. It turns out 45 minutes is just not a lot of time to barrel through everything you might wanna know about .NET and its future, .NET Core, .NET Core and Azure or any other provider. I want you to take a look at these videos, if you wanna see this great video about the history of .NET, Kathleen Dollard just does a wonderful job here, Jon Galloway talking about using in Azure, Jeff Fritz has a wonderful advanced .NET Core talk that really goes in depth, it's a nice deep dive and the last talk I wanted to show you is deploying ASP.NET Core applications using Docker containers, which will go much more in depth than what you saw me do, and if you're not familiar with Docker at all, don't be afraid, it's super easy to get started and it really frees you up to go to whatever cloud, whatever infrastructure you'd like. I think that's about the time that we have, Tony.

Tony:

Yeah, thank you very much, Chris. It was an interesting presentation. I would just ask you about one thing you didn't mention, you didn't mention .NET Native here. Do you have any information about this project, how is it going to be?

Chris:

Yeah, .NET Native, that's a great question. And I think a lot of developers ask about it because a couple of build conferences ago the product team showed .NET Core being compiled with .NET Native. Now, that was a Hello World sample, and this is what I know about .NET Native's current state: it is being used when you build applications for the Windows Store, that your application when you submit it, it gets compiled using .NET Native to native code and then that is what is actually put on folks' computers.

There is some SDK information that you can use to get started with .NET Native but the only workload that I know of right now is the Universal Windows Platform. I do not see any documentation, I haven't seen any update on .NET Native for .NET Core projects, ASP.NET Core specifically or more importantly what I think we all wanna see is on Linux. I mean we've seen the demo but it's been a little while and so I just don't have any more on that. I would love to hear if anybody said, "No, you just missed it" and don't forget build is next week. No idea what's gonna be announced there, I'm not pretending that you should tune in to hear an answer here but it is next week and a lot of times some surprises are saved until then.

Tony:

Okay, thank you. Now we can go ahead and answer some questions of our attendees. I would begin with questions about when the slides will be available and if we would provide the commands that have been used during the presentation and so on, so if you can repeat this information, please, Chris.

Chris:

Yeah, that's a great question. On my blog, chrisgomez.com, you can go ahead and reach the slides today. They're hosted on SlideShare but the second part of that question was about if you wanna recreate some of these demos. That's a good question and you know I think probably demands some roundup blog posts, putting together the documentation and support that I had in order to make this happen there is the dotnet command documentation, there's a Docker startup documentation.

We only got to just scratch the surface today. The time went by really, really fast but I could understand if you want to recreate this, it makes good sense to be a blog series for that. The slides are available now and I will get to work on blog posts to help you replicate what we did with the dotnet command and with the Docker commands.

Tony:

Yeah, that would be great and also don't forget that there will be the recording available so once this live session finishes we will process the recording and all registered people will get the link to the recording along with the questions answered.

 

Q & A

Q: Is if it possible to make a traditional Windows application and/or console application and if it makes sense to replace the .NET Framework with .NET Core?

A: Right, that's a good question. Today if you're using .NET Framework, first of all there's no rush to .NET Core but what you wanna find is what's the feature of .NET Core that you're waiting for and say, "Why, I really could use this."

For one thing it's the cross-platform support and I would just say that the number one workload I'm seeing people head towards is the ASP.NET Core stuff and using ASP.NET Core MVC and Entity Framework Core and things like that.

If you've got an existing application, you have to make that decision on migration because it's not, you don't just simply pick up your code and move it over to a .NET Core project and build it. You got a little bit of a hint when you saw that the .NET Core code that there's no global ASAX anymore if you're used to that. There's a startup.CS and there's a program.CS file. It's a slightly different model, the idea is to keep the concepts intact. You might be missing features that you're used to on the Windows console app that you described that you might have or using right now or that you're getting started on, so double check and see if they're in the .NET Core framework or if they're on the roadmap, otherwise you have both of these options for the foreseeable future.

Q: Is it possible to build daemons with .NET Core?

A: Well, you can build, like I said, you could build console applications if you wanna register it as a daemon. I can't point you to a tutorial or post that I'd seen on that right now. It's an interesting idea and it might be so simple that it would just work. I was just trying to think through my research if I saw anybody specifically reaching out to do that. I don't see why it wouldn't be possible though, because, again, you have two major choices in .NET Core, you have console applications, which is just plain old stuff running in the terminal, or you have this ASP.NET workload, which sets up a server and hosts traditionally built web applications.

Q: What about external DLL files, how can we add them to our projects?

A: Okay, so if you're working purely in Linux, let's see, I think I should be able to ... go ahead and come back here. I'll try and show this but I'll answer the question, is that the CS.proj file still is the place to add package references. It's just that if we're used to Visual Studio, you know, we would just say, we would just add a reference and be done with it. We wouldn't really care that much about what was actually happening under the hood.

But if I go back to this solution project that I created, actually let me do a different one. I want solution, back. I'm gonna just show you just in the CS.proj real quick where that reference got added so that the, in this particular case I know that it's a project reference but it's not the only way to add files. So the solution knows about the two projects, that I already showed but in order for this PeopleApi to use the service library, because in this particular example the values controller is modified so that it's using that service library and it's calling a method on it. It's creating an instance of a class, calling a method on it.

In order for it to know where to reach out to that, there's a different project reference types, so project reference include instead of package reference. What we need to look up here, and I didn't demonstrate, is in the new CS.proj format, you have project reference, package reference, other types of references and you could just take a bare DLL, reference it.

One sneaky way to find out how to do things, quite frankly, because I think most of us are probably Windows developers and have Visual Studio, is go try something in Visual Studio in a .NET Core project and then go check out what it did to the CS.proj file. That is what led me to other research to say, okay, so now that I know that it added this item group, let me go find out what item groups and project references are. It's a reverse engineering way to jumpstart your research but it definitely works.

Q: It's per my knowledge .NET Core has project JSON files for project. Please correct me if I'm wrong. Which .NET Core version has CS bridge files support?

A: Good question because the project JSON file was going to be the way forward, it was gonna be the end of CS.proj, right? You're absolutely right, all through the betas there was a different JSON based format. There was a decision made, I believe it was maybe close to a year ago now that trying to force project JSON onto .NET Core was not going to work. The reason why is that .NET Core was gaining some mind share in other workloads, not just ASP.NET. The Xamarin people got interested, the Unity people got interested, the regular .NET team got interested. That's why today we have the CoreFX repo, which is .NET Framework team traditionally kind of concern, although, remember, it's not the .NET Framework, that is the Windows framework.

Then there is the ASP.NET repo, and that product team is building on top of .NET Core. They decided that instead of making everybody move off of MSBuild and throw away all of that and basically reimplement MSBuild so you could support all these other different types of projects that instead ASP.NET Core went back to MSBuild. This is the final CS.proj.

If you take your .NET Core 1.0 app, which is still project JSON based and you bring it to .NET Core 1.1 there is a migration, the dotnet command will migrate your project JSON to CS.proj for you. I will tell you I've heard that your mileage may vary on that. I haven't moved over, like so many dozens of projects that I can tell you oh, this is the pitfall. And, again, a lot of them are demonstration projects, so those were a piece of cake.

The format going forward is CS.proj. This is what it looks like. So if you're used to looking at a CS.proj file and seeing tons of GUIDs and all kinds of nonsense that you don't understand, there is an effort going on to make this readable, partially so it can be hand edited and partially just so it's not so frustrating. You don't see all of the source files in here anymore. They're assumed to be in your project by default because they're in the folder.

Now, what if you don't want a file in here? There is an exclude option, going the opposite direction. Exclude what you don't want, don't have to list every file. Remember how you would create a new class and that would be a CS.proj change and you'd have to go check that into your source control, and guess what? Someone else created a new class too and that was the worst merge conflict, happened all the time, most frustrating thing in the world. We're getting away from that now, that's kind of nice but yes, the answer is that CS.proj is the way forward and project JSON is .NET Core 1.0 and it's not coming back.

Q: What is the Yeoman about?

A: Yeoman, yeah, I didn't get to show. Yeoman, let's go take a look at what generating a Yeoman project is. Yeoman is an open source project generation, the web's scaffolding tools for modern apps. It's not just to support ASP.NET. But what happened is a lot of the community felt wouldn't it be nice if you could use Yeoman and that generator for ASP.NET, what if you could use that to build projects?

You're gonna see this looks very similar to dotnet new, extremely similar. It's even got a lot of the same APIs, except this is an interactive console, and I'm just gonna say go ahead and make a web application basic, and I'm gonna say, "Oh, I could use Bootstrapper semantic UI, let's do Bootstrap." What do I wanna call the app? I can change the name of it here and it's going to go ahead, create all the files and use Bower to install the client side libraries and you've got another way to build apps.

Now, pros and cons to Yeoman. The pro is it's open source, we can all go work on it however I can tell you that the .NET templating is now also open source so there's an interesting pivot going on. This project is still going, you can see it's a little behind though, they're always trying to catch up to what the .NET product team is doing with the dotnet new command, and you and I are able to contribute to the dotnet new templates today.

We're kind of in an interesting space in wondering should we continue to have the Generator ASP.NET, I'm not part of that project, they may wanna continue on to be an alternative. At the same time you can contribute to dotnet new templates but this is just another way to get things started, I can dotnet restore and dotnet run and this project is gonna work just like as if I used dotnet new.

Q: Is Visual Studio code open source?

A: Visual Studio Code is open source.  You can find the project here: https://github.com/Microsoft/vscode.

Q: How did "dotnet restore" know which packages to restore?

A: When you install the dotnet tool following the instructions on the .NET Core download site (https://www.microsoft.com/net/download/core), a default NuGet Config file is created with a default feed.  You can find this in Ubuntu in the ~/.nuget/NuGet folder.  This can be overridden in your projects if you include a NuGet.Config file.  For more information, read about dotnet restore in the documentation at: https://docs.microsoft.com/en-us/dotnet/core/tools/dotnet-restore

Q: Does ASP.NET Core run on ARM?

A: I haven’t personally investigated ARM, yet.  However, you can see the daily builds for .NET core on various platforms here: https://github.com/dotnet/core-setup#daily-builds. Here you will find builds for ARM versions of Windows and Linux.

An interesting source for information is a recent podcast with Scott Hanselman and his guest Adi Avivi.  In the show, they discuss developing RavenDB on .NET Core for the Raspberry PI: https://www.hanselminutes.com/579/ravendb-the-open-source-nosql-database-for-net-with-adi-avivi

Q: Is there a different NuGet website for Core or it's all in the same place with .net packages?

A: NuGet as a product has evolved to support the needs of .NET Framework and .NET Core.  If you use dotnet new or Visual Studio 2017 to create a new project today, the feed location is https://api.nuget.org/v3/index.json for both. 

Q: Can you provide us the commands that you used in this presentation?

A: Unfortunately, it would take a few posts to recap everything used here to download and install .NET Core and to use the dotnet tool for its various features.  We also quickly published a Docker image and I used one published previously to Docker Hub for the Azure App Service on Linux.  Some great resources to start are:

Step by step instructions to install the .NET Core SDK on Ubuntu Linux: https://www.microsoft.com/net/core#linuxubuntu

dotnet command (https://docs.microsoft.com/en-us/dotnet/core/tools/dotnet) - This documents the various features of the dotnet command line tool.

An overview of the process to create your own Docker images with your application: https://hajekj.net/2016/12/25/building-custom-docker-images-for-use-in-app-service-on-linux/

Using your docker image with Azure App Service for Linux: https://docs.microsoft.com/en-us/azure/app-service-web/app-service-linux-using-custom-docker-image

Q: Does it make sense to use IIS to host an ASP.NET Core application?

A: If you are going to run you ASP.NET Core application on a Windows Server, it absolutely makes sense.  In fact, today it is required to run a full featured web server as a reverse proxy.  .NET Core ships with a lightweight server named Kestrel.  Kestrel has been tuned as a high performance web server built with .NET.  However, it has not to this point been hardened to be the public facing server.

In the Linux world, this had already become more common.  The idea was that programming stacks would ship with small lightweight and fast resource servers, but that you would use an application server to guard it and configure access to it from the outside world.

Please carefully read the section called Set Up A Reverse Proxy in the following documentation discussing how to host ASP.NET Core applications today: https://docs.microsoft.com/en-us/aspnet/core/publishing/

You should also read When to use Kestrel wth a reverse proxy in the documentation: https://docs.microsoft.com/en-us/aspnet/core/fundamentals/servers/kestrel#when-to-use-kestrel-with-a-reverse-proxy.

Finally, to host on IIS, you will need to learn about the ASP.NET Core Module on IIS: https://docs.microsoft.com/en-us/aspnet/core/fundamentals/servers/aspnet-core-module

Q: I noticed that the support for Dependency Injection and IoC is also only minimally supported.

A: ASP.NET Core supports a minimal dependency injection model without any external dependencies. Some developers prefer minimizing dependencies and don’t need more than this minimal model. However, the system is not closed, and other dependency injection systems may be used.

The documentation discusses the built-in system at length and provides an example of using Autofac to replace it in the document called Introduction to Dependency Injection in ASP.NET Core: https://docs.microsoft.com/en-us/aspnet/core/fundamentals/dependency-injection

Q: Did you also try VS for Mac? Can I also use it to build apps with .NET Core?

A: I do not have a Mac and have not tried Visual Studio for Mac.  Visual Studio for Mac was made generally available during the BUILD conference.  Among other features, you can begin creating .NET Core and ASP.NET Core applications with the new IDE.

Q: I have some existing C# libraries that I would like to try on .NET Core for possible use on Linux. Any advice?

A: Research .NET Standard.  There is some common confusion about the difference between .NET Standard and .NET Core.  .NET Standard is a specification.  It defines the APIs that are available at a certain release level.

NET Standard accomplishes this by defining the intersection of APIs available in older platforms (some that existed before anyone had the idea for .NET Standard) and paves the way for newer .NET platforms (which includes newer versions of .NET Core, .NET Framework, and perhaps new “.NET’s” no one has thought of yet) to embrace common sets of APIs.

If you’ve written .NET libraries intended to work on multiple platforms, you may be familiar with Portable Class Libraries.  .NET Standard intends to remedy the problems with PCLs and is the present and future of .NET library compatibility. 

This post on the .NET Blog introduces .NET Standard and links to some valuable living information such as a FAQ and the compatibility matrix:  https://blogs.msdn.microsoft.com/dotnet/2016/09/26/introducing-net-standard/

For documentation on .NET Standard, visit: https://docs.microsoft.com/en-us/dotnet/standard/library

Q: All the things we've done so far are already available in .NET Framework in a very elegant and easy manner. Apart from the Cross platform, why should we go for .NET Core?

A: You are asking a very good question that your team must answer for itself.  If you are satisfied with your solution, .NET Framework and support on Windows Server is not ending.  In fact, I would not expect any kind of announcement that .NET Framework will be superseded.  .NET Framework is the desktop platform for .NET on Windows client and server.  When new Windows features ship, a new .NET Framework often follows.

You may want to research .NET Standard and watch the evolution of that space.  Over time, you could responsibly make sure your internal library code supports a .NET Standard version.  At some point, you could consider a trial run of .NET Core and reuse your internal library investment because .NET Standard enables compatibility across .NET platforms (in this example, between .NET Framework and .NET Core).

The other major feature you may want to keep an eye on and test for yourself is performance.  Besides, cross-platform support, ASP.NET Core aims to be a high performance framework.  If you proved that significant and necessary performance gains could come from switching, that could be a good consideration for doing so.

For each case I have discussed, there should be no immediate urgency on your part.  Your question implies you are very satisfied with your solution.  I would just keep an eye on .NET Standard and see if it makes sense to eventually consider making your libraries implement the standard for future flexibility.

Q: Do we have NuGet package support in Linux?

A: When you use .NET Core or ASP.NET Core, you are retrieving packages from NuGet even for base class library items such as .NET Core itself.  You can created NuGet packages and either post them on internal feeds or the public NuGet feed and target them in your Linux projects.  For example, commonly used NuGet packages such as JSON.NET implement the .NET Standard and are part of the ASP.NET templates for a new project that you might create in Linux.

.NET Core is made up of NuGet packages.  This is a departure from .NET Framework, which was obtained and installed separately.

For more information on NuGet packages and their use in .NET Core, see the article Packages, Metapackages, and Frameworks in the documentation:
https://docs.microsoft.com/en-us/dotnet/core/packages

Q: Is there CMake support for C#? I think I read something about that a while ago...

A: I’m sorry.  I’m pretty unfamiliar with using CMake.  I am familiar with the tool, but have no practical experience with it.  However, I can tell you that CMake is used on .NET Core itself.  For example, the CoreCLR for .NET Core has CMake as a build prerequisite, so if you wanted to contribute to this repository, you would be using CMake:  https://github.com/dotnet/coreclr

Q: Is there a way to execute all the TESTS on the solution using VS Code?

A: The best answer I have for this is to learn about Tasks in Visual Studio Code.  Tasks allow you to setup command line tools to be executed within Visual Studio Code.  You can learn more about Tasks here:  https://code.visualstudio.com/Docs/editor/tasks

Next, you would combine Visual Studio Code tasks with dotnet test.  The dotnet test command will execute a test runner against a compiled .dll.  It is like “dotnet run” but for tests.  MSTest, NUnit, and xUnit are all supported test frameworks.  You can learn more about dotnet test here:  https://docs.microsoft.com/en-us/dotnet/core/tools/dotnet-test

But don’t stop there.  dotnet-watch is a command extension for the dotnet command.  The command doesn’t include watch by default.  You add a reference to your project and now the command “dotnet watch” will run a command of your choosing when files change in the project.  One of the things you could do is automate unit testing every time a file changes by using all of this together.

Scott Hanselman demonstrated bringing this all together in the following blog post: https://www.hanselman.com/blog/UsingDotnetWatchTestForContinuousTestingWithNETCoreAndXUnitnet.aspx
You can learn more at this documentation article called Developing ASP.NET Core apps using dotnet watch:  https://docs.microsoft.com/en-us/aspnet/core/tutorials/dotnet-watch

Q: Can we run Package Manager Console for the Nuget packages?

A: You can continue to use Package Manager Console in Visual Studio in Windows.  On Linux you will be using the command line tools such as “dotnet add package” to add a package to your project from the command line.  You may also edit the project’s .csproj file directly.  The new format is so streamlined it will not take long to understand.

This article discusses the changeover from .xproj to .csproj as .NET Core has matured: https://docs.microsoft.com/en-us/dotnet/core/tools/project-json-to-csproj

Q: Does .NET Core have the same libraries that already existed in ASP.NET?  For example: does System.Web.Security exist in .NET Core?

A: ASP.NET Core does not implement everything that you found in ASP.NET just as .NET Core does not attempt to implement everything found in .NET Framework.  Examples of items left out were some that were very Windows specific in nature, items that customers weren’t using, or items that would benefit from some redesign.

For example, when considering ASP.NET MVC, you will find in ASP.NET Core this is called ASP.NET Core MVC and is a “concept compatible” framework.  You can not simply life your ASP.NET 5 code and use it immediately, but the idea was that the code in ASP.NET Core MVC would be very familiar to an ASP.NET MVC developer, and they would have no problem transitioning to the new framework.

For the record, there is no System.Web.Security namespace today in ASP.NET Core.  The security concepts are presented in this article in the documentation: https://docs.microsoft.com/en-us/aspnet/core/security/

Q: Is it a good idea to invest in containers as a pattern?

A: Containerization was way beyond the scope of this talk.  However, I wanted to point out that .NET Core and ASP.NET Core were “container-ready”.

As a contrast, there was one way to host ASP.NET MVC in ASP.NET 4.6, and that was with IIS.  That automatically means Windows Server.

ASP.NET Core presents many options.  Some are great for your current datacenter, and require little or no change.  Other options, like Docker containers, are good options to explore for the future, especially a move to cloud based container services.

Reasons for using containers is a big topic, but one example of a benefit is that a container represents a complete image of an application.  The bits you run on your development machine once the container is built are identical to the bits running in your datacenter.  You can reduce or eliminate setup instructions and be assured that there isn’t a rogue configuration setting somewhere that makes it work for you but not in production.