Could not load file or assembly after deploy - c#

I am developing app, which uses PDFLibNet.dll, everythings works fine on my pc, but when I deploy application and try to use it in another pc, creating PDFWrapper class (from PFDLibNet.dll) throw me an exception:
Could not load file or assembly "PDFLibNet.dll" or one of its dependencies.The specified module could not be found.
The same scenario on Win7 and XP
PDFLibNet.dll is stored in the same directory as binary .exe file of my app.
Any suggestion how to fix it?
I am using .Net4.0, Win7
Thanks!

It can be 2 possible reasons:
1. Check if dll was build for x86 or x64 or AnyCPU if you target machine x64 build your dll x64
2. It can be because of MS C++ redistrubute updates! uninstall them and try to start app again. Or you can either install the redistributable on the target machine.

Related

BadImageFormatException when deploying on windows server 2012 r2

I am deploying my Asp.net application on Windows Server 2012 R2(x64). I get a runtime BadImageFormatException while using 64-bit dll. When I run it with IIS Express or application published on local machine IIS everything works well (Application pools -> solution name -> Enable 32-bit applications set to False, All projects in solution are also set for Platform target x64). Deploy is going through Team City & Octopus Deploy.
What the solution could be?
UPD
System.BadImageFormatException: An attempt was made to load a program with an incorrect format. (Exception from HRESULT: 0x8007000B) at libxl.XmlBook.xlCreateXMLBookC() at xxx.Controllers.xxx.xxxController.LibxlTest() in C:\TeamCity\buildAgent\work\aeb63fe0b246a1f3\xxx\xxx\Controllers\xxx\xxx\xxxController.cs:line 597
There is no such path C:\TeamCity\buildAgent\ on server whrere the Octopus Tentacle is.
Finally, it works with x86 (from bin folder) version while the solution was build for x64. Probably, it is a peculiarity of libxl. Thus, I'm developing with x64 and after deploy my post-deploy script changes it for x86 version.
OK, it looks like you or one of your references has a dependency on libXL.
Your exception result (0x8007000B) is definitely a 32-bit can't load on 64-bit issue.
libXL is C++ project, in the download zip there's a bin64 folder with a copy of libxl.dll that will work in 64-bit mode.
If you have a libXL licensed copy better to use the 64-bit dll from that.
Note that C:\TeamCity\buildAgent\ comes from the machine your project was built on, the line numbers etc get saved into your pdb files.

What might cause MSBuild to behave differently from machine-to-machine?

I have a C# program (not ASP.NET or even web-related) with platform AnyCPU targeting .NET v3.5 that references a 32-bit third-party .dll. Unfortunately, I also have several "work of art" build machines in our CI pipeline that build this program. I'm trying to add another one but I can't figure out what allows it to build.
Whenever I try to build on this new machine, I get
LC : error LC0000: 'Could not load file or assembly 'ASSEMBLY' or one
of its dependencies. An attempt was made to load a program with an
incorrect format.'
So far my only lead is that someone's installed several unneeded programs (visual studio 2010, several C++ runtimes, Windows SDK, etc) but those shouldn't break my build and I don't want to uninstall things willy nilly.
Here is the command which works on my old build machine and fails on my new one:
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\MSBuild.exe /property:Configuration=release;Platform=AnyCPU;TargetFrameworkVersion=v3.5 Utilities\UtilityGUI\UtilityGUI.csproj
If I change the Platform property to x86 it works on both machines. Changing it to x64 breaks it on both machines.
What could be causing this? I checked msbuild.exe.config on the machines and compared the registry under SOFTWARE/Microsoft/VisualStudio as well as SOFTWARE/Microsoft/MSBuild. I don't want to change code as it works on my other machines and branches that haven't had a merge yet couldn't build on this machine.
The problem is with your 32-bit reference. You can't load a 32-bit assembly into a 64-bit process. Is there a reason why you can't target x86 exclusively?
As for why it's building on one machine and not the other, it may be that the AnyCPU profile on one machine is set to prefer 32-bit, or it may be that the machine that's successfully building is actually a 32-bit machine and is targeting x86 out of necessity. Either way, you won't be able to produce x64 builds when referencing a 32-bit dll.

BadImageFormatException on SQLite load on certain computer

