Could not load file or assembly
Could not load file or assembly
Could not load file or assembly
Could not load file or assembly
Could not load file or assembly
Could not load file or assembly Could not load file or assembly Could not load file or assembly Could not load file or assembly Could not load file or assembly Could not load file or assembly Could not load file or assembly Could not load file or assembly
Could not load file or assembly Could not load file or assembly
Could not load file or assembly
Go Back  Xtreme Visual Basic Talk > > > Could not load file or assembly


Reply
 
Thread Tools Display Modes
  #1  
Old 04-09-2010, 03:14 AM
JustinCase2 JustinCase2 is offline
Junior Contributor
 
Join Date: Apr 2006
Posts: 324
Default Could not load file or assembly


I have a program developed in vs 2005 (vb), and a setup program to deploy it. The program uses several dll files, but i get the error "Could not load file or assembly" when running the program on a 64 bit operating system. The program installs fine, and most of it works, but when it is supposed to load one of 2 dlls in a subfolder of the install folder, i get the error. "Could not load file or assembly. The system cannot find the file specified.". The files are there, and the program runs fine on 32 bit systems. Also, under installation, if i choose a different install folder than the default, it ignores it and still installs it on the default location (\program files (x86)\...).

A previous version of the program works fine on 64 bit, but after i did this:
Assembly Cache
It no longer works, and it is those dll's that is the problem.

Ideas?
Reply With Quote
  #2  
Old 04-09-2010, 04:41 AM
PlausiblyDamp's Avatar
PlausiblyDampCould not load file or assembly PlausiblyDamp is offline
Ultimate Contributor

Forum Leader
* Expert *
 
Join Date: Nov 2003
Location: Newport, Wales
Posts: 2,058
Default

Have you tried setting the application to build as a x86 application rather than as AnyCpu? You should be able to set this from either the build options or the build toolbar.

If that solves the problem it looks like the 3rd party dll you are using is 32bit only.
__________________
Intellectuals solve problems; geniuses prevent them.
-- Albert Einstein

Posting Guidelines Forum Rules Use the code tags
Reply With Quote
  #3  
Old 04-09-2010, 06:39 AM
JustinCase2 JustinCase2 is offline
Junior Contributor
 
Join Date: Apr 2006
Posts: 324
Default Yes, I have

And that made no difference. However, if I move the file to the application folder AFTER install, it finds it. To put it differently:
The program is installed to c:\program files (x86)\AppFolder
The dll's are installed to two subfolders:
c:\program files (x86)\AppFolder\PDFLib7 and
c:\program files (x86)\AppFolder\PDFLib8
because they have the same name. Now, after install, if I move one of the dll's from the subfolder to the appfolder, it finds that file and that version works fine.
Anything else I might have missed?

Oh, and I know the DLL's are written for 64 bit aswell. And I do not get this issue at all on 32 bit.

Last edited by JustinCase2; 04-09-2010 at 06:53 AM.
Reply With Quote
  #4  
Old 04-09-2010, 07:15 AM
PlausiblyDamp's Avatar
PlausiblyDampCould not load file or assembly PlausiblyDamp is offline
Ultimate Contributor

Forum Leader
* Expert *
 
Join Date: Nov 2003
Location: Newport, Wales
Posts: 2,058
Default

You could use an app.config file to tell your app where to look for these files - http://msdn.microsoft.com/en-us/libr...8VS.80%29.aspx gives the details / syntax.

This way you would edit the config file to tell it which folder to look in.
__________________
Intellectuals solve problems; geniuses prevent them.
-- Albert Einstein

Posting Guidelines Forum Rules Use the code tags
Reply With Quote
  #5  
Old 04-09-2010, 08:17 AM
JustinCase2 JustinCase2 is offline
Junior Contributor
 
Join Date: Apr 2006
Posts: 324
Default Hmm

I am assuming that the web.config file should be created for the projects that actually referance the DLL? I have several projects in my solution, but only the PDFL7_Relay and PDFL8_Relay actually referance the dlls. The other project referance those again.
Anyway, i created app.config for those 2 projects and provided the folder to check as per the link instructions, but alas! it did not help.
Reply With Quote
  #6  
Old 04-09-2010, 03:18 PM
PlausiblyDamp's Avatar
PlausiblyDampCould not load file or assembly PlausiblyDamp is offline
Ultimate Contributor

Forum Leader
* Expert *
 
Join Date: Nov 2003
Location: Newport, Wales
Posts: 2,058
Default

