Hey guys (and gals) I'm having a problem using Assembly GetExportedTypes() in .NET 4.0. The same code is working perfectly in a project targeted at an older .NET version.
NOTE: *The code works for local assemblies but when trying to open them off a network drive it does not work, that is my problem... It looks to be loading the assembly, but it claims it can't find it when using GetExportedTypes(). Again if I open a dll off my machine it works, this error only occurs with dlls located on network drives *
EDIT: The error is thrown on GetExportedTypes
The Code:
Assembly assembly;
Type[] t;
assembly = Assembly.LoadFrom(dllPathOpenFileDialog.FileName.ToString());
t = assembly.GetExportedTypes();
The Error:
Could not load file or assembly '*..***.***.****, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified.
(I used asterisks to hide personal information - the file name)
The way certain security policies are handled was changed in .NET 4.0. This article should provide some background.
Related
I am trying to include some reference files in Wix# managed project using DefaultRefAssemblies.Add method:
ManagedProject project = new ManagedProject();
project.DefaultRefAssemblies.Add("FontAwesome.Sharp.dll");
project.DefaultRefAssemblies.Add("protobuf-net.dll");
project.DefaultRefAssemblies.Add("Newtonsoft.Json.dll");
project.DefaultRefAssemblies.Add("ManagedOpenSsl.dll");
project.DefaultRefAssemblies.Add("ssleay32.dll");
When I try to build a MSI I get an error. The problem happens to be in loading of ssleay32 assembly (part of OpenSSL). When I exclude this file, the build succeeds. Can you please help me understand the exception? The target framework of the Wix# project is .NET Framework 4.8.
Unhandled Exception: System.BadImageFormatException: Could not load file or assembly '361984 bytes loaded from WixSharp, Version=1.15.0.0, Culture=neutral, PublicKeyToken=3775edd25acc43c2' or one of its dependencies. An attempt was made to load a program with an incorrect format. ---> System.BadImageFormatException: Bad IL format.
Wixsharp supports .net assemblies compiled for:
Platform x86
Managed assemblies (Not native)
Target framework 3.5
So, make sure "ssleay32.dll" has 3 requirements above. Every ssleay32 assembly i have found was native (unmanaged).
Workaround in case of no luck with:
You can try to save ssleay32.dll to embedding resource file and before "ManagedOpenSsl.dll" types usage you should load dll in the memory. Load unmanaged assembly
Good luck!
I've added Microsoft.Bcl.Build/Microsoft.Bcl and Microsoft.Bcl.Async to some projects in my solution where I want to use async/await.
Everything works fine on my machine with .Net4.5 installed. However, when I start the application on a machine with only .Net4 installed, at some point, the application crashes with the following Exception:
Could not load file or assembly 'System.Threading.Tasks, Version=1.5.11.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
Looking at the StackTrace, the exception seems to be generated in a third party library that we reference.
When I analyze the Microsoft.Threading.Tasks.dll provided by Microsoft.Bcl.Async, I see that it does reference System.Threading.Tasks Version 1.5.11.0, but version 2.6.10.0 is included in Microsoft.Bcl.
Am I doing something wrong?
I found the solution! It was actually very simple. I just had to copy and paste the binding redirects that nuget adds in the app.config files into the *.exe.config file. Then it just magically works. Easy fix.
I'm having error when running WPF application with reference to C:\Program Files\Affectiva\Affdex SDK\bin\release\Affdex.dll
Exception:
Could not load file or assembly 'Affdex, Version=3.1.1.419, Culture=neutral, PublicKeyToken=null' or one of its dependencies. An attempt was made to load a program with an incorrect format."
The WPF application is running under .Net Framework 4.5 and I'm running SDK version downloaded as AffdexSDK-3.1.1-419-win64.exe
According to this Affdex.dll depends on affdex-native.dll and loads it in runtime. Make sure that the latter is accessible to your program by adding it to your %PATH% variable or by adding it to your visual studio project. See example in AffdexMe source code.
I have an application that relies on a set of third-party DLLs, version v1.1. In order to use them, I reference the main one, which is found somewhere under the Program Files folder. This library uses the other ones, installed in the GAC.
A new version of the third-party DLLs is released, v1.2. The DLL in the Program Files folder is replaced by the new version; in the GAC, both versions co-exist.
The problem is to get the application (compiled with DLLs v1.1) to work when v1.2 is installed, without re-compiling it, and without changing the app.exe.config file.
I am the maintainer of the DLLs; additional constraints are that only the latest version of the DLL is installed in Program Files, and other DLLs are all installed in the GAC (all versions are kept).
My problem is that the application starts, but eventually I get an error because of incompatibilities between types:
Unhandled Exception: System.InvalidCastException:
[A]ThirdParty.User cannot be cast to [B]ThirdParty.User.
Type A originates from 'ThirdParty, Version=1.2.0.0, Culture=neutral, PublicKeyToken=XXXX'
in the context 'Default' at location 'C:\Windows\Microsoft.Net\assembly\GAC_32\ThirdParty\v4.0_1.2.0.0__XXXX\ThirdParty.dll'.
Type B originates from 'ThirdParty, Version=1.1.0.0, Culture=neutral, PublicKeyToken=XXXX'
in the context 'Default' at location 'C:\Windows\Microsoft.Net\assembly\GAC_32\ThirdPart\v4.0_1.1.0.0__XXXX\ThirdParty.dll'.
I am not sure to understand how the v1.2 DLL is chosen, I am guessing that the path to the DLL is stored in the application, which in turn decides to use the DLLs in the GAC for this version? I am testing on a system different from the one used for compiling, but the DLLs are located in the same location. My understanding from the documentation is that the v1.1 version in the GAC should be chosen, not v1.2.
Where is my mistake? How can I fix it?
Thanks,
I found a solution in my specific case, and re-reading my question I realize I did not mention that my initial DLL does rely on a PowerShell instance. Which is where I worked around my problem. In my DLL, I load a specific version if the DLL that is present in the GAC, and load it in my PowerShell instance:
var assembly = Assembly.Load("ThirdParty, Version=1.1.0.0, Culture=neutral, PublicKeyToken=XXXX");
var ps = PowerShell.Create();
ps.Commands.AddCommand("Import-Module").AddParameter("-Assembly", assembly);
ps.Invoke();
I have got this error when using Enterprise Library 3.1 May 2007 version. We are developing a product and have a common lib directory beneath the Subversion Trunk directory
<>\Trunk\Lib\ into which we put all the third party DLLs. Inside this we have Microsoft\EnterpriseLibrary\v3.1 in which we have copied all the dlls from \Program Files\Microsoft Enterprise Library May2007\bin. Everything was working properly until one of the developers installed the source code on this machine. There were some dlls copied at the end of the source code installation and once that was done, he is not able to run the project anymore. He always gets this error
'Microsoft.Practices.EnterpriseLibrary.Data, Version=3.1.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)'
What is the problem here? I thought that when the source code was installed it was just supposed to build everything and copy in the bin directory within the source code parent directory. Also we have copied the Dlls from Microsoft Enterprise Library May 2007\bin directory into our product development directory and references into our project with a copylocal flag set to true.
Can anyone help me out here
RK
I used to get that when I developed against the signed version of the dll and deployed where only the unsigned version was available.
Also, fuslogvw.exe. EVERY. TIME.
I assume the error lies in the developer having compiled the code against the unsigned source code compilation he has.
Make sure he adds the reference to the signed DLLs before compiling his code.
Microsoft.Practices.EnterpriseLibrary.Data, Version=3.1.0.0, Culture=neutral, PublicKeyToken=null
should be something like:
Microsoft.Practices.EnterpriseLibrary.Data, Version=3.1.0.0, Culture=neutral, PublicKeyToken=fa03fef243232
maybe you should check the Assembly- and FileVersion of the dll. if they do not match this exception can occur.
Read here to get started with assembly loading debugging.
In short you need to check the Fusion log for more information.
For a "The located assembly's manifest
definition with name [yourAssembly]
does not match the assembly reference"
message (for hresult
FUSION_E_REF_DEF_MISMATCH,
0x80131040): The Fusion log will say
which part of the assembly reference
failed to match what was found. It
will be the assembly name, culture,
public key (or token) or version (if
the found assembly was
strongly-named).