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:
cd bin\Release\netcoreapp2.0\publish
dotnet MyApp.dll
Then to deploy I just run a bash script with WSL:
bash deploy.sh
Where 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/ user@remote.example.org/deploy/path
ssh user@remote.example.org "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 -suffix
.
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.