I have a project going on witch uses a DLL from an ERP system.
The DLL is used to get information from the ERP, like invoices and such.
The error i am getting is:
Inner Exception 1: FileNotFoundException: Could not load file or
assembly 'SnelStartGatewayInterface, Version=12.48.37.0,
Culture=neutral, PublicKeyToken=null' or one of its dependencies. The
system cannot find the file specified.
But in the same window I used 'watch 1' to see the current using assembly's with the method:
AppDomain.CurrentDomain.GetAssemblies()
It returns a couple of assembly's.
This is the one loaded in and exactly the same as seen in the error:
+ [36] {SnelStartGatewayInterface, Version=12.48.37.0, Culture=neutral, PublicKeyToken=null} System.Reflection.Assembly
{System.Reflection.RuntimeAssembly}
Why would it return me the error?
Ps. I have tried the exact same method and dll in a windows forms test app and it was running fine.
Like Pawl Lukasik mentioned in the comments, you should look at the dependencies.
To do this, use:
private List<string> ListReferencedAssemblies()
{
List<string> refList = new List<string>();
var assemblies = Assembly.GetExecutingAssembly().GetReferencedAssemblies();
foreach (var assembly in assemblies)
{
refList.Add(assembly.Name);
}
return refList;
}
to see all referenced assemblies.
Or with LINQ:
private List<string> ListReferencedAssemblies()
{
return Assembly.GetExecutingAssembly().GetReferencedAssemblies().Select(x => x.FullName).ToList();
}
Related
As a continuation of my previous question.
I load DLL through this code.
Example 1:
var assembly = Assembly.LoadFile("C:\\Temp\\PROCESSOR\\SKM.dll");
And that's work fine.
But I use serialization that internally use this code, example 2:
var ass1 = Assembly.Load("SKM, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null");
And this code throws an exception: System.Runtime.Serialization.SerializationException: Unable to find assembly "SKM, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null". - that's because the DLL in a separate folder.
How to force CLR to see DLL in separate directory (not in subfolders of main application)?
I tried this:
<codeBase version="1.0.0.0" href="C:\\Temp\\PROCESSOR\\SKM.dll"/> - do not work because it works only for subfolders.
<probing privatePath="paths"/> - do not work because it works only for subfolders.
First run first example, and then run second example. But even if the SKM.dll already loaded, CLR does not see my assembly.
I found resolution here.
Just adding an event to AssemblyResolve:
AppDomain.CurrentDomain.AssemblyResolve += (sender, args) =>
{
string fileName = new AssemblyName(args.Name).Name + ".dll";
string assemblyPath = Path.Combine("C:\\Temp\\PROCESSOR", fileName);
var assembly = Assembly.LoadFile(assemblyPath);
return assembly;
};
And if DLL can not be found standard way, the event fired and load DLL from my folder.
Is there any particular reason you don't want to go with example 1 if you know where the DLL is?
If you really don't then one option would be to register the DLL in the GAC.
https://msdn.microsoft.com/en-us/library/dkkx7f79%28v=vs.110%29.aspx
I discovered that after my application generates Telerik report
var result = new ReportProcessor().RenderReport("PDF", new InstanceReportSource { ReportDocument = new MyTelerikReport(data) }, null);
var stream = new MemoryStream(result.DocumentBytes);
return CreateHttpFileResponse("MyReport.pdf", stream, "application/pdf");
I am not able to get all types within CurrentDomain
var typesWithAttribute = (from a in AppDomain.CurrentDomain.GetAssemblies()
from t in a.GetTypes() //error appears here
//some filtering logic
select t).ToList();
I am getting error
System.Reflection.ReflectionTypeLoadException: Unable to load one or
more of the requested types. Retrieve the LoaderExceptions property
for more information.
LoaderExceptions:
System.IO.FileNotFoundException: Could not load file or assembly
'DocumentFormat.OpenXml, Version=2.0.5022.0, Culture=neutral,
PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The
system cannot find the file specified. File name:
'DocumentFormat.OpenXml, Version=2.0.5022.0, Culture=neutral,
PublicKeyToken=31bf3856ad364e35'
After some investigation I found that assembly that fails to load: Telerik.Reporting.OpenXmlRendering, Version=8.0.14.311, Culture=neutral, PublicKeyToken=a9d7983dfcc261be and that assembly doesn't exists in AppDomain.CurrentDomain.GetAssemblies() before I generate report (I assume that assembly loaded dynamically by Telerik.Reporting, Version=8.0.14.311, Culture=neutral, PublicKeyToken=a9d7983dfcc261be).
I could filter out that assembly as I don't need any types from that but I am a bit worried about fact of having assemblies in domain that cannot be loaded - seems a bit wrong to me.
Could someone explain what there happens? Is it my issue or that is fault of 3rd party library that doesn't load all required assemblies?
The issue is not the assembly but the Type coming from a dependent assembly that has not been loaded.
If the GetTypes method is called on an assembly and a type in that assembly is dependent on a type in an assembly that has not been loaded (for example, if it derives from a type in the second assembly), a ReflectionTypeLoadException is thrown.
http://msdn.microsoft.com/en-us/library/system.reflection.assembly.gettypes(v=vs.110).aspx
I have a collection of DLLs(say 20). How do I find out all the DLLs on which one specific DLL (say DLL A) is depending upon?
If you mean programmatically, use Assembly.GetReferencedAssemblies.
You can use that recursively to find all the assemblies you need. (So you find the dependencies of X, then the dependencies of the dependencies, etc.)
Since the question is tagged "C#", I would assume you are talking about managed dlls (assemblies). In that case, dependencywalker is not useful. If you want to do that with a program, good ones are dotPeek by JetBrians and Reflector by RedGate. Or you can even use the object inspector in Visual Studio.
However, it can be a long process and cumbersome too. I would write a short C# program/F# script that uses Assembly.GetReferencedAssemblies, as Jon mentioned.
If instead you want to examine native DLLs dependencies with a program (C# code), you have to walk the examine the PE file (the MS dll and exe file format) and its IAT (import address table). Not easy, but not impossible...
I would start here on MSDN and here to understand PE sections, and use a managed library to read it (there are many, including some from the Mono project (I'm thinking of Cecil, it should work with native binaries too); in the past I have used this one from the good John Gough.
All answer credit goes to previous authors for the usage of Assembly.GetReferencedAssemblies. This is just a write-and-forget C# console app that works solely for .NET assemblies. return 0 on assemblies you were able to check, and when successful, outputs them to STDOUT. Everything else will return 1 and print some kind of error output. You can grab the gist here.
using System;
using System.Reflection;
using System.IO;
namespace DotNetInspectorGadget
{
class DotNetInspectorGadget
{
static int Main(string[] args)
{
if(args.GetLength(0) < 1)
{
Console.WriteLine("Add a single parameter that is your" +
" path to the file you want inspected.");
return 1;
}
try {
var assemblies = Assembly.LoadFile(#args[0]).GetReferencedAssemblies();
if (assemblies.GetLength(0) > 0)
{
foreach (var assembly in assemblies)
{
Console.WriteLine(assembly);
}
return 0;
}
}
catch(Exception e) {
Console.WriteLine("An exception occurred: {0}", e.Message);
return 1;
} finally{}
return 1;
}
}
}
Usage:
call %cd%\dotnet_inspector_gadget.exe C:\Windows\Microsoft.NET\assembly\GAC_64\Microsoft.ConfigCI.Commands\v4.0_10.0.0.0__31bf3856ad364e35\Microsoft.ConfigCI.Commands.dll
Output:
mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
System.Xml, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
System.Management.Automation, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35
System.Core, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
System.Security, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
System.Management, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
You can use dependency walker http://www.dependencywalker.com to figure this out. Take note on the difference between x32 and x64 though.
Dependency Walker is a free utility that scans any 32-bit or 64-bit
Windows module (exe, dll, ocx, sys, etc.) and builds a hierarchical
tree diagram of all dependent modules.
For .NET assemblies, a terrific tool to view the assemblies an assembly is dependent on is AsmSpy.
If you want the DLL's (the files) then, Assembly.GetReferencedAssemblies will also return the .Net Framework assemblies.
Here is a simple code snippet that will get the dll's it can find in the current directory (and also include some other related files):
private readonly string[] _extensions = { ".dll", ".exe", ".pdb", ".dll.config", ".exe.config" };
private string[] GetDependentFiles(Assembly assembly)
{
AssemblyName[] asm = assembly.GetReferencedAssemblies();
List<string> paths = new List<string>(asm.Length);
for (int t = asm.Length - 1; t >= 0; t--)
{
for (int e = _extensions.Length - 1; e >= 0; e--)
{
string path = Path.GetFullPath(asm[t].Name + _extensions[e]);
if (File.Exists(path)) paths.Add(path);
}
}
return paths.ToArray();
}
You can call it like so: MessageBox.Show(string.Join("\r\n", GetDependentFiles(Assembly.GetEntryAssembly())));
I have an assembly on a shared folder (UNC-path only, no mapped drive). When I try to register it programmatically via RegistrationServices, I'm getting a strange error.
Here's the code:
using System;
using System.IO;
using System.Reflection;
using System.Runtime.InteropServices;
namespace BLRegisterAssembly
{
public static class BlRegisterAssembly
{
public static void Register()
{
var asm = Assembly.LoadFile(#"\\myUNCPath\myAssembly.dll");
var rs = new RegistrationServices();
rs.RegisterAssembly(asm, AssemblyRegistrationFlags.SetCodeBase);
// I've also tried AssemblyRegistrationFlags.None : same error.
}
}
}
This is the error I'm getting:
"Could not load file or assembly
'[xxxxxxxxxxxxx],
Version=1.0.0.0, Culture=neutral,
PublicKeyToken=[xxxxxxxxxxxxxx]' or
one of its dependencies. The system
cannot find the file specified."
(The file in question is a referenced assembly that the main assembly uses).
Some more points:
- the referenced assembly is located in the same folder as the main assembly that I'm trying to register.
- the folder cannot be mapped as a logical drive. Because of how the network folders are accessed, users in different groups have different drive mappings to the same network folders, and these cannot be modified, per IT policy...
Can anyone point me in the right direction to resolve the problem?
ANSWERED
Because I was using Assembly.LoadFile, the dependent assemblies have to be resolved manually via AssemblyResolve. The following code update fixed my woes:
public void Register()
{
AppDomain.CurrentDomain.AssemblyResolve +=
new ResolveEventHandler(CurrentDomain_AssemblyResolve);
var asm = Assembly.LoadFile(Path.Combine(m_path, assemblyName));
var rs = new RegistrationServices();
rs.RegisterAssembly(asm, AssemblyRegistrationFlags.SetCodeBase);
}
static Assembly CurrentDomain_AssemblyResolve(object sender,
ResolveEventArgs args)
{
//... code to resolve the path and load the dependent assembly...
}
You should never use LoadFile(), use LoadFrom() so the CLR has a shot at finding any dependent assemblies. If you still have trouble then use Fuslogvw.exe to get a trace of the assembly resolution attempt. The backup plan is to implement AppDomain.AssemblyResolve.
I have this weird problem that I cannot handle myself. A class in the model of my mvp-project designed as singleton causes an InvalidCastException.
The source of error is found in this code line where the deserialised object is assigned to the instance variable of the class: engineObject = (ENGINE)xSerializer.Deserialize(str);. It occurs whenever I try to add one of my UserControls to a Form or to a different UC. All of my UCs have a special presenter that accesses the above mentioned instance variable of the singleton class.
This is what I get when trying to add a UC somewhere:
'System.TypeInitializationException: The type initializer for 'MVP.Model.EngineData' threw an exception. ---->
System.InvalidCastException: [A]Engine cannot be cast to [B]Engine. Type A originates from 'MVP.Model, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' in the context 'LoadNeither'
at location '[...]\AppData\Roaming\Microsoft\VisualStudio\9.0\ProjectAssemblies\uankw1hh01\MVP.Model.dll'.
Type B originates from 'MVP.Model, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' in the context 'LoadNeither'
at location '[...]\AppData\Roaming\Microsoft\VisualStudio\9.0\ProjectAssemblies\u_hge2de01\MVP.Model.dll'
...
So I somehow have two assemblies and they are not accessed from my project folder, but from a VS temp folder? I googled a lot and only found this: IronPython Exception: [A]Person cannot be cast to [B]Person. There is a solution offered, but it concerns IronPhyton and I don't know where to use it within my project.
Types are per-assembly; if you have "the same" assembly loaded twice, then types in each "copy" of the assembly are not considered to be the same type.
These issues normally crop up when the two assemblies are in the Load and LoadFrom contexts. See
Difference between LoadFile and LoadFrom with .NET Assemblies?
and the link to suzcook's blog for details on that issue.
Also, consider using the fusion log viewer to help diagnose the problem.
http://msdn.microsoft.com/en-us/library/e74a18c4%28VS.71%29.aspx
Judging by the context in which the assembly is getting loaded (the context is "LoadNeither"), some developers may be doing something like loading an assembly that has been internally packaged as a resource with your application. If you do this, you will be using the AppDomain.CurrentDomain.AssemblyResolve event handler, so that your application can specify where .NET should get any particular assembly that it needs.
My answer will not explain the machinations of how to do that - but I'm mentioning it because this process led directly to the same exact error encountered by the original poster. As Eric Lippert mentions, types are per-assembly. So if you load an individual assembly more than once, the same defined class will appear as different classes - even though visual inspection shows that they appear to be the same.
We've seen instances in which .NET will call the ResolveEventHandler more than once for the same DLL. I'm not sure why .NET sometimes does this (it happened on some machines, but not all machines). But to resolve the problem, we needed keep a global list of handles to loaded assemblies, so that if .NET wanted to load the assembly again, we returned a handle to the same Assembly that was originally loaded, instead of loading another copy into memory.
I have included the code that caused the issue for us, and notes about how to handle it properly.
public void AppStartup (object sender, StartupEventArgs e)
{
AppDomain.CurrentDomain.AssemblyResolve += new ResolveEventHandler(CurrentDomain_AssemblyResolve);
}
public System.Reflection.Assembly CurrentDomain_AssemblyResolve(object sender, ResolveEventArgs args)
{
string dllName = args.Name.Contains(',') ? args.Name.Substring(0, args.Name.IndexOf(',')) : args.Name.Replace(".dll", "");
dllName = dllName.Replace(".", "_");
if (dllName.EndsWith("_resources")) return null;
System.Resources.ResourceManager rm = new System.Resources.ResourceManager(GetType().Namespace + ".Properties.Resources", System.Reflection.Assembly.GetExecutingAssembly());
byte[] bytes = null;
try
{
bytes = (byte[])rm.GetObject(dllName);
}
catch (Exception ex)
{
}
if (bytes != null)
{
// the following call will return a newly loaded assembly
// every time it is called
// if this function is called more than once for the same
// assembly, you'll load more than one copy into memory
// this can cause the InvalidCastException
// instead of doing this, you keep a global list of loaded
// assemblies, and return the previously loaded assembly
// handle, instead of loading it again
return System.Reflection.Assembly.Load(bytes);
}
return null;
}
My situation involved two copies of the same dll. One was in the bin folder and one was in a sub-folder of the same bin folder. Both were loaded, amazingly some things worked fine, but some things didn't and that's when this error message appeared:
System.InvalidOperationException; There was an error generating the XML document.; Source: System.Xml; TargetSite: Void Serialize(System.Xml.XmlWriter, System.Object, System.Xml.Serialization.XmlSerializerNamespaces, System.String, System.String);
Hidden in this was the following inner exception (this was to do with Microsoft Dynamics CRM 4.0, but could relate to anything)
System.InvalidCastException; [A]XXX.CRMCustomCode.YYY.CreateCompanyRequest cannot be cast to [B]XXX.CRMCustomCode.YYY.CreateCompanyRequest. Type A originates from 'XXX.CRMCustomCode, Version=2.0.0.0, Culture=neutral, PublicKeyToken=null' in the context 'LoadFrom' at location 'C:\Program Files\Microsoft CRM\Server\bin\assembly\XXX.CRMCustomCode.dll'. Type B originates from 'XXX.CRMCustomCode, Version=2.0.0.0, Culture=neutral, PublicKeyToken=null' in the context 'Default' at location 'C:\Program Files\Microsoft CRM\Server\bin\XXX.CRMCustomCode.dll'.;
I simply deleted the duplicate dll (in C:\Program Files\Microsoft CRM\Server\bin) and the error went away.
My particular case - class library referenced in web application was renamed and rebuilt. Older version of library was still in bin folder under old name. The framework loads whatever in bin folder (both libraries) and emits this error. So it happens not only when assemblies are loaded explicitly.
The obvious solution in my case is to clean bin folder.
I got it working when I tried changing this cast:
var t = (TeacherWebPages)Session["TeachersAD"];
To this:
var t = Session["TeachersAD"] as TeacherWebPages;
However the assembly/session/memcache was different and no data got back but no error occurred. So later I still had to delete specific temporary files every time source page was changed from the folder it was complaining about which would require me to kill IIS process from task manager. Or in my case I can just logout and it clears the session state.