I have a solution that contains three projects; UI (winforms), Business Layer and Data Access Layer, and I have created a setup project. I have added UI project as a primary output, and other two projects (actually dlls) automatically added to application folder and these two projects appears under the Detected Dependencies folder in the solution.
After building the solution, I have installed the program. When I run the program, I get the following error:
"Could not load file or assembly 'xxxBL', Version = 1.0.0.0 Culture = neutral, PublicKey Token = null or one of its dependencies." What am I doing wrong?
First make sure the dll that failed to load is actually in the search path of your Application. If it is, run the Dependency Walker on the dll that failed to load to see why it failed to load. Like the error message says it is possible that one of the dll's dependencies failed to load. For instance, a common mistake occurs if you deploy a debug version of your dll. It would work on your development machine since it most likely would have whaterver SDK you used already installed, but on a fresh machine it would fail to load because the debug dlls are not installed. The Dependency Walker will allow you to find this sort of problem.
Related
I am currently writing a desktop application (nothing hosted in IIS or similar, .NET 4.5.2) which makes use of SQLite and the Entity Provider for SQLite. For this to get it to work in Visual Studio, I had to install the 1.0.65.0 version package from the SQLite site to get the EF6 provider for SQLite inside Visual Studio. This worked as expected ad as far as I understood, this is also the only way this can be done.
For my application, I would like to use the current version which is 1.0.104.0 (again, info from the sqlite page). I have successfully added the Nuget package for this version to my application and when I look into the references tab, I can see System.Data.SQLite, System.Data.SQLite.EF6 and System.Data.SQLite.Linq, all with the version 1.0.104.0 and Specific Version set to True. Copy Local is set to true for all three of them.
So now when I run my application and get to the line:
using (var ctx = new SmtAoiLookupEntities())
{
foreach (var lu in ctx.Lookups.Where(d=>!string.IsNullOrEmpty(d.Aoi)))
{
...
}
}
I get the following error message:
An exception of type 'System.IO.FileLoadException' occurred in mscorlib.dll and wasn't handled before a managed/native boundary
Additional information: Could not load file or assembly 'System.Data.SQLite, Version=1.0.65.0, Culture=neutral, PublicKeyToken=db937bc2d44ff139' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
From this, I understand that my application tries to load version 1.0.65.0, although all my references point to 1.0.104.0. I have absolutely no idea where my application gets the idea that I want to load 1.0.65.0. I even did a find in files to catch any reference to "1.0.65" with absolutely no results.
I used
gacutil -l System.Data.SQLite
to see which Assemblies are stored in the GAC -> Version 1.0.104.0
Now, this appears only to happen when I run the application from within Visual Studio; If I run the application outside Visual Studio as an executable I get a different error when saving the context. It appears that this is an application error and not related to the assembly version problem. I have also tried setting the application to a 32bit application, the issue stays the same.
The main issue: I would like to be able to debug the application inside Visual Studio, otherwise this could become quite cumbersome. Any ideas how I tell Visual Studio not to load the 1.0.65.0 libs?
A project in your solution is still pointing to previous SQLite version. In my case it was the project which file was throwing the error. Making sure every project in the solution has the updated package version solved the problem for me.
I've got a web service that references a set of dlls that are currently version 6. I was given version 7 dlls to upgrade to, so I registered the new dlls in the GAC, removed the references in my project to the old dlls and added references in for the new ones. No problems so far.
I then proceeded to alter the App.config, which had references to these dlls and changed their version number to 7.0.0.0 from 6.0.0.0 and built the project. No errors or warnings.
Finally, I installed the web service and tested it out and got the following error:
[System.InvalidOperationException] = {"Unable to create service from
type 'the type,
dll name, Version=7.0.0.0, Culture=neutral,
PublicKeyToken=My token'."}
As I don't have access to the code in the dll's I don't know if it's something in them that's not working or whether it's perhaps a permissions / connection issue. Does anyone have some suggestions?
Press Ctrl + Q in Visual Studio in order to start texting in quick launch text box. Then type 'verbosity'. Change build output verbosity into 'Diagnostic' and analyze your build. That helps a lot in that cases.
We use a 3rd party mixed mode assembly that interfaces with a printer device.
In one of our applications, the assembly functions correctly.
In another application, it was generating the following exception:
Mixed mode assembly is built against version 'v2.0.50727' of the runtime and cannot be loaded in the 4.0 runtime without additional configuration information.
After doing some research, I discovered that I could add the following to the app.config file to resolve this problem:
<startup useLegacyV2RuntimeActivationPolicy="true">
(The application that works already had this setting in its app.config)
Although this did resolve the "Mixed mode assembly" issue, now I'm seeing a somewhat different problem:
External component has thrown an exception
The strange thing is that I have one application which works correctly and another application which does not. They both call the third party assembly via the same code (which is another one of our assemblies).
I tried creating a very simple test app which calls the third party assembly using the same code path, and it also fails with the "External component has thrown an exception" error.
I've compared the app.config files for all of the applications and they are essentially the same, and I've double checked that all of the build settings are the same for each. Both projects target .NET 4.0 and X86.
There is obviously something different about the two applications but I'm at a loss to identify what it is.
Development environment is Visual Studio 2010.
Does anyone have any suggestions on what other areas I could investigate?
#tsells was right: there was a missing dependency
The third party assembly in question depended on another DLL that was present in the first applications bin folder.
I copied all of the files from the working application's bin folder to the non-working application's bin folder, and it resolved the problem.
From there it was just a matter of deducing which DLL was missing and including it in the second applications project.
When there are dependencies missing, you can use tools like CheckAsm for managed and Dependency Walker for unmanaged libraries to check for dependencies.
I just switched from C++ to C# and I am a bit confused about referencing DLLs.
I have a third party DLL and a simple testing application that uses some of its methods. When I compile the project, everything goes well, but when I run the compiled app on another computer, I've got an error that says that the DLL is missing even though the DLL is in the app's working directory. What's even more strange is that I have access to the source code of another app that is dependent on an older version of this DLL and this app works well.
I've gone through the code and all the solution settings without finding anything really different.
Can you tell me how to reference a .dll from a working dir (Visual Studio 2010)?
Below is the exception:
System.IO.FileNotFoundException was unhandled
Message=Could not load file or assembly 'TIS.Imaging.ICImagingControl32, Version=3.2.4.1146, Culture=neutral, PublicKeyToken=257805929e8b7928' or one of its dependencies. The system cannot find the file specified.
Source=ICtestapp
FileName=TIS.Imaging.ICImagingControl32, Version=3.2.4.1146, Culture=neutral, PublicKeyToken=257805929e8b7928
FusionLog=WRN: Assembly binding logging is turned OFF.
To enable assembly bind failure logging, set the registry value [HKLM\Software\Microsoft\Fusion!EnableLog] (DWORD) to 1.
Note: There is some performance penalty associated with assembly bind failure logging.
To turn this feature off, remove the registry value [HKLM\Software\Microsoft\Fusion!EnableLog].
StackTrace:
at ICtestapp.Form1.InitializeComponent()
at ICtestapp.Form1..ctor()
at ICtestapp.Program.Main()
InnerException:
Here's a good blog post from Suzanne Cook from the .net team on debugging .net loader issues.
http://blogs.msdn.com/b/suzcook/archive/2003/05/29/57120.aspx
and here's the details on how it loads:
http://msdn.microsoft.com/en-us/library/yx7xezcf(v=vs.71).aspx
You have to add the dll as reference in your project references, once you added the library in the reference, when you compile the program the dll will be automatically copied to the compilation output folder unless otherwise specified in the reference properties ...
Then if you copy all items that you will find in the compilation output folder in the new location in the other PC, you should not have any problems.
Check also that the .NET framework installed on the other machine is at least as the same level of the project target ..
This also happens when you copy the debug executables over to another machine. Try compiling in release and moving over.
The program worked fine until I did this:
Added a new class under an existing file and an existing namespace.
Added settings to that project the new class belongs to.
Build the solution.
Build the setup project.
Installed the new version on a machine.
When I start the new version on the machine, then I get:
Unhandled Exception:
System.TypeLoadException: Could not
load type
'SI.AS.CommonLogic.Utils.ErrorLog'
from assembly
'SI.AS.CommonLogic.ErrorUtils,
Versions=1.0.0.0, Culture=neutral,
PublicKeyToken=925c8734ae397609'. at
RSMonitor.RSMonitorMain.Main(String[]
args)
ErrorUtils is the new class I have added. There was a file with a static class in it. I added another static class under it and added settings to the project. It runs smoothly on my developer machine in debug mode. But I can't install and run it on another machine. The program can call the other static class from the same file. What am I missing here?
** update **
I tried to install it for a 2nd time and checked the DLL. The timestamp matched the latest compiled version and now it works. I have no idea why it didn't work last time, because it is the same package I installed again. But if I get same error, then I'll try out your suggestions.
Your program looks like it is having trouble locating another assembly, probably called SI.AS.CommonLogic.ErrorUtils.dll. Either that, or it can only find the wrong version of this assembly.
Is this an assembly that is part of your solution?
If so, is it in the "bin" directory on the machines that it is failing to run on (in other words, is this assembly being deployed correctly with your app)?
If not, is this a part of a seperately installed component or application that is installed on your machine but not on the others (ie is this an external dependency that is missing on the other machines)?
One thing that may help here, is to use the Assembly Binding Log Viewer on both the miachine this does work on, and the machine it doesn't to see where it gets loaded from in the working case, and where it is trying to load it from in the failing case.
Note you may need to make a registry change to get this to log all assembly bin info:
Set the HKLM\Software\Microsoft\Fusion\ForceLog registry value to 1 (the value is a DWORD).
It sounds like your DLLs aren't being deployed/overwritten correctly. Try copying your CommonLogic DLL from your development machine to the installation directory and see if it can load it then - and then figure out why!
The other assembly wasn't updated correctly, it is still the old version. Try replacing the assembly by hand with the current version and check if the problem persists; it should go away though.
It sounds like an old version of your assembly is being loaded from somewhere.
A few things to check:
Firstly, have you incorrectly set up a reference to an assembly instead of a project? This can result in subtle, order-dependent build problems. Ensure that the reference type is "project", not "assembly".
Secondly, is the culprit assembly in the GAC on the developer machine? Even if the assembly is a dependency of your build, if it's in the GAC, it may not be copied to your output directory. This problem manifests itself in a very pernicious fashion -- everything looks fine on the developer machine (as it has the assembly in the GAC) despite the build output being wrong, and the customer machine will blow up because the assembly is neither in the GAC nor the install directory. I can't remember if this only applies to assembly references or whether project references will pick it up, too. It's easy to test if it's a problem, though -- just do a clean build, then build your project and examine the assemblies copied to the output directory. They should all be there. If your culprit .dll is missing then you know it's a problem.
I worked at a company that (briefly) built installers for internal releases without using proper assembly versioning, resulting in absolutely terrible problems of this ilk (developer machines would be riddled with assemblies in the GAC).
Check the GAC on both the developer and customer machines. Also try what Josh suggested: Copy the culprit DLL from the developer machine to the customer machine's install directory to see if that fixes it, then work from there.