Page 25 - MSDN Magazine, November 2018

or runtimes should be targeted when creating an SCD, while self- contained signals that a self-contained package with the runtime needs to be created. If the runtime option is passed, the self- contained option is automatically applied.
Other choices to note are the no-restore and no-build options. The no-restore option won’t execute the implicit restore when running the publish command. The no-build option won’t build the project or run the restore command, so the publish command will run against the existing build. This is useful in continuous integration/continuous deployment scenarios because a build and restore won’t be triggered multiple times. Last, the framework option allows the framework version to be specified. The official documentation can be found at bit.ly/2pizcOL.
Framework-Dependent Deployments
FDDs are the default when executing the publish command under the .NET Core CLI. The publish command creates a platform- agnostic application that can run on any .NET Core runtime that’s equivalent to or newer than the minor version used to build the application (though version 2.0 won’t run something that targets 1.x, and 3.0 won’t run something that targets 2.x). Because the targeted runtime isn’t packaged with the application, this option yields the smallest package. If several applications are going to be deployed to a system, allowing the runtime to be shared among the applications reduces overall memory and disk usage on the system. Another advantage of the shared runtime is that any future runtime updates will apply to all applications.
Let’s walk through publishing the sample application as an FDD by entering the following at the command line:
> dotnet publish
This creates output in the bin\Debug\netcoreapp2.0 folder, including the file publishing.dll. This 5KB DLL is the application. Next, run the application using the dotnet CLI, like so:
> dotnet Publishing.dll Jamie Hello Jamie!
That’s all there is to it.
FDD provides several benefits, including a smaller deployment package, a system-managed runtime, and the ability to share the runtime among multiple apps to reduce disk and memory usage. The app is also guaranteed to run on any platform that has a com- patible runtime installed.
The disadvantages of FDDs are that system-wide runtime updates could cause issues as they might be incompatible, and that your application can only run on the framework version (or newer) with which it was compiled. It also requires users to have installed that version of the .NET Core runtime on their machine prior to executing the application.
Self-Contained Deployment
Now let’s look at the second approach to publishing provided with the .NET Core CLI—SCDs. I’ll use the same publishing command as I did before, but this time I’ll pass a runtime identifier (RID) as an option to the publish command. The RID tells the .NET Core CLI which platform or platforms to target when creating the application. In this example, I’ll create a Windows 10 x64 build of the application. Any platform can be targeted from any OS, msdnmagazine.com
allowing executables for other OSes to be created from Windows. Here’s the command I use for this sample:
> dotnet publish -r win10-x64
Notice that there’s a subfolder created under the netcoreapp2.0 folder that’s named after the target runtime passed. Inside the win10-x64 folder, you’ll see that there’s now an executable instead of a DLL. That executable is 77KB, which is 72KB more than the previ- ous application. I can run the executable to show that it still works:
> .\Publishing.exe Jamie Hello Jamie!
Now that I have an SCD for Windows 10 x64, I’ll build one that targets Ubuntu x64, like so:
> dotnet publish -r ubuntu-x64
I can then utilize WSL to test that the Ubuntu version executes as desired. I open WSL from Windows and make the newly cre- ated application executable, so I can I execute it to make sure it’s working. Here’s that input and the resulting output:
> chmod +x Publishing > ./Publishing Jamie Hello Jamie!
The upside of SCD is that the .NET Core runtime is con- trolled and shipped with your application. This is convenient for users, as they aren’t required to install the runtime, and any system runtime changes won’t impact your application. On the other hand, SCD creates larger deployment packages because the runtime is shipped with the application. You also need to know your target platforms in advance to generate packages for each target. Moreover, every time there’s a runtime update that includes security or bug fixes, you must republish every appli- cation on the machine to get these fixes rather than installing a single machine-wide runtime update.
In the past, the approach to distributing .NET applications had been to require the .NET Framework to be installed or to package it with the installer. With .NET Core and SCDs, there’s no longer a need to create a special installer to deliver a basic application.
As positive as SCD is, there’s still one looming issue when deploying these applications to a Linux system. The runtime depen- dencies for .NET Core aren’t included with SCDs, which means users won’t need to install the runtime. However, users will need to install six dependencies from the package manager for the Linux distribution. For example, on Ubuntu the following depen- dencies will still need to be installed:
liblttng-ust0 libcurl3 libssl1.0.0 libkrb5-3
zlib1g
libicu52 (for 14.x) libicu55 (for 16.x) libicu57 (for 17.x) libicu60 (for 18.x)
To resolve this issue, a developer needs to package the SCD application in a native package format for the distribution so additional dependencies can be defined.
While this may be a negative, the positive is that users don’t have to add any of the additional package repositories that would be required if the .NET Core runtime needs to be installed.
SCD is fascinating and deserves more discussion. Though there are several pieces that go into making SCD work, as part of
November 2018 19