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?
GAC is a machine wide a local cache of assemblies maintained by the . NET Framework.
Net doesn't change the . Net Core architecture, but adds some additional benefits including Core Runtime & API Performance enhancement, and deployment flexibility. . Net 5 also supports some major sub-framework for desktop development like Entity Framework, GDI+, LINQ, and ADO.Net.
NET Core will be renamed . NET 5 to be released in November 2020 and the traditional .
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 namedapp
.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 namedapp
), which is a renamed version of the platform-specific .NET Core host, and a .dll file (such asapp.dll
), which is the actual application.
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With