Framework Upgrade to 3.5 - c#

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.

Related

Azure Function can't find a file/dll that it suppose to use

I have an azure webjob that used to work well. When I added an internal nuget of the company I work for and used it, I received the following error:
Could not load file or assembly 'System.Threading.Tasks.Dataflow, Version=5.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. The system cannot find the file specified.
The weird thing is that both the interal nuget, and a nuget that was defualtly existed in that project before, are using the System.Threading.Tasks.Dataflow, Version=5.0.0.0
When .NET was first created, the Windows-only .NET Framework, it has a concept called "strong naming" which makes the assembly version part of the assembly identity (not just the name, but also includes public key). With the .NET Framework when A.dll has a reference to B.dll, at runtime the version of B.dll must match the version A.dll was compiled against. The way to work around that was to use a binding redirect in an app.config or web.config file.
With .NET Core, they stopped enforcing this, but they still put in a check to make sure that the assembly found on disk is a HIGHER version than what the compile time reference was.
This is relevant because you're using Microsoft.NET.Sdk.Functions version 3.0.13, which targets .NET 3.1. Therefore, I assume you're Azure Functions app is running on .NET Core 3.1. I don't know what the assembly version of System.Threading.Tasks.Dataflow that ships in the .NET 3.1 runtime is, but I'd expect it to be version 3.something.
While NuGet package versions do not have to match assembly versions, it is very often the case that the major (and sometimes minor) versions do match, especially for System.* packages/assemblies.
Putting 2+2 together, you're running on .NET Core 3.1, which has System.Threading.Tasks.Dataflow.dll version 3.something, but your something.Kafka.dll assembly is compiled against System.Threading.Tasks.Dataflow.dll version 5.something. Since the compile time reference is a higher version of the version available at runtime, the .NET assembly loader refuses to use it.
There are two actionable things now.
Firstly, you can do one of three things to fix your project. Use a newer version of Azure Functions that targets .NET 5 or higher. Alternatively, use an older version of your whatever.Kafka package that doesn't depend on BCL (base class library) assemblies that are higher version than the .NET Core 3.1 runtime provides. Finally, I'm guessing the reason the dll doesn't exist in your project's bin directory is because of this issue: https://github.com/Azure/azure-functions-host/issues/5894
Secondly, contact the package owners of this Kafka package, and inform them that they don't need to use the Dataflow NuGet package. .NET Core 1.0 had it built into the BCL, so the package is only needed for .NET Standard and .NET Framework projects. If this Kafka package does support .NET Framework or .NET Standard, then if they change their PackageReference to include Condition=" '$(TargetFrameworkIdentifier) != '.NETCoreApp' ", then the package will be used only in .NET Framework and .NET Standard, and the BCL version of the package will be used for .NET Core and .NET 5 and above. If they use any other System.* package (that ships in the runtime), they should do the same. Of course, if the package owner refuses to remove Dataflow as a package dependency, or if there are other packages that bring in Dataflow as a transitive package, then you're stuck. But by informing the Kafka package owners of this, they at least have the opportunity to improve their package.

Extra files in the project (NPGSQL)

The question is stupid enough, but it didn’t work with NuGet before. After installing the NuGet package through the console, to connect to PostgreSQL, files appeared that NetFramework should contain. Without copying these files, the project does not start. What to do to get rid of them and not copy them to the directory with the program. In my understanding, these files should be taken from the framework.
See screenshots:
All need files in project C#
My guess is that you have .Net Standard 2.0 libraries/dependencies in your project.
.NET 4.6.1 might add additional runtime dependencies in your output folder:
.NET 4.6.1, 4.6.2, .NET 4.7 and 4.7.1 all have partial .NET Standard
2.0 support in the natively shipped runtimes, but they still are .NET Standard 2.0 compliant by adding additional runtime dependencies into
your output folder to provide the missing functionality. NuGet along
with the runtime targeting handles automatically adding those
dependencies to your projects to provide the needed runtime support
for those extra features. A lot of those assemblies override behavior
from the base framework and .NET uses runtime redirects to route api
calls to the appropriate assemblies rather than than mscorlib.dll or
other system assemblies.
.NET 4.7.2 is the first version of the full .NET Framework that is
fully .NET Standard 2.0 compliant without any additional dependencies.
See: https://weblog.west-wind.com/posts/2019/Feb/19/Using-NET-Standard-with-Full-Framework-NET
In other words, targeting .NET 4.7.2 should get rid of the additional files.

'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.

Can a .NET assembly in framework 4.5 refer to old GAC?

I know that there are two GACs will be available on a system where latest .NET framework is installed.
i.e. "C:\Windows\assembly" for framework lower than 3.5, and "C:\Windows\Microsoft.NET\assembly\GAC_MSIL" for 4.0 and above.
Now, I have two questions:
First question is, I've a C#.NET assembly developed in frawework 4.5 and i have to add a reference to Microsoft.Office.Interop.InfoPath.Xml.dll.
I'm not finding this reference in the latest GAC, but it is there in the old one. So can I add from the old GAC?
Second question : If I install a latest version of Office, this reference also get migrated to another version. So unless I re-refer this dll in my project, my assembly cannot load the mentioned dll as it is checking for exact version number. Is there a generic solution for this, so that I need not change the reference and rebuild my application?
Remove the references to the GAC and use the assemblies from the file system. Set CopyLocal = TRUE;
You may need more than the one Assembly, an article here - InfoPath Interop describes the assemblies required.
The InfoPath primary interop assemblies can be downloaded here: http://msdn.microsoft.com/en-us/library/15s06t57.aspx

Problems with targeting my VS2010 to .NET4 Framework

I keep getting the following messages about frameworks in VS2010. Also I can no longer add .net 4 as a target framework. I have tried installing / repairing the .net 4 framework. It keeps telling me all is okay but then I still get the message and cannot target the .net 4 or add it from the drop down list in the project properties. I'm at a loss for what to do. Any advice would be much appreciated.
Warning 8 The reference assemblies for framework ".NETFramework,Version=v4.0" were not found. To resolve this, install the SDK or Targeting Pack for this framework version or retarget your application to a version of the framework for which you have the SDK or Targeting Pack installed. Note that assemblies will be resolved from the Global Assembly Cache (GAC) and will be used in place of reference assemblies. Therefore your assembly may not be correctly targeted for the framework you intend.
Have you tried downloading and installing this?:
http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=8279
It has worked for other people.
As far as I am aware this is different than the .NET framework, which is just for running the apps.
C:\Program Files[ (x86)]\Reference Assemblies\Microsoft\Framework.NETFramework\v4.0
This is the folder VS looks for reference assemblies. Does it contain the correct things on your machine? If not, you need to repair VS.
This folder is not part of .NET 4 installation, so that's why repair .NET 4 does not help you much.

Categories