I have created DLL using pgSQL(to read data and return to Automation Anywhere) and I am trying to use it in an Automation anywhere bot. But it shows an error:
Could not load file or assembly 'npgsql, Version=4.0.2.0, Culture=neutral, PublicKeyToken=5d8b90d52f46fda7' or one of its dependencies. System cannot find the file specified.
if you have any idea to solve that please help me.
You can try placing all(copy paste) the necessary assemblies ( DLLs) that are required for pgSQL in your DLL function to be invoked into AAE Program files directory. Since Player couldn't load the dependencies of your dll It is throwing this exception.
Another place where you can copy is while running bot see where your dll is located and put all necessary dependent assemblies there When you run your metabot AAE creates temporary folder where it copy your dll. copy dependencies there
You need to add the dependencies you used whilst creating the DLL into the metabot as well, by uploading them alongside your DLL in the assets view. In this case 'npgsql.dll'.
If you've built the DLL on another machine, you can - in addition to the steps above - also try adding the dependent DLLs to the PATH.
Related
My code was working and out of no where I am starting to get this:
System.Windows.Markup.XamlParseException: 'Could not load file or assembly 'Syncfusion.SfGrid.WPF, PublicKeyToken=3d67ed1f87d44c89' or
one of its dependencies. The system cannot find the file specified.'
FileNotFoundException: Could not load file or assembly 'Syncfusion.SfGrid.WPF, PublicKeyToken=3d67ed1f87d44c89' or one of its
dependencies. The system cannot find the file specified.
I ran fugslovw as recommended from other posts but cannot figure out how to solve this. It seems the assembly protocol is looking for Syncfusion.SfGrid.WPF.dll in the wrong directory. Syncfusion.SfGrid.WPF.dll is in the /bin/Debug folder so why isnt it searching there similar to other assemblies it found? I got this dll from nuget package and they are the same version accross my entire project. I also tried cleaning my solution. Any hints please? I have attached the two failing logs here and here. An example of a successful log which I expect is here
Probably the application (ETABS) loads your DLL with Assembly.LoadFrom, therefore resolving the dependencies works at this point in time.
When later WPF tries to load additional dependencies, it does not know about the location of your plugin and thus does not consider your bin directory.
We had a similar problem with a plugin architecture and solved it by pre-loading all required depedencies before the WPF control is created, e.g. by
_ = new AnyTypeFromTheAssembly();
I am trying to make a simple c# program using Growl C# API.
I tried to compile my program in two different ways:
1) I kept my .dll file in the same directory as my .cs file. Than I ran
csc /r:Growl.Connector.dll,Growl.CoreLibrary.dll /out:test.exe *.cs
It compiled fine and also ran fine.
2) Now I have created a directory inside my current working directory named growl and kept all my .dll references there.
Now when I try to compile it using the below command
csc /r:"D:\Modified\Growl_NET_Connector_SDK\libraries\growl\Growl.Connector.dll","D:
\Modified\Growl_NET_Connector_SDK\libraries\growl\Growl.CoreLibrary.dll" /out:test.exe *.cs
It compiled fine but when I tried to run it the below mentioned exception occurred.
Unhandled Exception: System.IO.FileNotFoundException: Could not load file or assembly 'Growl.Connector, Version=2.0.0.0, Culture=n
eutral, PublicKeyToken=980c2339411be384' or one of its dependencies. The system cannot find the file specified.
at GrowlNotification.Program.Main(String[] args)
So, my question is what is the correct way to reference .dll file in csc when files are in an external folder.
Here is the directory structure for 2nd case.
So, my question is what is the correct way to reference .dll file in csc when files are in an external folder.
You're already referencing them at build time. You just need to make them available at execution time too, but copying them into the same directory as the executable, when you want to run it.
You could also investigate using the Global Assembly Cache if these are signed assemblies, but personally I'd stick with just keeping the executable with the libraries on which it depends.
You can add these using the /lib and /reference command-line switches while compiling.
http://msdn.microsoft.com/en-us/library/s5bac5fx.aspx
But (Quote from the article)
An alternative to using /lib is to copy into the working directory any
required assemblies; this will allow you to simply pass the assembly
name to /reference. You can then delete the assemblies from the
working directory. Since the path to the dependent assembly is not
specified in the assembly manifest, the application can be started on
the target computer and will find and use the assembly in the global
assembly cache.
Because the compiler can reference the assembly does not imply the
common language runtime will be able to find and load the assembly at
runtime. See How the Runtime Locates Assemblies for details on how the
runtime searches for referenced assemblies.
so Jon Skeet's answer is better. (I'm just adding this to provide more info than I could in a comment, not as an answer. Jon's answer is the best IMO)
You can create symlinks to the assemblies in your libraries folder so you would only need to keep them updated in one location.
I have a C++ DLL library (let's call it unmanaged.dll) that gets wrapped around a managed .NET library (let's call it managed.dll). The managed.dll uses unmanaged.lib to import/link unmanaged.dll. I have another ASP.NET Web API project that uses managed.dll (let's call the project webapi.dll). Now, whenever I build the Web project, in the output directory I get webapi.dll and managed.dll. Then, I manually copy unmanaged.dll to be in the same output folder so that (presumably) .NET can locate it and load it.
However, when I try to run webapi.dll, it fails with an error that it cannot load managed.dll:
Could not load file or assembly 'managed.DLL' or one of its dependencies. The specified module could not be found.
This is particularly weird because unmanaged.dll is in the same folder.
What I find very weird is that if I put unmanaged.dll under C:\Windows\system32 then .NET can properly load it!
My question is how can I make this unmanaged.dll visible to .NET in the folder where the .NET project output is residing?
It's the IIS that is causing the problems. Had the same problem, sovled it by adding the dll to a folder, that lies in the PATH variable.
How can I use different dll's (other Version) with the same name in one directory?
For Example, LibA (ExternalLib.dll) has Version 1 and LibB (ExternalLib.dll) has Version 2.
I'm deploying all my programs to the same directory (this is our companys standard and I can't change this fact). The problem is if ProgramB which is using the LibB is deployed in the directory where ProgramA is using the LibA then ProgrammA would not longer work.
For my own Libs I use a Major-Version-Number (.01, .02) if there are big changes. But the Lib I'm using is an external Lib and each version of it requires different licensing-keys (which are handled by the programs itself).
I tried to rename the external libs from "ExternalLib.dll" to "ExternalLib.v1.dll" and "ExternalLib.v2.dll", but when I run my fresh compiled programm it throws an exception that says "ExternalLib.dll could not be found". The reference in my project is set to "ExternalLib.v1.dll" and compilation works fine.
Any ideas / suggestions to handle different assembly versions in the same directory?
Unfortunately, the filename of the DLL file has very little do do with how .Net is loading these types. The actual name is written into the meta data of the assembly as part of the compilation process. So at runtime, it will be probing for ExternalLib.dll regardless of what you renamed the file to. The usual way to fix this is to install to the GAC and use Strong Naming to reference the specific version.
Given you may not be able to do this, there are 4 things you could try:
Ask the vendor to produce version specific DLL's for you. They could compile such that the version name is part of the filename and included in the assembly manifest. This would be the simplest solution for you.
Handle the AssemblyResolve event and manually try and use Assembly.Load to point at the file you want such that you can specify specifically which dll to use. See http://support.microsoft.com/kb/837908 for more information, but effectively you'll be using Assembly.LoadFrom(specific_path) to choose the file where the code will load from.
If possible, you might also be able to use ildasm.exe to decompile the dll's to Intermediate Language (IL), then use ilasm.exe to recompile it to a new dll name. You would then reference this new DLL name in your project.
If the assembly is not signed, then you may be able to edit the manifest yourself; you can either use a compatible binary editor or possibly MT.exe.
I have a .dll file in my project folder and would like to load it via Assembly.Load().
AssemblyName name = new AssemblyName("Portable.Store, Version=0.1.0.0, Culture=neutral, PublicKeyToken=12ay62c33eocf6uf");
Assembly assembly = Assembly.Load(name);
However this would throw a FileNotFoundException due to not specifying a path. And I am unable to use Assembly.LoadFrom() or Assembly.LoadFile() because Portable Class Libraries only support Assembly.Load()
Is there a way to do this inside a pcl? Any help is appreciated, thank you!
Edit #1: Would it matter if the assembly I'm trying to load is a non PCL? I know that this defeats the purpose of the PCL however there are a few libraries that are not included in the PCL. Therefore using conditional compilation, depending on the platform, I will load platform specific assemblies.
Edit #2: Found some more information on where the dll should be placed: https://stackoverflow.com/a/6440406/2464165
As of now I just placed it inside my project folder, with the .sln file and what not Where exactly would be the app probing path?
Edit #3: I was able to get my dll file placed inside the Resources Folder of a .dll file. So I have MyPCL.dll and inside that is where I have the ResourcesFolder/Portable.Store. How could I tell the Assembly.Load to look in specific folders instead of just the main AppX root directory?
I'm making the assumption that you are running the portable library in a Windows Store application (based on the assembly name you are trying to load).
There are two places that store apps find their assemblies, either in GAC if it is a framework assembly or the Appx package if it is a user assembly.
As "Portable.Store" (which I assuming is from my PclContrib project) is a user assembly, it must be loaded from the AppX package. To ensure that both assemblies end up in the AppX package, simply make sure that the Windows Store project containing the AppxManifest references both of them. That's it.
If Assembly.Load still cannot find the assembly, check to make sure that the strong name you are passing to Assembly.Load is correct.