We Keep Coding

Does Windows cache the .NET version used by an assembly?

I made the mistake of trying to deploy a program built with .NET 4.7.1 on a machine that didn't have that version of the .NET framework installed. It popped the following error message:
Since installing a new .NET framework requires a reboot, I don't want to go that route yet. So I tried downgrading the target framework to 4.6.1... but I still get the same error!
I verified that the assembly was compiled targeting the 4.6.1 framework:
As a test, I renamed the assembly VueLinks2.exe and it started just fine.
The only thing I can think of is that Windows "remembers" what framework is associated with an assembly. Is that correct? Is it possible to undo that and downgrade an app to a previous version without renaming the file?

There's no cache. Deciding what framework to use is a combination of the <requiredRuntime> (legacy) and <supportedRuntime> elements in the [exe].app.config and the assembly's framework version if those are not supplied. Renaming the executable will cause the [exe].app.config to no longer be matched.

'Could not load file or assembly 'netstandard, Version=2.0.0.0, ...'. Reference assemblies should not be loaded for execution

Goal:
From a .NET 4.7 console app, using reflection with Assembly.GetType(), I am trying extract the Type of a netstandard 2.0 class from Assembly X. Then I want to create an instance of this Type with Activator.CreateInstance().
What I am trying to do:
However, this assembly X has a dependency to netstandard 2.0. To be able to get the Type, netstandard dependency has to be loaded into the AppDomain. That's why when the AppDomain is requesting the netstandard assembly through the AssemblyResolve event, I simply load the dll like this :
var netStandardDllPath = #"C:\Users\xxx\.nuget\packages\NETStandard.Library.2.0.0-preview1-25301-01\build\netstandard2.0\ref\netstandard.dll";
return Assembly.LoadFrom(netStandardDllPath);
Which throws:
System.BadImageFormatException: 'Could not load file or assembly
'file:///C:\Users\vincent.lerouvillois.nuget\packages\NETStandard.Library.2.0.0-preview1-25301-01\build\netstandard2.0\ref\netstandard.dll'
or one of its dependencies. Reference assemblies should not be loaded
for execution. They can only be loaded in the Reflection-only loader
context. (Exception from HRESULT: 0x80131058)'
Inner Exception: BadImageFormatException: Cannot load a reference
assembly for execution.
What I know:
I know that they want us to load the DLL with Assembly.ReflectionOnlyLoadFrom. But doing that will prevent me from instanciate the type with Activator.CreateInstance(). See Microsoft official post
Also, I tried referencing the Nuget packages NETStandard.Library 2.0.0-preview1-25301-01 and NETStandard.Library.NETFramework 2.0.0-preview1-25305-02 in my console app so it would have the netstandard 2.0 libraries referenced, but it didn't change anything.
Question:
Does anyone would know if there is a proper way to load that dll without error, or maybe if this is a bug, or else? Or why this kind of dll is not able to load for execution?

The netstandard.dll you are trying to load is a reference assembly that which cannot be loaded for runtime on .NET Framework as pointed out by others. However if you need to resolve that dependency you will need to runtime version that maps to the framework you are trying to run on.
For .NET Standard support we are including them as part of the msbuild extensions that ship with VS so you will want to get the version of netstandard.dll from there. Depending on which version of VS2017 you have installed it should be somewhere like C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net461\lib\netstandard.dll or from the .NET Core 2.0 SDK you can find it C:\Program Files\dotnet\sdk\2.0.0\Microsoft\Microsoft.NET.Build.Extensions\net461\lib\netstandard.dll
Try using one of those versions in your scenario.

Wow. I just spent several hours tracking the cause of this "could not load ... netstandard" error down.
For me, the problem was that my .NET Framework project (which references both .NET Framework and .NET Standard libraries) was built with .NET Framework 4.7.2 and the system where I was deploying and running it did not have 4.7.2 installed.
Deploying a very small Console project with the same basic structure and references and executing that in a Command window finally revealed the correct error, in a pop-up, that .NET Framework 4.7.2 was missing.
If you're struggling with this particular error, make sure you have the necessary .NET Framework installed.

