Is this the location of the GAC?
C:\Windows\Microsoft.NET\assembly\GAC_MSIL
If so, then what is C:\Windows\assembly?
The answer depends on the version of the .NET Framework being used. Multiple versions can be installed side by side (which is probably the case for you), and programs written for an older version use that version if it's installed.
Before 4.0
All versions before 4.0 use %WINDIR%\assembly (in your case, C:\Windows\assembly) for the GAC. This directory uses a special Explorer view (the Assembly Cache Viewer) to view and manage the GAC.
Since 4.0
Versions since 4.0 use %WINDIR%\Microsoft.NET\assembly (in your case, C:\Windows\Microsoft.NET\assembly) for the GAC. Since 4.0, the Assembly Cache Viewer is obsolete. Explorer displays the GAC directory just like a regular directory.
Related
I found some interesting articles about the difficulties of .NET Core SDK/runtime/tooling versioning, for example:
.NET Core Versioning
.NET Core versioning
Supporting both LTS and Current releases for ASP.NET Core
However I still don't really know how to deal with all of this in practice:
Given a project with a number of .Net Core dependencies. How can I determine which version of the runtime needs to be available on the end-users machine?
Does the runtime version need to match exactly, or can the runtime installed on the end-users machine be newer than the required version?
Let's say I want to stick to some LTS version of the runtime. How can I determine the version of the packages I need to reference? How can I make sure that no newer packages are referenced?
Oh, and there is one more:
Once I know which runtime version is required on the end-users machine, how can I determine (programmatically) if that version of the runtime (or a newer, backwards compatible one) is available?
First, let's look at what happens when a portable .NET Core application is run via dotnet yourapp.dll:
The muxer executable (dotnet.exeon windows) loads a version of the host framework resolver (hostfxr) from a folder beneath host\fxr\ next to dotnet.exe.
The host framework resolver looks at yourapp.runtimeconfig.json (or a different file if configured when using dotnet exec) to find out which framework you are targeting. This extracts a framework name (Microsoft.NETCore.App) and a version (e.g. 1.1.0).
It then looks inside the shared\Microsoft.NETCore.App folder (based on the framework name) for available versions.
Based on the available versions and the framework version from yourapp.runtimeconfig.json it determines which version to use. Or it may decide to error out and complain that the required version is not available.
👆 this is the hard and sometimes confusing part.
Currently (.NET Core 1.0), the framework resolver will use the latest patch version available for the major and minor version specified in the runtimeconfig.json but no version lower than the runtimeconfig.json specifies. E.g. a 1.1.2 runtime will be used if the runtime config specifies 1.1.1, but if on only 1.1.0 is available, it will log an error. There is also no version roll-forward across minor versions. So an app with a runtime config set to 1.0.0 will trigger an error if only any 1.1.* is installed.
For .NET Core 2.0, a minor version roll-forward is planned in case no matching minor version is found - if a 1.0.5 and 1.1.2 runtime are installed, an app with runtime config of 1.0.4 will be run on the 1.0.5 runtime. If only 1.1.2 is installed, the same app will be run on 1.1.2. If only 2.0.0 is installed, the same app will not be able to run. See GitHub issue for .NET Core 2+ Version Binding for details and discussion about this change.
Let's look at where the value in the runtime config comes from. When you target the framework netcoreapp1.1, the tooling you use will determine:
Which NuGet package (+ version) to use so you get the compilation references to be able to compile.
Which version to write into the yourapp.runtimeconfig.json
In the csproj file, the version of the framework to use is determined by the property
<RuntimeFrameworkVersion>1.1.2</RuntimeFrameworkVersion>
If this value is not specified, the tooling will use the newest version it knows about
for .NET Core 1.0 and 1.1.
For .NET Core 2.0, portable applications will use the patch version 0 by default and self-contained applications will use the latest version that the tooling knows about. This change is being made because tooling (CLI "SDK" / Visual Studio) updates and runtime updates have been released at the same time so apps would require the new runtime to be installed on target systems by default. If that runtime was not installed, an error would occur. This was bad if it takes a few days for hosters to catch up with testing and installing updates. The version can still be enforced / required by setting <RuntimeFrameworkVersion>explicitly.
About packages: The packages that 1.* tooling uses are meta-packages. So referencing Microsoft.NETCore.App or NETStandard.Library would pull in a lot of other NuGet packages. This is no longer the case for .NET Core 2.0 and .NET Standard 2.0 - the packages are flat and contain everything you need. Also, when you create a NuGet package, those packages will no longer be dependencies of the resulting package. They are used for compilation references only, with the exception of Microsoft.NETCore.App knowing which additional packages to pull in for self-contained applications.
Previously, a library built with NETStandard.Library version 1.6.1 would cause consuming .NET Core 1.0 applications to contain a lot of updated DLL files that are actually part of .NET Core 1.1. I do not know if this means that LTS policies will cover or not cover applications that end up with those DLLs. And it is hard to see which .NET Core version they belong to since the package versions they originate from are usually 4.0.*, 4.1.* and 4.3.*.
For ASP.NET Core packages, it is a lot easier since they are versioned 1.0.* and 1.1.* so you can see which "branch" they originate from and you have more control over the versions used by specifying the NuGet packages in the csproj file.
To recap, let's get back to the original questions:
Given a project with a number of .Net Core dependencies. How can I determine which version of the runtime needs to be available on the
end-users machine?
The real dependency here is which version of Microsoft.NETCore.App is written to the yourapp.runtimeconfig.json file. A version of the same major and minor number and same or higher patch number has to be installed, the latest patch version will be used. When the .NET Core 2.0 resolver is installed, alternatively the highest version with the same major number will be used instead, but a version of the same major and minor number will be preferred.
If only runtimes with newer major versions are installed, the app cannot be run on the target system. (e.g. 1.0.5 app and only 2.0.0 runtime)
Does the runtime version need to match exactly, or can the runtime installed on the end-users machine be newer than the required version?
The version of the runtime config is a hard minimum. For choosing the right version of newer runtimes see above.
Let's say I want to stick to some LTS version of the runtime. How can I determine the version of the packages I need to reference? How
can I make sure that no newer packages are referenced?
The version of Microsoft.NETCore.App will automatically be inferred from the target framework (e.g. netcoreapp1.0 => 1.0.*, patch version depending on the version of the tooling you use). To override the version, set the <RuntimeFrameworkVersion> property as discussed above.
If new NuGet packages are referenced transitively, e.g. by consuming Newtonsoft.Json 10.0.0 from a .NET Core 1.0 app (see GitHub issue), some extra DLLs might be added to the project's output. These are newer versions of DLLs that are part of the runtime, but override the versions from the runtime.
If you really want to make sure that you don't use any FTS versions, you'd need to explicitly reference all these packages in your csproj file so NuGet will downgrade the version of the packages used (and emit package downgrade warnings).
The problem here is that there hasn't been a case where an issue has not been fixed in 1.0 and 1.1 packages. If this will be an issue in the future when 1.0 and 2.0 are supported but 1.1 no longer, we will have to see how this will be handled case by case. (though there certainly be pressure/requests from the community to release updated 1.1 versions as well even if not covered by Microsoft's support).
If you use a 2.0 or higher version, those implementation packages will be trimmed out of the dependency graph of your app and no longer be considered when deploying. This happens as part of the conflict resolution logic that knows that the new flat package contains the same DLL files as the individual packages.
Once I know which runtime version is required on the end-users machine, how can I determine (programmatically) if that version of the
runtime (or a newer, backwards compatible one) is available?
Scan the shared\Microsoft.NETCore.App subfolders next to dotnet.exe and implement the same logic used by the host.
PInvoke into the native code of latest hostfxr.dll in host\fxr next to dotnet.exe. But this is fairly complicated to do.
According to MSDN documentation,
public static Assembly LoadFrom(string assemblyFile)
throws BadImageFormatException if
assemblyFile is not a valid assembly.
-or-
Version 2.0 or later of the common language runtime is currently loaded
and assemblyFile was compiled with a later version.
Actually, there is one extra case - loading assembly that is built for x86 from assembly that runs in x64 mode. Maybe it is included in "not a valid assembly" statement, I don't know. But this is reasonable cause of exception.
Ok, but in .NET 4.5 it doesn't! I have a .NET 4.5 WPF app, that loads different appliations for some reason. It is building for Any CPU and I'm starting it on x64 Win 7. I've been testing it on one executable, that is built for .NET 4.0 x86, and it worked fine. But when I switched my app to .NET 4.0 it began to crash on Assembly.Load method!
So, my question is, am I missing something? If not, then how did they do that - loading x86 assembly from x64 process in .NET 4.5? I'm lacking some understanding at this point.
Update
Thanks to Hans Passant, I've figured out my mistake. Actually the behavior of Assembly.Load is no different. It turned out, I didn't notice Prefer 32-bit option in project settings (or Prefer32Bit tag in .csproj file). That's why my process in .NET 4.5 ran in a 32-bit mode. This setting was true when I created WPF .NET 4.5 project. Then, when I swithced to .NET 4.0 it became inactive because there was no such an option in .NET 4.0. And when I switched back to .NET 4.5 it became false, which is so, I guess, for compatibility purpose.
Let's clear one assumption off the table quickly, there is no possible way to have different behavior on a machine that has .NET 4.5 installed. Targeting 4.0 makes no difference at runtime. The only thing that does is select a different set of reference assemblies, they prevent you from accidentally using a class that's available on .NET 4.5 but not on .NET 4.0.
There is no way to have both 4.0 and 4.5 installed on the same machine. .NET 4.5 is not a side-by-side version of the .NET framework, like 3.5 and 4.0 are side-by-side. Installing 4.5 replaces an installed 4.0 version. The CLR, the jitter, all the runtime assemblies plus the C# compiler.
It is best here to focus on the Platform target setting of your EXE project, that's the one that selects the bitness of the process. The kind of mistakes you can make is forgetting that the setting can be different for the Debug vs the Release build. And assuming that the "Active solution platform" combobox in Build + Configuration Manager has any effect. It doesn't, only the Project + Properties, Build tab, Platform target setting matters. This is a very awkward trap that many programmers have fallen into.
I am using the namespace System.Windows.Forms.DataVisualization.Charting to create a Chart object on a form. This DLL is not a part of the basic Windows install, so I shall need to include it in my package when I distribute my application.
I am aware of the new version of GacUtil.exe and also that Gacutil.exe is only for development purposes and should not be used to install production assemblies into the global assembly cache. Let's just assume that I have no choice in the matter and have to do it this way due to the use of a proprietary package distribution system. =)
Edit/Update: In the 2.0 runtime, even though some PC's did not have GacUtil.exe present on the intended installation PC, I could drop GacUtil.exe (2.0 version) on the PC and I could then GAC whatever extra assemblies I needed. This appears to be a problem in the 4.0 runtime. Even though I have copied GacUtil.exe (4.0) to the destination PC, I get no feedback when running it against the needed assembly. End Edit/Update
Now, on my PC (the development PC), I can add the DLL to the GAC without any problems:
However, on a clean Windows 7 PC, with the same DLL and the same version of GacUtil.exe I get this:
Why the discrepancy? Does the new GacUtil.exe depend upon something that this PC doesn't have?
Ok, I ended up having two problems, one of them being a moot point in the end.
Problem #1: GacUtil.exe (for the 4.0 CLR) has Dependencies
When i copy over the folder in which GacUtil.exe resides, the problem of adding the assembly vanishes:
This ended up being a moot point, however, because even though the file was in the 4.0 GAC on the client machine, I still had the crash. I realized at that point that the problem was that I am not targeting the 4.0 GAC - I'm targeting the 2.0 GAC. The file I was trying to add to the GAC this whole time was a 4.0 version of the file. This was the piece I wasn't understanding.
Problem #2: There are separate 4.0 and 2.0 versions of "GACable" DLL's, and they are not backwards compatible
I simply went back to my development machine and grabbed the 3.5 version of the DLL in question (System.Windows.Forms.DataVisualization), added it to the 2.0 GAC on the client PC, and crisis averted.
You can run the 4.0 Gacutil from your own folder if you add a "1033" subfolder and include the file, gacutlrc.dll, which can be found in the same subfolder in the standard location.
i've made an assembly in the .net framework that I intend to publish to the GAC but I can't find the gacutil utlity.
I've been googling a while and I've found a lot of suggestions, but nothing works:
Copy the assemby to %window%\assemby [DOES NOT WORK]
Copy the assemby to %window%\Microsoft.NET\assembly [DOES NOT
WORK]
C:\Program Files\Microsoft SDKs\Windows\v6.0A\Bin\gacutil.exe /i
"assembly" [returns an error: this assembly is built by a runtime newer
than the currently loaded runtime and cannot be loaded]
Does anyone have idea to solve this?
If you've got VS2010 installed, you ought to find a .NET 4.0 gacutil at
C:\Program Files\Microsoft SDKs\Windows\v7.0A\bin\NETFX 4.0 Tools
The 7.0A Windows SDK should have been installed alongside VS2010 - 6.0A will have been installed with VS2008, and hence won't have .NET 4.0 support.
VS 2012/13 Win 7 64 bit
gacutil.exe is located in
C:\Program Files (x86)\Microsoft SDKs\Windows\v8.0A\bin\NETFX 4.0 Tools
There is no Gacutil included in the .net 4.0 standard installation. They have moved the GAC too, from %Windir%\assembly to %Windir%\Microsoft.NET\Assembly.
They havent' even bothered adding a "special view" for the folder in Windows explorer, as they have for the .net 1.0/2.0 GAC.
Gacutil is part of the Windows SDK, so if you want to use it on your developement machine, just install the Windows SDK for your current platform. Then you will find it somewhere like this (depending on your SDK version):
C:\Program Files\Microsoft SDKs\Windows\v7.0A\bin\NETFX 4.0 Tools
There is a discussion on the new GAC here: .NET 4.0 has a new GAC, why?
If you want to install something in GAC on a production machine, you need to do it the "proper" way (gacutil was never meant as a tool for installing stuff on production servers, only as a development tool), with a Windows Installer, or with other tools. You can e.g. do it with PowerShell and the System.EnterpriseServices dll.
On a general note, and coming from several years of experience, I would personally strongly recommend against using GAC at all. Your application will always work if you deploy the DLL with each application in its bin folder as well. Yes, you will get multiple copies of the DLL on your server if you have e.g. multiple web apps on one server, but it's definitely worth the flexibility of being able to upgrade one application without breaking the others (by introducing an incompatible version of the shared DLL in the GAC).
There actually is now a GAC Utility for .NET 4.0. It is found in the Microsoft Windows 7 and .NET 4.0 SDK (the SDK supports multiple OSs -- not just Windows 7 -- so if you are using a later OS from Microsoft the odds are good that it's supported).
This is the SDK. You can download the ISO or do a Web install. Kind-of overkill to download the entire thing if all you want is the GAC Util; however, it does work.
I installed the VS2010 and .NET 4.0, then I compiled an assembly and ran the gacutil using the exe available on
%ProgramFiles%\Microsoft SDKs\Windows\v7.0A\Bin\NETFX 4.0 Tools
The output of the executable said the assembly was sucessfully installed on Global Assembly Cache. However, when I go to %WINDIR%\assembly folder I cannot find the assembly I installed using the .NET Framework 4.0 gacutil.
I've seen some posts saying the .NET Framework 4.0 has a separated GAC, but what I haven't found was where it is located.
May someone to help me to check where can I see the Global Assembly Cache of .NET Framework, as it used to work on previous version (%WINDIR%\assembly)?
Yes, there are two distinct GACs as from .NET 4.0
See here: .NET 4.0 has a new GAC, why?
As stated below, the new physical location is %windir%\Microsoft.NET\assembly\ (you can interogate it using the dir command at a command prompt if you're interested).
It's worth noting that applications running up to the 2.0 CLR will not even be able to see assemblies in the new GAC.
Try:
%windir%\Microsoft.NET\assembly\
Due to Common Language Runtime (CLR) changes, the contents of the Global Assembly Cache (GAC) is split between two directories:
%WINDIR%\assembly\
%WINDIR%\Microsoft.NET\assembly\
If you run the command gacutil -l from the directory of your project's .csproj file, you will get a printout of the contents of the GAC (the contents of both directories).