ok you’re confusing a lot of things here and are misunderstanding a lot of core assumptions. I recommend starting with small well-defined goals when trying to learn new technologies to help build understanding of what you’re using.
It sounds like you want to deploy your App in Docker on Linux so just focus on that first. I’d recommend changing the least about your existing environment to minimize the number of new products/technologies you need to learn and use. If you’re used to using VS.NET/R# just use that. .NET Core Apps are cross-platform so you can develop with what you’re comfortable with on Windows and just build and deploy that. e.g. all our .NET Core Apps are developed on Windows and deployed to Linux.
In which case you don’t need any IDE’s installed in your Linux server, you just need to install the .NET Core SDK on your Linux Server. To create a Docker version of your App on Linux you just need a copy of your Source code (e.g. git clone) and run a bash script to build (e.g. docker build) your Docker App from a
DockerFile. Many of our .NET Core Apps contains
Dockerfile in the root of every project. We have a guide on deploying .NET Core Apps with Docker to AWS EC2 which uses Travis CI to build the .NET Core Docker App so we don’t even to use our own Linux server to create the Docker build.
The Docker Apps which don’t have Dockerfile’s are built on Windows, deployed with rsync and run with supervisord which you may want to consider, especially during development since you can build/debug on Windows and run a single bash script with WSL to deploy your App to a remote Linux Server. This is what I do when I want to quickly deploy/test a local .NET Core App on linux.
Publish a Release build of your App with
dotnet publish, e.g:
c:\> dotnet publish -c Release
Which generates a build of your .NET Core App which can be run on any OS with .NET Core installed, e.g. you can test it in Windows by going to the publish output folder and running your Project .dll, e.g:
Then to deploy I just run a bash script with WSL:
deploy.sh just copies the incremental changes to the publish folder with rsync and restarts the monitored supervisor process, e.g:
rsync -avz -e 'ssh' bin/Release/netcoreapp2.0/publish/ firstname.lastname@example.org/deploy/path
ssh email@example.com "sudo supervisorctl restart my-supervisor-task"
You can find some info on setting up supervisor, nginx in Deploying Web Apps.
Forget about this, a deamon is just a background process. All .NET Core Apps are Console Apps, if you’re deploying in a Docker container you just need to run your .NET Core App as the Entry point in your Docker App.
Please always quote and link to the ServiceStack docs you’re referring to, this inference is inaccurate, the docs don’t say anything like this. There’s only 1 .NET Core platform your .NET Core App targets which can be run on the .NET Core runtime of each supported OS (e.g. Win/OSX/Linux). I have no idea where you got the
ASPDOTNETCORE token from, the ALL CAPS makes it look like an Environment variable, although it’s not one that I’ve seen before.
The only thing I can assume you’re referring to is that we changed our .NET Core Apps to use multi stage Docker builds. This just means that we use the
microsoft/aspnetcore-build:2.0 Docker Image to build our App and deploy the published outputs to run in the leaner
microsoft/aspnetcore:2.0 Docker container. This is similar to needing the .NET SDK to build your .NET Framework App and the .NET Runtime to run it.
Please refer to the Microsoft’s docs on Your first ASP.NET Core Docker app. If you haven’t already, please go through this step-by-step guide to deploy a .NET 2.0 Docker App. There is no “ServiceStack specific” steps or configuration for running in Docker which is just a generic container technology used for encapsulating and running any process, of which your .NET Core App is just a process that runs when the Container is started. A ServiceStack .NET Core App is also just a .NET Core App with ServiceStack configured to run as a single .NET Core middleware in its Request pipeline - any docs for deploying .NET Core Apps to Docker is relevant to all .NET Core Apps, since that’s all it is.
No, it has no bearing of what .NET Core template you start with, any of them can run on .NET Core and by extension in a Docker container.
This is irrelevant, you can continue to modularize your App as you wish. Most ServiceStack templates follow the recommended Physical Project structure where your Host project is a thin layer containing your
AppHost its configuration and concrete dependencies. In .NET Core this includes the
Program.cs containing the Console App’s Entry point and
Startup.cs which is akin to
AppHost in ServiceStack where your .NET Core App’s dependencies and middleware/plugins are registered and configured.
The templates ending with
-corefx means ASP.NET Core App running on the .NET Framework, which refers to .NET Framework v4.6.2+ which means Windows only (ignoring Mono in all this). Only .NET Core Apps are cross-platform and can run on Linux. ASP.NET Core Apps can run on .NET Framework in Windows (i.e. ServiceStack templates ending with
-corefx) or on (Windows/OSX/Linux) with .NET Core. If you wish to run in Docker on Linux you need to run on .NET Core which means any project template in ServiceStack .NET Core 2.0 Templates
Note: .NET Core 2.0 templates don’t have any
What you need is to ensure you’re building a .NET Core App which is what’s required for your App to run cross-platform on the .NET Core runtime. Docker is irrelevant since it can run any process and by extension any .NET Core App.
This is a blocker, your App needs to run on .NET Core which means you can’t use anything that doesn’t run on .NET Core. So all your packages/dependencies need to have either .NET Standard or .NET Core App builds. Since ServiceStack v5 nearly all of ServiceStack NuGet packages have both .NET v4.5 and .NET Standard 2.0 builds, the .NET Standard 2.0 builds are what’s used when running in .NET Core.
The only real tip is to target .NET Standard 2.0 in all your libraries which has the broadest and most compatible Surface area of .NET that can be used in .NET Core. ServiceStack-only Apps are trivial to port to .NET Core courtesy of being able to seamlessly integrate your ServiceStack AppHost in .NET Core Apps and most of ServiceStack packages including .NET Standard 2.0 builds which are used in .NET Core. The main difference is having separate WebRootPath and ContentRootPath, which is effectively the main change we needed to do when porting our ServiceStack .NET Framework Live demos to .NET Core - as we’re effectively able to use the existing Service Implementations as-is.
You can’t run anything with .NET Framework-only dependencies on .NET Core so you’re going to need to plan on how you’re going to handle remove that functionality from your App or rewrite it to use replacement deps which does run on .NET Core. For System.Drawing there is CoreCompat.System.Drawing which does run on .NET Core and is what we used in our .NET Core port of Imgur, although we’ve had some load/perf issues with it, so it’s more for compatibility until you can replace it with something more robust. I’d personally use SkiaSharp for new projects since it’s a well maintained wrapper over Google’s SKIA library used in Chrome.
My recommendation would be to go through the Your first ASP.NET Core Docker App so you can get familiar with .NET Core and Docker. Than after you’re comfortable start with one one of ServiceStack’s .NET Core Templates, you probably want to start with the web template since it’s an empty ASP.NET Core Web App then slowly copy over functionality from your existing App whilst verifying your App still builds.
Sounds like your biggest issue is going to be how you’re going to handle functionality that’s not available in .NET Core, so I would first look at identifying all dependencies which don’t support .NET Core and workout how you plan to work around it with your .NET Core port. This may potentially be a blocker for being able to port your App, so it’s better to try identify it upfront and save any potential wasted effort. When no replacements are possible you may need to extract that functionality behind a generic .NET Framework Micro Service on Windows which your .NET Core Apps call when it needs to execute functionality not available in .NET Core.