If you are creating the two wrapper dlls could you not give them slightly different names rather than the same name but in different folders? If the two real dlls are strongly named then they can be installed into the GAC and you wouldn't need to worry about where they are loaded from yourself as the .Net framework will take care of that.
__________________
Intellectuals solve problems; geniuses prevent them.
-- Albert Einstein

Posting Guidelines Forum Rules Use the code tags
Reply With Quote
  #7  
Old 04-10-2010, 11:32 AM
AtmaWeapon's Avatar
AtmaWeaponCould not load file or assembly AtmaWeapon is offline
Fabulous Florist

Forum Leader
* Guru *
 
Join Date: Feb 2004
Location: Austin, TX
Posts: 9,500
Default

DO NOT FOLLOW ALL OF THE INSTRUCTIONS IN THE PROJECT ATTACHED BEFORE I GIVE YOU MY WORD THAT IT'S HARMLESS. Uh... it's harmless, but you might want to know what it does first. Read the post.

I found an interesting solution, but won't talk about it until I say some other things. Such is my nature.

The best solution is to get on the vendor's case and have them install the DLL to the GAC. If the DLLs are strong-named and in the GAC I'm almost certain you can use app.config to tell the application to use multiple versions of the DLL. All bets are off if they have a different name or public key token though.

Read the documentation for application configuration files. The <assemblyBinding> element lets you specify a lot of stuff about how to find the assembly. The <probing> element lets you add paths to where the .NET CLR will search; by default it only looks in a few directories including the directory of the executing assembly. Redirecting Assembly Versions is a big help, but has a big fat obstacle:
Quote:
You cannot redirect versions for assemblies that are not strong-named. The common language runtime ignores the version for assemblies that are not strong-named.
It's just not safe to allow assemblies that aren't strong-named to be redirected. When an assembly doesn't have a strong name, nothing prevents Baron von McEvil from compiling an evil version of the DLL that does nasty things and forcing your application to use it. Keep in mind users can edit app.config files. If the libraries you are using aren't strong-named, you should really bother the vendor and ask them to do so.

OK, anyway, the solution if you don't have a strong-name key. I was making a pretty complicated example until I stumbled upon the AppDomain.AssemblyResolve event. It's really weird as events go, so let's talk about it. First, read the documentation.

Solution
This event is raised when the app domain tries to resolve an assembly and fails. The event handler must return an Assembly that can be used in its place or Nothing. It is very, very strange for event handlers to return a value. I think this is the only event in the entire .NET Framework that behaves in this manner. There's also some tricks to getting it to work, so I've attached an example to accompany the discussion.

First, this example won't work as-is. The forums strictly forbid any attachments that contain executables, so you're going to have to do some work to get things set up. The project contains a readme.txt file with instructions for setting up the application.

The application itself is simple. It depends on the excellent library "Library.dll" to provide a Rockstar class that addresses the crowd using a string that Rockstar.GetGreeting() returns. In my implementation, GetGreeting() returns a string that reflects the version so you can see the magic happening as the application finds DLLs.

If you follow the readme.txt instructions you'll randomly get v1 or v2. Basically what happens is when the form tries to use a Rockstar, .NET tries to load the Library assembly. It can't find it in the GAC or the application directory, so the AppDomain.AssemblyResolve event is raised. AssemblyFinder.AppDomainOnAssemblyResolve() looks in subdirectories for "Library.dll". If at least one is found, the first one is loaded and returned. I didn't go out of my way to bullet-proof this by handling all exceptions; you should do the work I left out.

This is dangerous. For an example of one reason why, follow the readme.txt instructions for the "Dangerous Stuff" scenario. (Don't worry, there's nothing really dangerous and you have the source code to verify.) When you set up this scenario, it's as if a version 3 of the Library assembly was created and it dramatically changed the Rockstar interface. The application can't create an abstract class, so it dies with a whimper. I'd check versions when loading assemblies to see if you've got one you're sure you can use.

This is also a security risk, as evidenced by the

DO NOT FOLLOW THESE INSTRUCTIONS WITHOUT READING MY EXPLANATION. DO NOT FOLLOW THESE INSTRUCTIONS WITHOUT READING MY EXPLANATION.

"Malicious Stuff" scenario. DO NOT follow the instructions in the readme.txt. Read them. For this scenario, you're doing the same thing as the "Dangerous Stuff" scenario. However, this time you play the part of Baron von McEvil who has analyzed your application and figured out that he can create *any* .NET assembly named "Library" with a file name of "Library.dll" and provide a "Rockstar" class with a "GetGreeting()" method and thus run arbitrary code with the privileges of your app. Let's say he has a page set up that pretends to have an update to your application, and he's talked a user into installing his dangerous Library.dll. What happens?

