We Keep Coding

Could not load an assembly despite it being referenced

I'm looking at incorporating the new Google Apps Script Execution API into an existing C# plugin i have already working. I am following the .NET quickstart guide provided as a console application (which i have gotten working without problem).
When porting the code from that into my plugin it will also fail at runtime at the first instance of:
UserCredential credential;
which I slimmed down the code so far to just that line which fails giving:
"Could not load file or assembly 'Google.Apis.Auth, Version=1.9.2.27817, Culture=neutral, PublicKeyToken=4b01fa6e34db77ab' or one of its dependencies. The system cannot find the file specified."
The file is properly referenced (having installed via nuget).
C# is not my normal field and perhaps i'm missing something in the subtlety of it working in a Console App.
What gives?

There was a time when console apps defaulted to using the client profile rather than the full .Net framework. Check the properties of the project on the Application tab and make sure the target framework doesn't end with Client profile. If that doesn't work try using the fusion log viewer, which you'll find conviently located at C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin, or any number of other places. Run it as an admin and it'll tell you what it can't load (which may or may not be Google.Apis.Auth) and where it looked for the file at.

This has been a little bit of a red herring. Not very well documented is the fact for the app i am building against, Autodesk Navisworks,
plugin dependency libraries have to be duplicated in a separate directory altogether from the plugins directory.
Easily fixed for the build environment, but will need a little more thought for when creating a distributable.

Debugging "Could not load file or assembly" that only happens on some computers

So I recently updated my software and with the new version I supply a new dll-file, lets call it My.dll. Now, the old version works just fine on every computer I have tried.
The problems began with the new version. Specifically, so far on at least one computer, it states that "Could not load file or assembly My.dll". This even happens when I have dropped a copy of the software on a network drive and run the software directly from there. It works on every other computer but one, which still gives the exact same error where other computers work fine.
The dll in question is even in the same directory as the executable, so I'm really quite bummed here. I tried to google around a bit as well, but all the issues I found were related to ASP.NET specifically. Any ideas on how to go about finding the problem would be much appreciated.

It is possible that the computer in question has a DLL added to it's Global assembly cache. This would take priority over the DLL in the same folder.
More information about the GAC: http://msdn.microsoft.com/en-us/library/yf1d93sz(v=VS.100).aspx

Is there an old copy of the DLL lying around? Perhaps with a different name? I had a similar issue when I changed the name of a dll. Internally, the namespaces were the same.
In my case, an older version of the DLL was still there. .NET got confused with two assemblies in the bin directory having the exact same namespaces and classes, couldn't decide on which to load, and threw an exception.
Removing the older version of the dll solved the issue.

Use the Assembly binding log viewer and set it to log failures. This will give you some clues as to why it is not loading.

You could take a look at the error log using the Assembly Binding Log Viewer. First you have to turn on logging.

--Right Click on Project
--Goto Properties->Build tab
--Change Platform and Platform Target to Any CPU, Save and run

Detected dependencies problem

I cannot build the solution. The error output is:
Looking at other people's suggestions pointed to missing dependencies. So I checked it:
The properties of a file like Dsofile.dll points to a location on the hard drive. I have checked it and the SourcePath is correct and it is marked as "Exclude" because unmarking it leads to another error. The Dsofile.dll cannot be shared in GAC. So where's the error? The list of dependencies is longer. There is about another 10 SI.ArchiveService.*.dll files.

Dsofile.dll is inprocess COM Server for those who use .NET to interact with Office documents when Office is not installed. But, to do so, one has to install this file. It can be done following
this link.
Do you have installed MS Office? Maybe that is the problem. Also, there are several missing files as can be seen on screenshot (MDIVWCTL.DLL - it is used for Microsoft Office Document Imaging), PDFCreator.exe, etc. You definitely should check if missing assemblies exist on your machine, and if so, change paths to them. But, I suppose that COM Servers don't exist or they are not registered since they should be found if they are properly registered. My recommendation is to reinstall missing components.

AppDomains and licence files

We have a dll which uses a third party component, with embedded licence file (licx). now we are trying to use our dll in a windows service applicaiton, using mulitple appdomains. the code get compiled. but when im running it im getting an error message, saying cannot find the runtime licence.
could someone explain me this. when use the dll in a single domain it works fine. please help.
Thanks.

How are you creating the AppDomain? There is a LicenseFile on AppDomainSetup; are you setting this? I'm not 100% "up" on license files and their use within AppDomains, but that may help a little...
Unfortunately information on this area (license files vs embedded) looks very sparse... you could try copying the embedded resource to a temp file?