Set Copy Local to true in netstandard.dll properties.
Open Solution Explorer and right click on netstandard.dll.
Set Copy Local to true.

You can't load a reference assembly.
.NET Standard is a collection of APIs that must be provided by .NET Standard compatible implementations.
A reference assembly only contains contracts. This means that it contains no implementation. The assembly you are trying to load contains the .NET Standard 2.0 contracts.
A contract looks like this: https://github.com/dotnet/standard/blob/master/netstandard/ref/mscorlib.cs
EDIT: .NET Framework 4.7 implements .NET Standard 2.0, so you shouldn't need to load any assembly to use Activator.CreateInstance() to instantiate a .NET Standard type.

NETStandard 2.0.0-preview1 in not compatibility with net461 and net47.
but for realese .NET Core SDK 2.0 assemblies (as well as 2.0.0-preview2)
var netStandardDllPath = #"c:\Program Files\dotnet\sdk\NuGetFallbackFolder\microsoft.netcore.app\2.0.0\ref\netcoreapp2.0\netstandard.dll";
Console.WriteLine(Assembly.LoadFrom(netStandardDllPath).FullName);
all is ok.
But if you steel need to load preview1 libraries, maybe you should to use netstandard2.0 instead net471.

For me solved doing the following:
1 - Installed latest .Net Framework on server.
2 - Updated windows server and my local machine.
3 - Went to Manage Nuget Package and updated all references on the update tab.
Perhaps only doing step 3 can solve in your case

In case if IBM Message Queue references are used in the project solution, this exception indicates that the DLL used for refering MQ classes are incompatible with the host(server) .NET version installed.
In this scenario, either we need to update server with latest update and make sure .NET latest version is available or use lower version of IBM Message queue DLL as reference.
Old version DLL - amqmdnet.dll (no new features will be introduced by IBM as not in support)
Latest version DLL - amqmdnetstd.dll (to run IBM MQ classes for .NET Standard, you must install Microsoft .NET Core)

Install NetStandard.Library 2.0.0.0 from NuGet , It works for me. when I downgrade .net framework 4.6.1 to 4.6.0

If you are having this issue for a project that used to work, try deleting the bin and obj folders since caching can cause this, too.

How do you add the 4.0 reference assemblies to your build server (so the compiler finds them)?

The issue comes up when you install Visual studio 2012 on a machine without Visual studio 2010 installed previously (I think). I want to target .net 4.0, while building on Visual Studio 2012. I already have set up the machine without VisualStudo 2010. I end up with messages like:
*Warning 2 The primary reference "blablaLibraryproject" could not be resolved because it was built against the ".NETFramework,Version=v4.5" framework. This is a higher version than the currently targeted framework ".NETFramework,Version=v4.0". blablaExecutableproject*
The answering post here(Can a build server with .NET 4.5 installed successfully deploy a project targeting 4.0 to a server with only .NET 4.0 installed?) says:
You can correct this, but you need to add the 4.0 reference assemblies to your build server (so the compiler finds them), and not
just rely on the .NET 4.5 versions.
So how does one "add the 4.0 reference assemblies to your build server (so the compiler finds them)"?

They are already present on the machine. Just change the Target Framework setting of the project from 4.5 to 4.0
The problem discussed in that linked question is a pretty common one for programmers that try to setup a build server without paying for the VS license. Which goes pretty far, but is missing an otherwise freely available component, the multi-targeting packs for the .NET Framework versions.
Which is penny-wise but pound-foolish. They then make a fatal mistake, they add reference assemblies from c:\windows\microsoft.net instead. Like it was done in framework versions prior to .NET 4.0. This causes horrible to diagnose runtime exceptions when the built product is ran on a machine that only has 4.0 installed. The asker of the question was pretty lucky, he got a relatively easy to diagnose one. That however can be a lot worse, getting pretty bizarre TypeLoadExceptions for common framework types.
You don't have this problem, you installed VS so you already got the multi-targeting packs. The 4.0 version is available in C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.0. Both MSBuild and VS know how to find it there without your help. Just change the project setting to tell them that you want to target 4.0

