I've installed the full version of .NET Framework 4 (Client Profile + Extended) on a customer machine which is running Windows Small Business Server 2003 Standard Edition. The installation was successful without any errors. There were no errors mentioned in the log files either...
BUT the .NET Framework 4 GAC (Global Assembly Cache) is completely missing! In other words, the following folder is missing:-
C:\Windows\Microsoft.NET\assembly
If I look into the C:\Windows\Microsoft.NET folder, I can only see 2 subfolders (as shown below) and nothing else.
authman
Framework
The server still has .NET Framework 3.5 installed and is running properly. This means that the GAC folder below exists and has all .NET library DLLs in it. But of course, there are no .NET 4 DLLs in there.
C:\Windows\assembly
Because of the missing .NET Framework 4 GAC, none of my applications run. They all complain about missing System or System.Xml references. If I copy the missing files from the C:\Windows\Microsoft.NET\Framework\v4.0.30319 folder to my application directory, they will stop complaining about these files and start complaining about other missing .NET files. Obviously I use a lot of .NET Library references, and I don't want to copy the whole .NET Framework folder into each of my applications.
Does anyone know how to create the missing GAC? Or at least find out what causes the GAC to disappear? I tried multiple times to re-install the .NET Framework 4, but the GAC is always missing...
Edit: I've also tried running gacutil.exe -l to see what is in the GAC, it only list out .NET assemblies of version 1.0 to 3.5. All .NET 4 assemblies are missing.
Note: .NET 4 version of gacutil.exe only comes with Visual Studio (or Windows SDK), so I have to copy the file to the customer site.
Related
I created a new project. I have 2 problems already.
The newest .net framework available is .net framework 4.8 right?
I cannot select that
I want my .exe file to show up on this folder
Instead, the .exe file show up in this
Note: I censored the username actually, but you got the point. It shows up at \net5.0-windows instead
I want that to show up on arbitrage2 folder straight. Not on arbitrange2\net5.0-windows
My other projects do not have this problem.
Where should I change this?
Also I suspect the problems are related. That's because my other project can have target framework 4.8. In fact, in other projects, .net 5.0 and .net 6.0 is not available
We're having the seemingly common error
Could not load type 'System.Runtime.CompilerServices.ExtensionAttribute' from assembly 'mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
in a project that needs to be compiled against .Net 4.0 but is built on a build server running Windows Server 2012 (with .Net 4.5). The project is a web application that gets deployed to a web server running 2003, where installing .Net 4.5 isn't an option. There it runs against "classic" .Net 4.0
From similar questions, we're trying command-line options to MSBuild:
/property:FrameworkPathOverride="C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0"
We also tried various combinations of
/property:ReferencePath="C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0"
/property:NoStdLib=true
/property:NoCompilerStandardLib=true
The reference assemblies (including the .dll files) are in fact installed in that place on the build server. But when we deploy the website and visit the home page, we get that error. (Interestingly, on a page reload, the error disappears, and the site operates normally.) What are the MSBuild parameters necessary to compile against the .Net 4.0 assemblies?
Update
I turned on ludicrous-level logging on MSBuild, and I see that apparently it is building against the .Net 4.0 reference assemblies:
Resolved file path is "C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0\mscorlib.dll
and I didn't see any mention of assemblies outside that folder or the build server's working directory. So it appears to compile properly, but when deployed on the web server, it throws the exception.
As to the exception going away on a page reload, I wonder if that's related to the markup pre-compile step. We're running aspnet_compile on the build server. Maybe if there's an exception coming from a generated assembly, the web server will re-compile it. And the recompiled assembly is fine, because it was created with true .Net 4.0.
Well the answer turned out to be borderline embarrassing. After we confirmed from detailed MSBuild output that it was in fact building the website project against the right reference assemblies, we realized that there are several in-house NuGet packages in the project that had been built against .Net 4.5. One of them was chock full of extension methods, which is what causes the exception. Rebuilding them against .Net 4.0 fixed the problem.
Which brings up an interesting issue. If a 3rd-party NuGet package is compiled for 4.0 but using 4.5 references, we'd be in the same situation, but not able to fix it. So the lesson for package publishers is to ensure your 4.0 version is compiled against the reference assemblies.
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'm trying to add a .NET 4.0 .dll to the GAC. I am attempting to do this because it is published by a 3rd party company as both a 32 and 64bit .dll which I must use from different apps on different platforms in both formats.
At any rate, I am having trouble registering this dll to the GAC on a Windows Server 2008 environment.
I have tried copying gacutil.exe (and supporting file) found at "C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\bin\NETFX 4.0 Tools" on my local machine to the "C:\Windows\Microsoft.NET\Framework\v4.0.30319" folder on the target production server per the suggestions found here.
I then tried copying them to "C:\Windows\Microsoft.NET\Framework64\v4.0.30319".
Running from both locations indicated successful installation. And indeed, the registration appears successful:
C:\Windows\Microsoft.NET\assembly\GAC_64\ChilkatDotNet4\v4.0_9.0.8.0__eb5fc1fc52ef09bd\ChilkatDotNet4.dll
C:\Windows\Microsoft.NET\assembly\GAC_32\ChilkatDotNet4\v4.0_9.0.8.0__eb5fc1fc52ef09bd\ChilkatDotNet4.dll
However, running a console app that refers to the (64bit) version of the dll errors out with the following message:
System.IO.FileNotFoundException: Could
not load file or assembly
'ChilkatDotNet4.dll' or one of its
dependencies. The specified module
could not be found. File name:
'ChilkatDotNet4.dll'
So, I have now manually created the following GAC entries using mkdir and copy from a command prompt (which may or may not actually work. I have no clue what is so special about gacutil.exe):
C:\Windows\Microsoft.NET\assembly\GAC_MSIL\ChilkatDotNet4\v4.0_9.0.8.0__eb5fc1fc52ef09bd\ChilkatDotNet4.dll (using the 64bit version of the dll)
C:\Windows\assembly\GAC_64\ChilkatDotNet4\v4.0_9.0.8.0__eb5fc1fc52ef09bd\ChilkatDotNet4.dll
C:\Windows\assembly\GAC_32\ChilkatDotNet4\v4.0_9.0.8.0__eb5fc1fc52ef09bd\ChilkatDotNet4.dll
After each "install" of the dll, I tested and received the same error. Any ideas welcome!
EDIT: the GAC issue above may not actually be the culprit. Turns out, even when I create a brand new Console App project and add the .dll directly (so that it lives in the bin), I still can't run it on the sever. Also, I've noted that Console apps are created targeting the .NET 4.0 Client Profile rather than the .NET Framework 4. When I try to run it targeting the client profile, it appears that none of the System.Web* libraries are available. However, I tried running a very simple test app targeting both and neither would run on the server while referencing the bad .dll.
Is there a special kind of install that was to occur to run .NET 4.0 Console Apps?
For anyone else who may have trouble with this in the future. It was not a generalized problem with the way I was registering the dll to the GAC or how I was referring to it from my projects.
ChilkatDotNet4.dll (and the other versions I'm sure) was built in Visual C++. So, the server it is being deployed to has to have the Visual C++ Runtime installed for the appropriate processor architecture.
For 2010 (.NET 4.0):
x86
x64
If you're running an x86 app on a 64-bit platform. Make sure to mark the application pool with "Enable 32-bit applications" = true.