If there is some static method/property to set then it is likely that you will have to do this per app domain.
I was under the impression however that licx files were only compiled into the executable project not into dll's.
Thus is your service is being started via a route that is not using the executable which had the license embedded in it then it will not get licensed. If you run the service but do not create multiple app domain's what happens?

Error when calling a .net dll from Com Visible dll using javascript

I am developing a windows 7 gadget.I am creating an activex object and loading the assembly.I am following the methodlogy mentioned here at codeproject (GadgetInterop). One of the tasks of the gadget is to interface with Facebook.
This is how I am referencing:
Javascript creates a GadgetBuilder object.
From here I load the my library. say "MyLibrary.dll".
When I call method say MyLibrary.GetCount(), (just return some integer) it works.
But when I call some facebook function inside the method say MyLibrary.GetFaceBookFeeds() it throws an error.I reference "facebook.dll" from CodePlex
If I test my code from a ASP.NET form it works perfectly. However, When I run it from my html page by trying to load it using javascript, I get the following error:
Could not load file or assembly 'facebook, Version=2.1.3654.38113, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified.
I verified that the dll's are in the same folder as "MyLibrary.dll".
Why is this error coming?
How do I go about achieving my task? (I need to use calling a dll from javascript as we are doing a lot of other things in the dll).

You're not forced to use a reflection-based assembly loader for .net code in desktop gadgets, you can write the assembly to be com visible, using class ids, etc. This article provides an example of using .net to achieve what you're trying to do without the "adapter".
That being said, there are various problems with activex based desktop gadgets that you should be aware of:
When an ActiveX instance is created in the gadget, the assembly dll will be "locked open" by sidebar.exe and the file cannot be deleted, even after the gadget has been closed. Unfortunately the gadget uninstallation process doesn't account for this and an uninstallation of the gadget will result in sidebar.exe copping out of the file deletion when it fails to delete the assembly, leaving the assembly and any other remaining files that hadn't been deleted up to that point. There's also no error message displayed. The same is true of overwriting a gadget (with a new version, for instance) - sidebar.exe attempts to delete the folder completely before installing the new gadget package, resulting in a failed installation in most cases.
The registration of such an activex control can be very tricky. The registry script given in the CodeProject article you provided does not work on my Windows 7 x64, for instance. The only way to work around this is to use WMI to write to the registry.
In a similar fashion, unregistration of the ActiveX control is also an issue. When the user uninstalls the gadget, the registry entries are left behind. Not a problem for a lot of people I suppose, but imagine a gadget enthusiast who tries every gadget he finds suddenly discovering the many unused registry entries. You can get around this by removing the registry entries directly after instantiating the object (since it's cached by the sidebar process anyway) and re-registering it again next startup.
So really although you can do it without reflection, using reflection can be a better option because you can copy the adapter assembly to an alternative folder, use it to load the current assembly and then unload it when the gadget is closed or finished using it. This eliminates the first issue of not being able to uninstall the gadget because the hosting assembly is located in a different folder and the reflected assembly is unloaded when the gadget is closed anyway.
The reason facebook.dll isn't loading is because the loader you're using doesn't correctly resolve dependencies (it can't find the file because it doesn't know where to look). You're welcome to try our reflection-based assembly loader called PluginLoader and see if that works. We haven't had an official release for it yet but we were intending to make it widely available and recommended for use by all developers to try and eliminate the problems with ActiveX and Windows Desktop Gadgets. Because we haven't officially released it you'll have to install our gadget, Auction Sidebar Tool which will install the plugin loader ready for use with the following code:
var plLoader = new ActiveXObject("Sidebar.PluginLoader");
var myLibrary = plLoader.LoadAssembly(classToLoad,
System.Gadget.path+"\\path\\to\\MyLibrary.dll");
myLibrary.GetFaceBookFeeds();
Where class to load is the class you need to load in the format Namespace.Class (ie MyLibrary.MyClass). We specifically coded it to correctly resolve any dependencies so it should work for you just fine. If it does work for you, you're welcome to include it with your gadget. All you need is the PluginLoader.js and PluginLoader.dll files from the AuctionSidebarTool folder, but you'll need to edit the PluginLoader.js file to remove the parts that reference our assembly (line 110 onwards). If you include this in your project, it will check for an existing PluginLoader.dll and if it fails, it will copy it to the Windows Sidebar folder in local AppData, register it and provide the AddInLoader object with the methods LoadAssembly and UnloadAssembly. If you need any extra help just let me know in the comments.
Hope that helps. That's probably the longest answer I've written so far on SO :)