46

As I currently understand in the full .NET Framework when we install the framework to the machine it deploys the whole BCL to the computer's GAC. In that way when we develop a software with .NET and deploy to that computer it'll use the BCL assemblies which are made available in the GAC when the .NET Framework itself was installed.

Now, as I know CoreFX is the equivalent of the BCL for the new .NET Core. The main difference, however, is that we can specify in the project.json exactly which pieces of the CoreFX we need.

My question is: when we deploy .NET Core apps, is there any GAC equivalent on the production environment? So, when we deploy the app to be executed, is there any central location in the computer where the app will look to see if the whole CoreFX is available?

user1620696
  • 10,825
  • 13
  • 60
  • 81
  • AOT compilation (Ahead-Of-Time) is likely to be the dominant way to create deployable executables, no framework required at all. Pretty necessary to not get killed on cold-starts. They are working on it, CoreRT project. These kind of questions are a lot more useful when you ask them a year from now. – Hans Passant Feb 21 '16 at 16:07
  • I saw that CoreRT would be the responsible for doing this AOT compilation which in the end would produce just a native executable. But there's also the CoreCLR which works with JIT compilation right? In that case if one uses it, is there something like the GAC where the assemblies from the CoreFX will be searched? – user1620696 Feb 21 '16 at 16:09

2 Answers2

37

Edit 2017-09-01

Somewhat analogous to the GAC, .NET Core 2.0 introduces the "Runtime package store":

Starting with .NET Core 2.0, it's possible to package and deploy apps against a known set of packages that exist in the target environment. The benefits are faster deployments, lower disk space use, and improved startup performance in some cases.

This feature is implemented as a runtime package store, which is a directory on disk where packages are stored (typically at /usr/local/share/dotnet/store on macOS/Linux and C:/Program Files/dotnet/store on Windows).

You are looking for a "Framework-dependent deployment". From the docs:

You can create two types of deployments for .NET Core applications:

  • Framework-dependent deployment. As the name implies, framework-dependent deployment (FDD) relies on a shared system-wide version of .NET Core to be present on the target system. Because .NET Core is already present, your app is also portable between installations of .NET Core. Your app contains only its own code and any third-party dependencies that are outside of the .NET Core libraries. FDDs contain .dll files that can be launched by using the dotnet utility from the command line. For example, dotnet app.dll runs an application named app.

  • Self-contained deployment. Unlike FDD, a self-contained deployment (SCD) does not rely on any shared components to be present on the target system. All components, including both .NET Core libraries and the .NET Core runtime, are included with the application and are isolated from other .NET Core applications. SCDs include an executable (such as app.exe on Windows platforms for an application named app), which is a renamed version of the platform-specific .NET Core host, and a .dll file (such as app.dll), which is the actual application.

Stajs
  • 1,255
  • 11
  • 21
13

No there's not, not in the way you think of the GAC. Core apps are meant to be isolated from each other, so you can patch one without fear of affecting the others. You ship all the packages you need with the app.

There's a servicing directory that can be used to ship updates for Core components, but it's to swap them out entirely, not enable side by side versioning, and it's only for updates shipped via Microsoft Update.

jpierson
  • 16,435
  • 14
  • 105
  • 149
blowdart
  • 55,577
  • 12
  • 114
  • 149
  • Thanks @blowdart. I knew that for .NET Core we could ship all the packages we need with the app, but I thought this was just an option. So when developing .NET Core apps we *always* need to ship the packages with the app? – user1620696 Feb 21 '16 at 17:06
  • There's the concept of a local cache, or at least there was with DNX, but when you ship locally you override it. It's more for "missing" packages. – blowdart Feb 21 '16 at 17:07