I'm converting a (working) .netstandard library project into a multi-targetted project that will target:
<targetframeworks>netstandard2.1;xamarinios10;monoandroid10.0;monoandroid12.0;</targetframeworks>
I'm having issues with the System.ComponentModel.DataAnnotations reference. Sepcifically I get this error (for eveything except the .netstandard target):
The type 'DataType' is defined in an assembly that is not referenced. You must add a reference to assembly 'System.ComponentModel.DataAnnotations, Version=2.0.5.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'.
After a bit of searching I tried adding the System.ComponentModel.Annotations (4.7.0) nuget package. This gave the same error.
In the nuget directory for this I noticed that where the .dll would normally live it had a file '.' - I didn't know if that was important (.nuget\packages\system.componentmodel.annotations\4.7.0\ref\MonoAndroid10) - the .netstandard dll was there as expected.
I've also noticed that (a separate) Xamarin.Android project seems to use the System.ComponentModel.DataAnnotations.dll which lives in C:\Program Files\Microsoft Visual Studio\2022\Enterprise\Common7\IDE\ReferenceAssemblies\Microsoft\Framework\Xamarin.iOS\v1.0
I'm not sure if the right version of Mono.Android (or ios equivalant) is being targetted or I have to specify a specific assembly version, or whether I'm down the wrong track completely?
Thanks in advance,
Paul.
As the comment above mentions, to workaround this issue, I moved the bit of offending code (that used the System.ComponentModel.DataAnnotations) into a seperate project that targetted .netstandard2.1 and then referenced this project from my multi-targetted project.
tl;dr: My .NET Core 3.1 console application crashes with a FileNotFoundException because a (referenced?) assembly is present in version A, but required in version B. What to do?
I am trying to get a console application to run that is now built for .NET Core 3.1, but that used to be a .NET Framework 4.8 project before it was converted.
The console application crashes with a System.IO.FileNotFoundException, saying that the assembly Microsoft.Extensions.FileProviders.Physical in version 3.1.0.0 cannot befound. Now, I can confirm it's not there - in the directory where the .exe file of my console application resides, there is a file named Microsoft.Extensions.FileProviders.Physical.dll, but its assembly version is 3.1.6.0.
The console application and its dependencies are a part of a bigger project in said folder, with a total of over 1,200 DLLs.
In .NET Framework, I'd have used a binding redirect to use the present version 3.1.6.0 of the indicated assembly. In .NET Core, though, I understand these binding redirects are not a thing anymore. Thus, I'm not sure how to proceed, or how to even find out why the runtime thinks it needs to load Microsoft.Extensions.FileProviders.Physical.dll.
I may have found a partial solution that loads the version-mismatched assembly nonetheless (see observation (6) below), but then, I'm still getting a FileNotFoundException, this time for Microsoft.AspNetCore.Mvc.Abstractions.
Some observations and attempts to solve this:
(1) None of the > 1,200 .csproj files contains the string "Physical".
(2) More than 400 of the .deps.json files mention "Microsoft.Extensions.FileProviders.Physical.dll", all of them referring to version 3.1.0.0.
(3) All of the respective DLLs are loaded in an ASP.NET Core application where the version mismatch appears to cause no issues.
(4) The .deps.json file of my console application itself does not mention "Microsoft.Extensions.FileProviders.Physical.dll".
(5) Putting the right version of the file (3.1.0.0) into the directory where the .exe file resides and from where the .exe file is also executed does not change anything. The FileNotFoundException still occurs, still complaining about an absence of "Microsoft.Extensions.FileProviders.Physical.dll", version 3.1.0.0.
(6) Based upon the information on assembly resolution in .NET Core provided in a CodeProject article, I have attempted to force loading of the assemblies from the same directory myself (preliminary code, relying on the working directory):
AssemblyLoadContext.Default.Resolving += (context, name) =>
{
var dllPath = System.IO.Path.Combine(Environment.CurrentDirectory, name.Name + ".dll");
if (File.Exists(dllPath))
{
return AssemblyLoadContext.Default.LoadFromAssemblyPath(dllPath);
}
return null;
};
This appears to help to some extent! Now, the "Microsoft.Extensions.FileProviders.Physical.dll" assembly, and plenty (more than 250) of others, can be loaded. But this fails once "Microsoft.AspNetCore.Mvc.Abstractions", 3.1.0.0, needs to be loaded, which is not actually anywhere around the .exe file. Apparently, it must be loaded from somewhere else (?)
(7) While the above appears to provide a partial solution concerning the version mismatch, our entire source code contains no other occurrence of "AssemblyLoadContext". Therefore, the ASP.NET Core application apparently avoids the version mismatch issue using some other mechanism.
(8) Building my console application with build output set to Diagnostic1 confirms the suspected behaviour for the "Microsoft.Extensions.FileProviders.Physical.dll" file (shortened excerpt of the output):
Dependency "Microsoft.Extensions.FileProviders.Physical, Version=3.1.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60".
Could not resolve this reference. Could not locate the assembly "Microsoft.Extensions.FileProviders.Physical, Version=3.1.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors.
For SearchPath "C:\(...)".
Considered "C:\(...)\Microsoft.Extensions.FileProviders.Physical.winmd", but it didn't exist.
Considered "C:\(...)\Microsoft.Extensions.FileProviders.Physical.dll",
but its name "Microsoft.Extensions.FileProviders.Physical, Version=3.1.6.0, Culture=neutral, PublicKeyToken=adb9793829ddae60"
didn't match the expected name "Microsoft.Extensions.FileProviders.Physical, Version=3.1.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60".
Considered "C:\(...)\Microsoft.Extensions.FileProviders.Physical.exe", but it didn't exist.
Required by "(A)".
Required by "(B)".
Required by "(C)".
In there, (A), (B), and (C) are assemblies of our own project. But as far as I can see, neither of their .csproj files mentions the text "Physical", so I do not understand why the DLL is allegedly being required by them.
(9) For the "Microsoft.AspNetCore.Mvc.Abstractions" assembly, diagnostic output says:
Dependency "Microsoft.AspNetCore.Mvc.Abstractions, Version=3.1.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60".
Could not resolve this reference. Could not locate the assembly "Microsoft.AspNetCore.Mvc.Abstractions, Version=3.1.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors.
For SearchPath "C:\(...)".
Considered "C:\(...)\Microsoft.AspNetCore.Mvc.Abstractions.winmd", but it didn't exist.
Considered "C:\(...)\Microsoft.AspNetCore.Mvc.Abstractions.dll", but it didn't exist.
Considered "C:\(...)\Microsoft.AspNetCore.Mvc.Abstractions.exe", but it didn't exist.
Considered "C:\(...)\Microsoft.AspNetCore.Mvc.Abstractions.winmd", but it didn't exist.
Considered "C:\(...)\Microsoft.AspNetCore.Mvc.Abstractions.dll", but it didn't exist.
Considered "C:\(...)\Microsoft.AspNetCore.Mvc.Abstractions.exe", but it didn't exist.
Required by "(B)".
Once again, (B) is an assembly (same as the (B) in (8)) of our own, but looking into the .csproj file does not reveal a single occurrence of "Mvc.Abstractions".
I have found a couple of questions that appeared to provide solutions, but none of them worked for me:
Assembly binding redirect in .NET Core - just points to another question (listed below).
Adding a bindingRedirect to a .Net Standard library - the answer points out that binding redirects do not exist in .NET Core, but that the .deps.json file can be used to resolve assemblies. It then goes on to describe .NET Framework binding redirects, without mentioning anything else on what to do with .deps.json in .NET Core.
Common practice to load the dependency(different version of dll) in program - the question is about .NET Core, but the answer applies to .NET Framework. For .NET Core, it links to one of the other questions listed here.
How can I add an assembly binding redirect to a .net core unit test project? - the answers to this question seem to suggest using binding redirects in app.config files, even though these are apparently not supported anymore in .NET Core according to another comment on that question. In any case, the suggested solution of adding
<PropertyGroup>
<AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects>
<GenerateBindingRedirectsOutputType>true</GenerateBindingRedirectsOutputType>
</PropertyGroup>
to the .csproj file (uh, which one? I tried the one of my console application; is that the right one?) has no effect to my .deps.json files or the exception I keep getting, as far as I can tell.
Error System.IO.FileLoadException: 'Could not load file or assembly 'log4net, Version=2.0.8.0 in .NET Core - in this case, the correct DLL was available in the right version, it was just not copied to the appropriate output folder.
.NET Core 3.1 - Could not load file or assembly System.Runtime, Version=4.2.2.0 - the solution in this case seemed to be to use another library/library version that would fit with the assembly reference. I do not think that is a viable way for me, as replacing the Microsoft.Extensions.FileProviders.Physical assembly might just cause any kinds of conflicts or issues in any of the > 400 of our assemblies that apparently somehow use the file, according to the .deps.json mentions.
Why is my .NET framework app looking for the wrong version of the .NET core/standard platform extension assembly, and how do I fix it? - it seems this question's OP just accidentally stepped into the .NET Core topic, while they were actually working in a .NET Framework context.
FileNotFoundException when referencing DLL in .NET Core Application - this issue was centered around deficiencies in earlier .NET Core versions, which do not apply to .NET Core 3.1 anymore.
FileNotFoundException with indirectly (.net to .net standard to NuGet) referenced DLL - this appears to have been another case of the correct DLL file being available, just not in the right location.
Can I control .NET Core assembly redirects programmatically? - once again, comments in this question point out that binding redirects are not a solution in .NET Core. Moreover, the answer appears to apply to compile time. As none of our .csproj files mentions the files with which I am observing a version mismatch, I suspect it is referenced from within one of the 3rd party libraries we are using and thus compile-time solutions may not be applicable.
How can I make the runtime load version of 3.1.6.0 of the indicated assembly rather than the requested version 3.1.0.0? Alternatively, how do I find out how the runtime does it when running the ASP.NET Core application?
1: in VS2019: Tools -> Options -> Projects and Solutions -> Build And Run -> MSBuild project build output verbosity -> Diagnostic
I'm newbie to .net projects. Although I was able to code in c# & use it's frameworks, Some times I face exceptions which I really didn't get any proper resource/suggestion to modify or rectify them. Hope I would get clear this time.
The exception which I faced is as follows :
Could not load file or assembly 'Microsoft.AspNetCore.Cryptography.KeyDerivation, Version=2.2.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60' or one of its dependencies. The system cannot find the file specified.
I'm really confused with such type of exceptions. What's the reason for those & how we needs to cross check to clear those ?
Here is what I did install: "Microsoft.AspNetCore.Cryptography.KeyDerivation" from nuget console with version 2.2.0.
My installed packages list image :
The main reason for this type of error is a result of your output folder. Take a look at where your binary outputs were placed. Inside of that folder (usually your .exe or .dll output, not sure what kind of .NET project you're writing), you should also have all of your dependency dlls. In this case, the dll related to Microsoft.AspNetCore.Cryptography.KeyDerivation is missing. So when you go to run your executable, it complains "Could not load file or assembly KeyDerivation" because it couldn't find it.
To resolve this issue, double check your project's references and that there are no issues with the Microsoft.AspNetcore.Cryptography.KeyDerivation reference (what I mean is, make sure there are no yellow exclamations or other icons showing up next to this reference in your Solution Explorer). If you have any issues, remove the reference, then add the nuget package again.
I would like to sign all projects in my C# solution. But when I try to do so, there is the problem, that several third party assemblies don't have a strong name. These assemblies are:
Microsoft.Practices.Composite.dll
Microsoft.Practices.Composite.Presentation.dll
After doing some research I found a way to give third party DLLs a strong name (source):
1) ildasm /all /out=ThirdParty.il ThirdParty.dll
2) ilasm /dll /key=YourKey.snk ThirdParty.il
These operations both complete successful. But when I remove the NuGet packages with the unsigned assemblies from my projects and add the signed ones as references, I get the following compiler error:
The type 'Microsoft.Practices.Composite.Events.EventBase' is defined in an assembly that is not referenced. You must add a reference to assembly 'Microsoft.Practices.Composite, Version=2.0.1.0, Culture=neutral, PublicKeyToken=null'
But of course I already added Microsoft.Practices.Composite.Presentation.dll
To confine the problem, I tried to add the reference to a new project. But since I got the same error there, I can exclude some weird configuration in my main solution.
You can download my test-project here: https://www.dropbox.com/s/g7sqb4vtbnasfjz/ConsoleApplication1.zip?dl=0
I really hope that you can help me in any way.
Today I found out that the Composite Library is part of Prism since version 4. So instead of adding references to the dlls signed by me, I added the NuGet Package for Prism, which is already signed.
System.DllNotFoundException was unhandled Message=Unable to load DLL 'sqlite3': The specified module could not be found.
I already reference the DLL. I check it on Debug folder and it was there. I also search how to "include" it in the project but they don't specifically explain how to do it.
I'm following this example: http://www.codeproject.com/Articles/22165/Using-SQLite-in-your-C-Application
SQLite doesn't have a full .NET implementation, but available libraries are wrappers of a native one.
This means that not only .NET assembly must be referenced but you need to be sure native library is there too when applicacion is executed.
Summary: output folder will have a .NET assembly and a native assembly (C/C++ one) in order to work properly!
The System.Data.SQLite.dll is platform dependent assembly, and you mast add reference to appropriated assembly.
Follow the steps :
1)Add the Dll in debug folder
2)in your code add this
using System.Data.SQLite;
3) Add the reference by going to solution explorer and add it.
4) Check the version in app.config to verify it