In my solution I have a third-party A.dll with another B.dll(Specific version = true) dependency. But I have older version of B.dll and it goes with error:
Could not load file or assembly 'B, Version=2.0.0.1, ...'
but i have B.dll with little older version (2.0.0.0)
so how can i solve my problem? How to loose version depenceny? Force to look for older in not exists?
AND what is important A and B are third-party. So i can't change it.
Just define a version redirection in your app.config.
See here.
Or you can set the 'Specific version' option to false.
Of course, both options only work as long as there is no breaking change...
Related
I am seeing a System.Reflection.ReflectionTypeLoadException at runTime:
Could not load type 'System.IdentityModel.Tokens.ISecurityTokenValidator'
from assembly 'System.IdentityModel.Tokens.Jwt, Version=5.0.0.127, Culture=neutral, PublicKeyToken=31bf3856ad364e35'.":"System.IdentityModel.Tokens.ISecurityTokenValidator
I am using System.IdentityModel.Tokens.Jwt version 5.0.0.127 (nuget package 5.0.0)
I have tried using fuslog to look at the binding log. It finds the dll in my bin directory and the bind succeeds (and it is the correct dll). I've also verified that I don't have this library installed in the GAC.
I used visual studio's object browser and went looking through the dll. I found that JwtSecurityTokenHandler inherits from ISecurityTokenValidator. According to the object browser ISecurityTokenValidtor comes from Microsoft.IdentityModel.Tokens. (I am using nuget package 5.0.0 of that one also).
I manually went through the various nuget dependencies related to these two packages (as well as any others in my project that I thought had a chance of being relevant). Everything appears to check out.
Can anyone explain under what circumstances you would be unable to load a type from an assembly? And can anyone explain to me how to properly resolve the issue with this specific library?
In My case I removed the "Microsoft.IdentityModel.Protocol.Extensions" from my packages. and worked like a charm.
I have been tasked with converting an old .Net 2.0 application to 4.0 and am running into a build error related to a missing dependency.
The build error is as follows:
Error 1 Could not load file or assembly 'Atalasoft.dotImage.Ocr.GlyphReader.DLL' or one of its dependencies. The specified module could not be found.
I was thinking that I needed to find a newer version of this DLL but I wanted to see if anyone knew an easier method for resolving this first.
Any help would be great!
A .NET 4.0 or later assembly can reference and use an assembly built on the .NET 2.0 framework. The problem is that the compiler cannot find the assembly, not that the assembly is the wrong version. Try the following steps, this should clear up your problem:
Highlight the reference in the project and go the the properties tab (F4 shortcut). Check the path that is used to reference the assembly and verify that it is actually located there.
Check if the project requires a specific version of the assembly. Go to the same properties page like mentioned in step 1 and see if specific version is set to true, change it to false if this is not a requirement for you.
If you are using NuGet ensure that the latest assemblies have been downloaded if you are not persisting your references to the source repository. You check this by going to the nuget project references and in the top right corner there will be a message asking you if you want to restore all package references if they cannot be found.
If you are not using nuget for this and it still does not work then remove the reference and manually re-add it to the project.
I have two assemblies that I have built, assembly A references assembly B. Both work fine when they are both version 1.0.
But whenever I want to update the assemblies, I increment assembly B to 1.1 and build the DLL. Then I change project/assembly A to reference the 1.1 version of assembly B. Everything builds just fine. But when I go to run my application that invokes assembly A (which in turn invokes assembly B) I am getting a runtime error saying that version 1.0 of assembly B cannot be found.
I hope I've made myself clear enough, It's not so easy to explain...
Well, something somewhere wants 1.0; your best bet is to trawl back through trying to find what is still referencing 1.0, and fix that. However, if you are happy that the API is forwards compatible, you can also fix this in configuration, via a <bindingRedirect> from 1.0.0.0 to 1.1.0.0 (or whatever the version is). See MSDN: http://msdn.microsoft.com/en-us/library/eftw1fys(v=vs.110).aspx
I made a change to an ancillary DLL that my project uses, built it of course, renamed the legacy DLL to *.dll_old, and copy and pasted in the new version of the DLL to that same folder.
However, when I then ran the app that uses the DLL, it errored out with:
"An expected error has occurred...bla bla bla...or select Details for more information.
I did select Details, and saw:
TypeLoadException
File or assembly name <name of the DLL, which I just replaced>
Version=<bla>
Culture=neutral
PublicKeyToken=null, or one of its dependencies, was not found.
UPDATE
Based on the comments, I guess there's more to replacing a DLL than one might expect. I don't know if this is significant or not, I thought replacing a DLL would be like replacing an EXE, but maybe not: the DLL project's AssemblyInfo.cs says,
[assembly: AssemblyVersion("1.3.*")] // used by .NET framework only
[assembly: AssemblyFileVersion("1.3.0.308")] // File Version - increment here
[assembly: AssemblyInformationalVersion("6.3.0")] // Product version - set to current IEQ system
...and the Version in the err msg is "1.3.3889.27539"
Do I need to update one of these lines (I would guess the middle one, if so) to that value (1.3.3889.27539)? Or...???
UPDATE
So since the .DLL is not strongly named, I tried simply removing the reference (to the old .DLL) in the project that uses the DLL and then adding it back again (same file name, different version). I see, though, that updating the .DLL does not change the version numbers shown above - IOW, the AssemblyInfo.cs does not get updated when building. Should it? Do I need to manually update these vals?
It seems that types inside your original DLL were referenced by your EXE file. WHen you replaced it with your own version the references were messed. The EXE file contains metadata table with a list of types, methods, properties, etc that it references and exact version of the assemble expected. Providing something else even if everything was the same but the version number is simply not the same thing. That is why you are getting the exception.
UPDATE: Yes it is possible. However it involves creating a manifest file. For more information check this MSDN web site on Redirecting Assembly Versions. Also, keep in mind that only strongly signed assemblies can be redirected. Non-signed assemblies will be ignored.
In the assemblyInfo.cs I have AssemblyVersion and AssemblyFileVersion.
Normally I just increment the AssemblyVersion like this.
1st digit: Major change
2nd digit: Minor change
3rd digit: bug fixes
4rd digit: Subversion revision number
However, I am wondering what is the AssemblyFileVersion for, and when do I need to increment. Should it be the same as the assemblyVersion?
Should I just comment it out, if I am not using it?
Many thanks for any advice,
AssemblyVersion is used by the .NET class loader and identifies the .NET version of the assembly. AssemblyFileVersion represents the File Version contained in a standard VERSION_INFO block of a Windows PE file...in other words, it represents the file version as seen in the file properties dialog.
If you omit the AssemblyFileVersion, the compiler will default it to be the same as the AssemblyVersion.
Generally the file version is more precise than the assembly version. Per example: System.Windows.Form.dll - Assembly Version: 2.0.0.0, File Version: 2.0.50727.3053.
The assembly version is an important information when it is time to load an assembly.
So, if you find a small bug in one of you referenced assembly. You fix the bug, update the file version but you keep the same assembly version. The advantage: you dont have to relink your references to this assembly to the new version and with the file version you can know the current revision of your file.
Installers will use AssemblyFileVersion to determine whether to overwrite a file based on version.
It's important to note that changing the AssemblyVersion for an assembly that implements serialization has some serious consequences when trying to deserialize from a previous version.
I am not an expert, and I may not be referencing an expert, but from what I have understood, broadly speaking the AssemblyVersion is about the 'interface' -> what the assembly does, backward compatibility etc. And the AssemblyFileVersion is more to do with implementation, which build etc.
Use AssemblyVersion attribute to specify "Last Compatible-To" version and AssemblyFileVersion attribute to specify the build version.”
-> http://www.shitalshah.com/blog/IsJeffRichterScrewingUpTheNetVersioning.aspx
//Oh, and another thing.
There are certain circumstances (about which I'm not too clear, as I've only heard about them but not actually experienced them) where if you try to update an application with dll's in the GAC, old versions of dlls won't be overwritten by new versions with the same Assembly Version number, unless the File Version has changed. (Is that sentence complicated enough? It's late here...)
AssemblyFileVersion is used to set the version info in the Win32 resource in your
binary, the one you see if you open the properties window for the file
in Explorer.