I've created a very simple console app in .NET 4.0 that will run as a scheduled task. It looks for local files that are unmodified for a certain amount of time and then parses the file, inserts a record into a MySQL database, and copies the file to the network. I'm using a local SQLite database to track which files have already been processed, but unfortunately I'm running into a problem on one system at the first SQLite operation:
System.BadImageFormatException: Could not load file or assembly 'System.Data.SQLite.dll' or one of its dependencies. is not a valid Win32 application. (Exception from HRESULT: 0x800700C1) File name: 'System.Data.SQLite.dll'
at FileDatabase.CreateDatabaseAndTable()
at Program.Main(String[] args)
This exception is thrown on one system (Windows 7 x64 Home Premium with .NET 4.0 full), but is not thrown on two other systems (dev system + one other, both Windows 7 x64 Professional with .NET 4.0 full).
From browsing other questions, I see that this can happen when the program is run in 64-bit mode since the SQLite DLL is the 32-bit version. The first thing I checked is that the active platform is x86 in the Visual Studio Configuration Manager. I also used IL DASM to verify that the output exe is 32-bit (.corflags 0x00000003 // ILONLY 32BITREQUIRED). I would prefer to keep the 32-bit SQLite DLL and target platform as x86 so that I do not have to make different versions of the application for 32- and 64-bit computers.
I've also read that this exception can occur because of a corrupted DLL file, but since it works on some computers, I think this is not the case.
Other things I've tried on the problem system that didn't help:
Searching the GAC and Windows directory for errant SQLite DLLs, but found none.
Turning off AVG anti-virus.
Running the exe directly instead of the published ClickOnce application.
Uninstalling and reinstalling the ClickOnce application.
Any suggestions would be appreciated - thanks!
Installing the full setup package from system.data.sqlite.org/index.html/doc/trunk/www/downloads.wiki seems to have solved the problem - it must have been some dependency that was not present (possibly in Windows 7 Professional but not Home?). While this solution isn't perfect for a big deployment, I really just needed it on this one computer. Thanks for RoadBump for getting me on the right path.

C# application with access database won't work on 64 bit windows 7

I made C# application for my friend which has connection to access database (mdb file). I have developed application on my computer with win7 x86 installed. My friend had XP and it worked perfectly, but now he installed win7 x64 and application doesn't work. In fact, application starts and behave regular, but cannot connect to database... Database too can be opened with access, but my application cannot connect to it.
What can be a problem? How to make my application works on both operating systems?
regards,
Vajda
Ask your friend to download and install the following file:
Microsoft Access Database Engine 2010 Redistributable
and make sure he picks the 64-bit version there (AccessDatabaseEngine_x64.exe).
By default there is no 64-bit ODBC/OLEDB driver for Access installed, but the 2010 version should work for 2007 databases as well.
You could probably also configure your program to be built for the x86 target. That would run the program as a 32-bit program, even on 64-bit OS.
Most likely, the .Net CLR is trying to fire the app up in 64bit mode by default on his new win7 box and this might be causing some issues with the referenced assemblies.
The first thing I would try is to change the Platform target of the application (go to Project properties in Visual Studio for the application) to x86 (from Any CPU) to force the application to run in 32bit mode.
If this works, you will have narrowed down your problem.
Then, after building the project, look in the bin folder to see which assemblies are being copied to the output folder. If you see any System.Data... or any other .Net assemblies that are already contained in the GAC, you'll want to delete these and then try to fire it up. This will force the application to use GAC assemblies written for 64bit use.

On some computers application can't load sqlite dll file

I wrote an application that uses sqlite and it works great on most of the systems. It is written in C#, and the only non-framework assembly is sqlite, which is included by System.Data.SQLite.dll .
I deploy it the same way on all of the machines (copy pasting the exe file, the database file and the System.Data.SQLite file). It works great for all my PC's and most of the PC's I've tried.
But then I've got reports that for some people it throws the following exception:
Could not load file or assembly
'System.Data.SQLite, Version=1.0.65.0,
Culture=neutral,
PublicKeyToken=db937bc2d44ff139' or
one of its dependencies. An attempt
was made to load a program with an
incorrect format.
Now I've made sure the dll file is in the same folder than the application exe file. It's the same dll, with the same version as stated in the exception message above.
I was really confused by this, so I created a fresh virtual machine, installed windows 7 professional on it, and just copy pasted the files, and the thing worked. So if it works on a fresh windows, I can't imagine what the other PC's could be missing...
Note: Two of those machines where the project throws the exception are also running windows 7 proffesional.
I would really appreciate any help on this, because I'm fresh out of ideas...
Here's a possibility: Is the difference between the working and not-working machines 32-bit vs. 64-bit? Are you building for "Any CPU", when you should be building for just the bitness of your external DLL?
It is possible that the machines that throw the exception are running a 64-bit version of Windows and that your program is using the AnyCPU configuration. The System.Data.SQLite DLL is a two-faced beast: a managed part and a native-part. It could be that the native-part is responsible for the exception.
See this question for more info.
Have you checked whether the target system is 64-bit or 32-bit?
It might be that one of your dependencies requires a 32-bit version of Windows. To solve the issue you can specify a platform target in the properties of your C# project: Choose x86 instead of Any CPU.

Categories

Resources