Fun stuff. Writing WackyForm.vb was probably the most programming fun I've had in a long time. You should really look over the source, I'm proud of it. It's a bunch of amateur obfuscation but I got some chuckles. Bonus points for catching the video game references/memes. Go ahead and try to figure out what it does; the Rename refactoring tool will help you loads (it's how I did most of the work.)

Anyway, if you don't FOLLOW MY ADVICE TO NOT RUN THE FORM then you're in for a treat. I won't tell you what happens if you run Baron von McEvil's code, but I will promise you that it is harmless and won't last for longer than 20 seconds. No data is stolen, deleted, or mangled. Do not freak out and start CTRL+ALT+DEL or ALT+F4 like a madman; you might close something you didn't want to close and *then* you'd lose data. Sit back and enjoy the show, because I know you can't resist

If you're curious how you can protect yourself from tampering like this demonstration, the answer is strong names. Part of giving an assembly a strong name is generating a gigantic hash token that uniquely identifies the file. It is very hard and impractical to generate a malicious file that has the same token, so if you load a file using its strong name you can be certain it's what you want. (Unless Baron von McEvil has stolen the key used to sign the DLLs. Then you're hosed.)
Attached Files
File Type: zip FindAssemblyDemo.zip (48.6 KB, 4 views)
__________________
.NET Resources
My FAQ threads | Tutor's Corner | Code Library
I would bet money 2/3 of .NET questions are already answered in one of these three places.
Reply With Quote
  #8  
Old 04-13-2010, 01:26 AM
JustinCase2 JustinCase2 is offline
Junior Contributor
 
Join Date: Apr 2006
Posts: 324
Default Well

I'm giving the "strong names" another try. But it stops for me at the al.exe utility, and one of the input variables. All the tutorials/explenations etc. I can find on this issue says this:

al /out:<assembly name> <module name> /keyfile:<file name>

Ok. Assembly name is fine, so is keyfile. But what is "Module name" in this context? They all explain it like this:

"module name is the name of the code module used to create the assembly"

witch tells me absolutely nothing. I know, I should probably get this, but I'm getting too annoyed here...
Reply With Quote
  #9  
Old 04-13-2010, 02:34 AM
PlausiblyDamp's Avatar
PlausiblyDampCould not load file or assembly PlausiblyDamp is offline
Ultimate Contributor

Forum Leader
* Expert *
 
Join Date: Nov 2003
Location: Newport, Wales
Posts: 2,058
Default

You shouldn't really need to be using al.exe just to assign a strong name to an assembly. You can assign the key either through visual studio (Project properties -> signing -> sign the assembly and browse to the key file) or by adding
Code:
<Assembly: AssemblyKeyFile("<path to key file>")>
to a source file (normally in the assemblyinfo.vb file)
__________________
Intellectuals solve problems; geniuses prevent them.
-- Albert Einstein

Posting Guidelines Forum Rules Use the code tags
Reply With Quote
  #10  
Old 04-13-2010, 02:37 AM
JustinCase2 JustinCase2 is offline
Junior Contributor
 
Join Date: Apr 2006
Posts: 324
Default Well, yes, that's true

But I am talking about the third party dll's... I do not have the source code for those.
Reply With Quote
  #11  
Old 04-13-2010, 03:36 AM
PlausiblyDamp's Avatar
PlausiblyDampCould not load file or assembly PlausiblyDamp is offline
Ultimate Contributor

Forum Leader
* Expert *
 
Join Date: Nov 2003
Location: Newport, Wales
Posts: 2,058
Default

I would have thought the manufacturer would have already signed the dlls with a strong name, if they haven't then you can't install them in the gac for starters.

If they have been released by the manufacturer without a strong name you are pretty much out of luck unfortunately.
__________________
Intellectuals solve problems; geniuses prevent them.
-- Albert Einstein

Posting Guidelines Forum Rules Use the code tags
Reply With Quote
  #12  
Old 04-13-2010, 03:43 AM
JustinCase2 JustinCase2 is offline
Junior Contributor
 
Join Date: Apr 2006
Posts: 324
Default Hmm

I CAN install them to the GAC, and they get different version numbers. But when I try to reference them in my project i get "Reference to this file already exists". Maybe I am doing something wrong?

Asked the creators of the dll's, and this is the answer i get:

our PDFlib 7.0.4 and PDFlib 8.0.0 pdflib_dotnet.dll are strong name dlls. But what you want to do, is not possible. You can not link two PDFlib dlls to the same application. (Due to name conflicts of the API)

So we can only recommend to have two versions, one link against PDFlib 7 and the other again PDFlib 8. Also, a simple replace of the PDFlib dll
(pdflib_dotnet.dll) might work, however it's not recommended and not supported. You have to reference and link against the new dll.


Reply With Quote
  #13  
Old 04-13-2010, 04:11 AM
PlausiblyDamp's Avatar
PlausiblyDampCould not load file or assembly PlausiblyDamp is offline
Ultimate Contributor

Forum Leader
* Expert *
 
Join Date: Nov 2003
Location: Newport, Wales
Posts: 2,058
Default

If they are already strong named then you don't need to strong name them yourself. Given they don't recommend dynamically loading their libraries this way I would create two wrapper libraries of my own (one that references each of the two versions) and a 3rd library of common interfaces that are implemented by my other two libraries.

I would then strong name all three of my own libraries with my own key. My main application would have a design time reference to the library containing the common interfaces and would then dynamically load the correct one of my two wrapper dlls.
__________________
Intellectuals solve problems; geniuses prevent them.
-- Albert Einstein

Posting Guidelines Forum Rules Use the code tags
Reply With Quote
  #14  
Old 04-13-2010, 04:17 AM
JustinCase2 JustinCase2 is offline
Junior Contributor
 
Join Date: Apr 2006
Posts: 324
Default Aye

That's pretty much what I had done, and seemed to work fine. But then I got the issue on 64 bit systems, that the dll's cannot be found in the subdirectories. My workaround now seems to have to be to copy the correct dll to the app folder after the user chooses his version (the user has to select what version dll he/she uses anyway). It's ugly but i guess it might work.
Reply With Quote
  #15  
Old 04-13-2010, 04:22 AM
PlausiblyDamp's Avatar
PlausiblyDampCould not load file or assembly PlausiblyDamp is offline
Ultimate Contributor

Forum Leader
* Expert *
 
Join Date: Nov 2003
Location: Newport, Wales
Posts: 2,058
Default

If the pdflib dlls are in the GAC then your wrapper dlls should be able to find them correctly based on the version they were built against. Your wrapper dlls could be in the gac or the same folder and they should then be able to be loaded at runtime just fine.
__________________
Intellectuals solve problems; geniuses prevent them.
-- Albert Einstein

Posting Guidelines Forum Rules Use the code tags
Reply With Quote
  #16  
Old 04-13-2010, 04:26 AM
JustinCase2 JustinCase2 is offline
Junior Contributor
 
Join Date: Apr 2006
Posts: 324
Default Like I said

Works fine for 32 bit, errors with "Cannot find the file specified" on 64 bit. If i copy the dll from the subfolder and into the main app folder (after install), it works fine on 64 bit aswell.
Reply With Quote
  #17  
Old 04-13-2010, 07:18 AM
JustinCase2 JustinCase2 is offline
Junior Contributor
 
Join Date: Apr 2006
Posts: 324
Default Well

Ended up building it so that if the user changes what version he uses (and he must do so at first run), the correct dll is copied from the subfolders to the app folder. Works fine on all systems now, but it is certainly an ugly workaround.

Anyway, thanks a million for helping me out with this!!!!
Reply With Quote
Reply


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off

Forum Jump

Advertisement:





Free Publications
The ASP.NET 2.0 Anthology
101 Essential Tips, Tricks & Hacks - Free 156 Page Preview. Learn the most practical features and best approaches for ASP.NET.
subscribe
Programmers Heaven C# School Book -Free 338 Page eBook
The Programmers Heaven C# School book covers the .NET framework and the C# language.
subscribe
Build Your Own ASP.NET 3.5 Web Site Using C# & VB, 3rd Edition - Free 219 Page Preview!
This comprehensive step-by-step guide will help get your database-driven ASP.NET web site up and running in no time..
subscribe
Could not load file or assembly
Could not load file or assembly
Could not load file or assembly Could not load file or assembly
Could not load file or assembly
Could not load file or assembly
Could not load file or assembly Could not load file or assembly Could not load file or assembly Could not load file or assembly Could not load file or assembly Could not load file or assembly Could not load file or assembly
Could not load file or assembly
Could not load file or assembly
 
Could not load file or assembly
Could not load file or assembly
 
-->