If you suddenly missed, then .NET is now open source, and .NET Core is a free, open source, cross-platform framework that you can download and run in a time <10 minutes. You can get it on Mac, Windows and half a dozen Unixes from the
dot.net website
. Try it along with the free, cross-platform Visual Studio Code and you will write in C # and F # anytime, anywhere.
OK, in view of the above, there are two ways to deploy .NET Core applications. This is FDD and SCD. Since TBA (three-letter acronyms) is stupid, this is Framework-dependent and Self-contained Deployment.
When .NET Core is installed, it is, for example, in C: \ program files \ dotnet on Windows. In the “Shared” directory there is a bunch of .NET pieces, which, let's say, shared ie. are common. There may be many directories inside, as you can see below in my folder in the screenshot. You may have many .NET Core installations.

')
When you install your application and its dependencies, BUT NOT the .NET Core itself, then you depend on the .NET Core that is already installed on the target machine. This is great for Web Apps or for systems with a lot of applications, but what if I want to write an application and give it to you as a zip or usb flash drive and I just want it to work. I can include .NET Core in the bargain, then from all this it will turn out Self Contained Deployment.
I will make my “Hello World” application larger than it would be using a system-wide installation, but I will know that it will just work because it is completely independent.
If I deploy my application with .NET Core, then it is important to remember that I will be responsible for the .NET Core service and keeping it up-to-date. I also need to choose target platforms in advance. If I want it to run on Mac, Windows and Linux, and just work, then I need to enable these target platforms and build packages for them. It's all intuitive, but it's good to know for sure.
For example, I will take my small application (I use a simple “dotnet new” application) and modify project.json in a text editor.
My application is .NETCore.App, but it will not use the .NET Core platform that is installed. It will use the local version so I will remove the “type =“ platform ”” from the dependencies. Here is what will remain:
"frameworks": { "netcoreapp1.0": { "dependencies": { "Microsoft.NETCore.App": { "version": "1.0.1" } } } }
Next, I will add a runtimes section to indicate which runtime I want to set. A list of all the
Runtime IDE is here.
"runtimes": { "win10-x64": {}, "osx.10.10-x64": {}, "ubuntu.14.04-x64": {} }
Translator's note (just in case): this section is added before the last bracketAfter launching the dotnet restore command, you will want to build a project for each of the runtime in the following way:
dotnet build -r win10-x64 dotnet build -r osx.10.10-x64 dotnet build -r ubuntu.14.04-x64
And after that publish the release after you have tested, etc.
dotnet publish -c release -r win10-x64 dotnet publish -c release -r osx.10.10-x64 dotnet publish -c release -r ubuntu.14.04-x64
After this is done, I will get my portable application in n folders, ready for deployment on any system I want.

You can see in the Win10 directory the application “MYAPPLICATION.exe” (mine is called scd.exe) which can be started right away, and not with the help of these pieces, like the “dotnet run” that developers use.

In
.NET Core Docs there is a lot of good documentation about how to configure and determine exactly what will be deployed with your self-contained application. You can also pay attention to the
trimming to .NET Core article, where it is said that in the future everything will become more automatic, possibly down to the method level.