In addition to Hans' answer, here is another possible reason for this:
My build server had Visual Studio installed, however, my project targeted .NET 4.0.3 and that specific target framework was missing on my build server. Therefore it silently defaulted to .NET 4.5.
I fixed this by changing the target framework of my project to .NET 4.

easiest way to convert .NET project from 4.5 to 4.0?

I have a .NET application that I built in 4.5, which has references to a bunch of libraries that were built in 4.5, which themselves have references to 4.5, etc. A user group that I'm trying to distribute the application to is having problems running the executable because they have 4.0 installed; in particular, they're getting a MissingMethodException:
Method not found: 'System.Type System.Runtime.InteropServices.Marshal.GetTypeFromCLSID(System.Guid)'.
Because we may have trouble getting each user upgraded to 4.5 (as none of them have admin permissions on their machines and this would require a separate upgrade request for each user), I'm looking at finding an easy way to rebuild the project as 4.0. This seems to require that I rebuild every library and its referenced libraries in 4.0; is there an easier way to do this than going through each library one by one and building a 4.0 version? I'm thinking maybe like a one-click option for "Rebuild all referenced libraries in target framework" or something like that.

If you have dependencies on .Net 4.5 DLLs then you will need to also get .Net 4.0 versions of those if you want to successfully downgrade your project. A .Net project can only reference .Net DLLs up to the same version of .Net as the referencing assembly.
The easiest way to do this is to use something like NuGet to manage your dependencies. Note that when you change the target framework version of your project in VS you will need to uninstall and re-install dependencies with NuGet as NuGet does not automatically do this for you when you change the target framework version.
Of course if all the dependencies are to your own code and you aren't publishing this through a dependency management system like NuGet you will need to downgrade all your other code to .Net 4.0 as well

When I use Visual Studio, I right click on the project, change the framework, fix the References and recompile. Usually straight forward.

Please, have a look at this MSDN page to correctly switch your project to a lower target framework without problems! It is a little bit outdated for what concerns versions, but the process is the same described!

This is based on my experience. I had an application initially created in .net framework 4.5 but I wanted to convert it in .net framework 4.0. I created new project initially created 4.0 and then I did copy and paste of all the forms and controls of my previous application and it works. Framework 4.5 is using Aero2 and 4.0 is Aero... Good Luck :)

Framework Upgrade to 3.5

I have a project which references another project's dll. They both were in .net framework 2.0.
So upgraded both to 3.5, but when I go to reference for second project(the one referencing the first project) it still says on properties runtime version 2.0, even though I deleted the reference and readded.
How would I determine if the referenced dll is the upgraded one, before deploying to server where it has version 2.0?
I don't want to delete all files in server and deploy, after upgrading do I need to check the config files are referencing same dlls and deploy published files or it needs replacing all together?

.Net 3.5 and .Net 2 both run on version 2 of the CLR, so the runtime version of the 'old' and 'upgraded' assemblies will not change.
As for finding out whether it is 'upgraded', I would recommend using ILDASM to see which version of mscorlib is referenced.
However, the answers to this SO question provide a few alternatives.

You can easily check which version the assembly is build against by opening it up in Reflector (or another decompiler).

The CLR for .NET 3.0 and .NET 3.5 is the same CLR from .NET 2.0.
Hence the best way to check, if your assemblies are upgraded or not, is to use Assembly version. Do maintain assembly version and build version in AssemblyInfo.cs while building the assembly.
Having a strong named assembly is the best way to check.