We recently published these Knowledge Base articles: Changing a .NET Core Application from Framework-Dependent to Self-Contained with Visual Studio 2015 Changing a .NET Core Application from Framework-Dependent to Self-Contained with Visual Studio 2017 As you can see, we're moving away from "framework dependent" implementation to "self contained," meaning none of the Core framework would be on the server, it would all be uploaded by you and live and run in your space on the server. There are a couple of advantages to doing it that way, first, you would only upload the components that your application requires, which means lower overhead. Second, and most importantly, the development cadence for .NET Core is too rapid for a commercial host like us to reasonably keep up with. .NET Core updates are not included in the monthly Windows Server Updates (which are automated), and they seem to be taking the "modern" approach of: release-quickly-and-often-and-let-the-users-find-the-bugs. Which means more updates more frequently, and that isn't workable when you have dozens (or hundreds) of servers to update manually every time they decide to push a release. So self-contained is really the only implementation that makes sense. The downside of self-contained implementation is many of the resources used by .NET Core move from the server to the user, so memory use and storage space for individual user accounts are affected. We can't say how much they'll be affected, because every implementation will be different, depending on which elements of Core are used.
