Forgive me if it has been answered before but I searched the web and found only desperate people asking exactly my question but nobody giving any answer which I could use.
I'm developing an application in C# Visual Studio 2010 which uses Crystal Reports. I'm developing it on 32 bit system. Everything works okay.
Now I'm trying to run it on another computer which is 64 bit system has Crystal Reports installed and some terrible error happens.
************** Tekst wyjątku **************
System.TypeInitializationException: Inicjator typów zgłosił wyjątek dla typu
'CrystalDecisions.ReportSource.ReportSourceFactory'. ---> System.TypeInitializationException:
Inicjator typów zgłosił wyjątek dla typu 'CrystalDecisions.Shared.SharedUtils'. --->
System.IO.FileLoadException: Nie można załadować pliku lub zestawu
'log4net, Version=1.2.10.0, Culture=neutral, PublicKeyToken=692fbea5521e1304' lub jednej z jego zależności.
Forgive me some Polish language there. It basically means that it cannot find some specific version of log4net.dll file which apparently must be used by something.
This problem was described in many places:
log4net not logging and throwing error
http://scn.sap.com/thread/1857957
I understand that my application uses/expects some version of this file and Crystal Reports installed on 64 bit machine uses another version.
Still after browsing the internet I have no idea what steps I should take to correct it.
I would be really grateful for some "tutorial for dummies" how to deal with it.
Oh, and my application needs to be built as 32 bit and run on 64 bit. No possibility of building it as 64 bit, another thing would stop working :(
Installing CR 32 bit (CRRuntime_32bit_13_0_14.msi) will resolve the error.
The 32 and 64 bit versions can be found here.
Well, not much response here :) I've learnt a few things myself since then and have thought I would share my knowledge with any poor beginner people that may encounter the similar problem.
So there is something like GAC - http://en.wikipedia.org/wiki/Global_Assembly_Cache
You may think of it as a collection of libraries and drivers used by your programs.
It is on your computer in c:/windows/assembly but it is a hidden directory so first you must enable seeing it.
At my 64 bit computer it contained GAC_32 and GAC_64 subdirectories. In GAC_64 there was log4net in:
c:\Windows\assembly\GAC_64\log4net\1.2.10.0__692fbea5521e1304\
In GAC_32 there was nothing. So I created the directory and copied the appropriate file from my 32 computer into it and it worked.
c:\Windows\assembly\GAC_32\log4net\1.2.10.0__692fbea5521e1304\
Still a moment later I faced another error but it is a different story
CrystalDecisions.CrystalReports.Engine.ReportDocument'. ---> System.IO.FileNotFoundException: Nie można załadować pliku lub zestawu 'CrystalDecisions.ReportAppServer.CommLayer, Version=13.0.2000.0, Culture=neutral, PublicKeyToken=692fbea5521e1304
Generally expect that anything using Crystal Reports build on 32 bit computer may give problems when tried to run at 64 bit computer. SAP did really a crappy job with these drivers.
Do you have SAP Crystal Reports runtime engine for .NET framework (64-bit) installed on the target machine? If not, you may try installing it from this link and see if it will fix your problem.
Also, if you have installed only the 32bits version on a 64 bits platform, you'll get the same Log4net error; both version, 32 & 64 bits, are required.
It's curious that 64bits msi delploys DLL in SAP 32bits folder (C:\Program Files (x86)\BusinessObjects\Crystal Reports for .NET Framework 4.0\Common\SAP BusinessObjects Enterprise XI 4.0\win32_x86\dotnet\ ) that 32bits setup doesn't.
In my case, installing CR 64-bit wasn't an option, but I was able to work around this issue by enabling 32-bit application on the App Pool in IIS. (See this answer).
Related
I have developed an addin for word in vs2010.It's working cool in 32 bit version of office, but its not working on 64bit version of office .Searched a lot and found that
For 64-bit Root\Software\Microsoft\Office\application name\Addins\add-in ID
For 32-bit Root\Software\Wow6432Node\Microsoft\Office\application name\Addins\add-in ID
registry information path's.I tried register the information for 64bit.Even too its not working in 64 bit of office. In 64 bit office my addin was displaying under InActive Application Add-Ins.I even tried enabling it.
How to develop and deploy an addin for 64 bit of office..?
and am getting the following error ..!!
Could not load file or assembly 'xxxxx, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. An attempt was made to load a program with an incorrect format.
************** Exception Text **************
System.BadImageFormatException: Could not load file or assembly 'xxxxx, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. An attempt was made to load a program with an incorrect format.
File name: 'xxxxx, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'
at MyWord.ThisAddIn.ThisAddIn_Startup(Object sender, EventArgs e)
at MyWord.ThisAddIn.FinishInitialization()
at
Microsoft.VisualStudio.Tools.Office.Runtime.DomainCreator.ExecuteCustomization.ExecutePhase(ExecutionPhases
executionPhases) at
Microsoft.VisualStudio.Tools.Office.Runtime.DomainCreator.ExecuteCustomization.Microsoft.VisualStudio.Tools.Office.Runtime.Interop.IExecuteCustomization2.ExecuteEntryPoints()
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].
An attempt was made to load a program with an incorrect format
In 99% of the cases, that just means one thing when this exception is raised in a 64-bit program. The "incorrect format" is a DLL that contains 32-bit code. That cannot work, a 64-bit program can only load 64-bit DLLs.
If you used C# to write that add-in then it is a very simple fix. Right-click the project in the Solution Explorer window, Properties, Build tab. Set the "Platform target" to AnyCPU. Untick the "Prefer 32-bit" checkbox if you see it (VS2012 and up). Repeat this for the Release configuration.
Other possible explanations for this, the unusual cases:
Not having the 64-bit version of the .NET Framework installed
Writing code in the C++/CLI language, you have to build the x64 version
Having a dependency on a 32-bit unmanaged DLL
Accidentally loading the wrong DLL
You'll need SysInternals' Process Monitor to chase these kind of mishaps down. The trace shows you what DLLs the Office program is looking for and in which directories it looked for the DLL. It will be a big trace, work from the bottom of the trace backwards.
Take a look at the Deploying an Office Solution by Using Windows Installer article in MSDN which describes all the required steps in depth. It states the following:
32-bit
HKEY_LOCAL_MACHINE\SOFTWARE(32-Bit)\Microsoft\Office\Excel\Addins\SampleCompany.ExcelAddIn
64-bit
HKEY_LOCAL_MACHINE\SOFTWARE(32-Bit)\Microsoft\Office\Excel\Addins\SampleCompany.ExcelAddIn
HKEY_LOCAL_MACHINE\SOFTWARE(64-Bit)\Microsoft\Office\Excel\Addins\SampleCompany.ExcelAddIn
An installer for 64-bit Windows requires two registry paths because it’s possible for users to run 32-bit and 64-bit versions of Office on a computer that runs 64-bit Windows.
But you may detect (in the custom actions) the bitness of MS Office installed and create keys in the proper hive.
I have this dll that I created a long time ago and use to connect to the db of a specific software that I develop for. I have had no issues for well over 4 years and countless applications with this dll.
Trying to deploy my latest creation, I get the following error:
System.IO.FileNotFoundException: Could not load file or assembly '***.dll' or one of its dependencies. The specified module could not be found.
So, for every dll I ever wrote, I always made a simple forms application to test that dll just by itself. Running that simple app yielded the same error. The dll doesn't load or use anything else than: System, System.Data, System.XML. So as far as depencies of it go, I don't see anything wrong.
By the way everything works on a dev station. The problem is limited to deployment stations. .Net and the necessary redistributables, since I do everything in C++, are deployed and working.
Running FUSLOGVW.exe showed everything as working fine.
Running depends.exe said: Warning: At least one module has an unresolved import due to a missing export function in a delay-load dependent module.
I already tried rewriting the whole thing. Which yielded the same results.
Clues anyone?
EDITS
Here is the total error message:
See the end of this message for details on invoking \"
just-in-time (JIT) debugging instead of this dialog box.\"
************** Exception Text **************\"
System.IO.FileNotFoundException: Could not load file or assembly 'connectionTo.dll' or one of its dependencies. The specified module could not be found.\"
File name: 'connectionToJobboss32.dll'\"
at TESTConnection.Form1.button1_Click(Object sender, EventArgs e)\"
at System.Windows.Forms.Control.OnClick(EventArgs e)\"
at System.Windows.Forms.Button.OnClick(EventArgs e)\"
at System.Windows.Forms.Button.OnMouseUp(MouseEventArgs mevent)\"
at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)\"
at System.Windows.Forms.Control.WndProc(Message& m)\"
at System.Windows.Forms.ButtonBase.WndProc(Message& m)\"
at System.Windows.Forms.Button.WndProc(Message& m)\"
at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)\"
at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)\"
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)\"
\"
************** Loaded Assemblies **************\"
mscorlib\"
Assembly Version: 4.0.0.0\"
Win32 Version: 4.0.30319.1 (RTMRel.030319-0100)\"
CodeBase: file:///C:/Windows/Microsoft.NET/Framework/v4.0.30319/mscorlib.dll\"
----------------------------------------\"
TESTConnection\"
Assembly Version: 1.0.3996.18980\"
Win32 Version: \"
CodeBase: file:///C:/Program%20Files%20(x86)/conn/TESTConnection.exe\"
----------------------------------------\"
System.Windows.Forms\"
Assembly Version: 4.0.0.0\"
Win32 Version: 4.0.30319.1 built by: RTMRel\"
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Windows.Forms/v4.0_4.0.0.0__b77a5c561934e089/System.Windows.Forms.dll\"
----------------------------------------\"
System.Drawing\"
Assembly Version: 4.0.0.0\"
Win32 Version: 4.0.30319.1 built by: RTMRel\"
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Drawing/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll\"
----------------------------------------\"
System\"
Assembly Version: 4.0.0.0\"
Win32 Version: 4.0.30319.1 built by: RTMRel\"
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System/v4.0_4.0.0.0__b77a5c561934e089/System.dll\"
----------------------------------------\"
There is no errors in the event viewer.
or one of its dependencies
That's the usual problem, you cannot see a missing unmanaged DLL with Fuslogvw.exe. Best thing to do is to run SysInternals' ProcMon utility. You'll see it searching for the DLL and not find it. Profile mode in Dependency Walker can show it too.
I had the same issue with a dll yesterday and all it referenced was System, System.Data, and System.Xml. Turns out the build configuration for the Platform type didn't line up. The dll was build for x86 and the program using it was "Any CPU" and since I am running a x64 machine, it ran the program as x64 and had issues with the x86 dll. I don't know if this is your issue or not, just thought that I would mention it as something else to check.
I recently hit this issue, the app would run fine on the developer machines and select others machines but not on recently installed machines. It turned out that the machines it did work on had the Visual C++ 11 Runtime installed while the freshly installed machines didn't. Adding the Visual C++ 11 Runtime redistributable to the app installer fixed the issue...
I had the same problem. For me, it was caused by the default settings in the local IIS server on my machine. So the easy way to fix it, was to use the built in Visual Studio development server instead :)
Newer IIS versions on x64 machines have a setting that doesn't allow 32 bit applications to run by default. To enable 32 bit applications in the local IIS, select the relevant application pool in IIS manager, click "Advanced settings", and change "Enable 32-Bit Applications" from False to True
I ran into this recently. It turned out that the old DLL was compiled with a previous version (Visual Studio 2008) and was referencing that version of the dynamic runtime libraries. I was trying to run it on a system that only had .NET 4.0 on it and I'd never installed any dynamic runtime libraries. The solution? I recompiled the DLL to link the static runtime libraries.
Check your application error log in Event Viewer (EVENTVWR.EXE). It will give you more information on the error and will probably point you at the real cause of the problem.
This answer is totally unrelated to the OP's situation, and is a very unlikely scenario for anyone else too, but just in case it may help someone ...
In my case I was getting "Could not load file or assembly 'System.Windows.Forms, Version=4.0.0.0 ..." because I had disassembled and reassembled the program using ILDAsm.exe and ILAsm.exe from .Net Framework / SDK version 2. Switching to ILDAsm.exe and ILAsm.exe from .Net Framework / SDK version 4 fixed the problem.
(Strangely, even though doing what I did may seem like an obvious error, the resulting EXE file that didn't work did indicate that it targeted .Net 4 when examined with JetBrains dotPeek.)
I had the same issue - a .dll working all the time, then my computer crashed and afterwards I had this problem of 'could not load file or assembly ....dll'
Two possible solutions: when the computer crashed there may be some inconsistent files in
C:\Users\<yourUserName>\AppData\Local\Temp\Temporary ASP.NET Files
Deleting that folder, recompiling and the error was gone.
Once I had also to delete my packages folder (I had read that somewhere else). Allow Visual Studio / nuget to install missing packages (or manually reinstall) and afterwards everything was fine again.
An easier way to determine what dependencies a native DLL has is to use Dependency Walker - http://www.dependencywalker.com/
I analysed the native DLL and discovered that it depended on MSVCR120.DLL and MSVCP120.DLL, both of which were not installed on my staging server in the System32 directory. I installed the C++ runtime on my staging server and the issue was resolved.
Had the same issue and got it resolved by making sure projects in the solution have the same configuration and platform (in my case it was Debug x64). Somehow the VIsual Studio was missing x64 for part of the projects and I edited the .sln file manually (copied the configurations and platforms from correctly built projects to the projects that were missing the settings I needed). This is what it looks like for one of the projects:
{1BA29980-EE5D-4476-AFFC-0F177B6C9865}.Debug|Any CPU.ActiveCfg = Debug|Any CPU
{1BA29980-EE5D-4476-AFFC-0F177B6C9865}.Debug|Any CPU.Build.0 = Debug|Any CPU
{1BA29980-EE5D-4476-AFFC-0F177B6C9865}.Debug|x64.ActiveCfg = Debug|x64
{1BA29980-EE5D-4476-AFFC-0F177B6C9865}.Debug|x64.Build.0 = Debug|x64
{1BA29980-EE5D-4476-AFFC-0F177B6C9865}.Release|Any CPU.ActiveCfg = Release|Any CPU
{1BA29980-EE5D-4476-AFFC-0F177B6C9865}.Release|Any CPU.Build.0 = Release|Any CPU
{1BA29980-EE5D-4476-AFFC-0F177B6C9865}.Release|x64.ActiveCfg = Release|x64
{1BA29980-EE5D-4476-AFFC-0F177B6C9865}.Release|x64.Build.0 = Release|x64
But then the same error occurred for a project that had a Java file (*.jar) in the dependencies. I had to edit Environment Variables manually to create a record with this value
C:\Program Files\Java\jre1.8.0_171\bin\server
for Java's path, and put it on top of the Path items.
This fixed the issue until I updated Java on my machine. I had to edit the version number in Environment Variables to match the updated folder name.
C:\Program Files\Java\jre1.8.0_181\bin\server
1) Copy DLLs from "Externals\ffmpeg\bin" to your project's output directory (where executable stays);
2) Make sure your project is built for x86 target (runs in 32-bit mode).
Follow this thread for more
I'm working with National Instruments Measurement Studio in C#, and I've come across a bit of a problem in deploying my application to a particular computer (running Windows 7). I've tried asking on the National Instruments forums, but haven't got any solutions yet - could anyone here give me some tips?
Essentially, I have deployed this application several times on a number of computers, but in this particular case I receive an error when running the program -
"System.DllNotFoundException: Unable to load DLL 'nianlys.dll': The specified module could not be found. (Exception from HRESULT: 0x80070007E)
I have ensured that nianlys.dll is present in C:\Program Files
(x86)\National Instruments\Shared\Analysis.
I have ensured that libiomp5md.dll and LV110000_BLASLAPACK.dll, the files from mkl.msm (nianlys.dll has a dependency on mkl.msm), are present. nianlys.dll also has a dependency on nimetautils.msm, but I'm not sure which dlls are included in this.
I have ensured the program is installed by running the setup.exe as an administrator (as opposed to running the .msi that is generated, see here).
I have ensured the computer in question is up to date with updates to the .net framework via windows update.
I have tried reinstalling the program several times, sometimes with a freshly-recompiled installer.
I have tried adding in the 64 bit nianlys.msm into the setup project manually - this throws an error because the TargetPlatform property of the setup project is set to x86. The 32 bit version is, of course, already present in the detected dependencies.
Interestingly, taking a copy of nianlys.dll from C:\Program Files (x86)\National Instruments\Shared\Analysis and inserting it into the directory the program is installed in throws up a different error - in this case, the error is:
"An attempt was made to load a program with an incorrect format. (Exception from HRESULT: 0x8007000B)"
Taking a copy of the 64 bit version of nianlys.dll from another computer (default location C:\Program Files\National Instruments\Shared\Analysis) and inserting it into the directory the program is installed in throws up a third type of error - "System.DllNotFoundException: Unable to load DLL 'nianlys.dll': A dynamic link library (DLL) initialization routine failed. (Exception from HRESULT: 0x8007045A)". It should be noted that this .dll was present before installing the program on the machines that the program works on, but is not present on the target computer that is throwing up problems.
Taking the same 64 bit nianlys.dll and inserting it into the location it was found on on another computer, C:\Program Files\National Instruments\Shared\Analysis, does not solve the original error.
Even more interestingly, I have tried to reproduce the error on a computer on which the program works - removing the x64 version of nianlys.dll throws up the original HRESULT: 0x80070007E error, whereas removing the x86 version causes a windows installer to appear when running the program.
On a computer upon which the program works with no problems, the windows task manager does not seem to indicate that the program is 32 bit (with the *32 suffix on the program name), despite the target platform being set to x86. It seems from all this that there is some issue with the nianlys.dll being used in both its x64 and x86 versions, despite the target platform only being x86.
I'm running out of ideas about what kind of thing I could try to solve this problem.
I suspect that even though the setup is for X86, the project itself is AnyCPU and thus runs as a 64bit process on 64bit systems and as a 32bit process on 32bit systems. As you said your DLL is in the Program Files (x86) folder I assume it is 32bit only, so you should compile your application explicitly as x86, too. It is your bullet #7 that leads me to this conclusion.
Just copying the nianlys.dll 64bit DLL doesn't seem to work as it seems to rely on other DLLs it then can't find. (bullet #8).
It may caused by the dependents of nianlys.dll are not found. You can diagnose this problem with the process monitor , one of the system internal tools. It can capture the loading/unloading DLL activities, so if something wrong, you can find it in the log.
Be sure to use the filter when use this tool, otherwise the log file will be huge.
Could not load file or assembly 'NCrawler.GeckoProcessor,
Version=3.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its
dependencies.
When I call CrawlUsingGeckoProcessor.Run();
What does this mean? I can click "go to definition" and I can see the Run() method.
This error usually means that the assembly was not found.
Try verifying that the file exists in the directory where your application is running.
If you still can't figure out which file fails loading, try using a tool such as Fusion Log Viewer (run fuslogvw.exe from the Visual Studio command prompt), to determine which files the CLR was trying to load and from where, so that you can see exactly what failed.
I experienced the same problem, and the reason was that I compiled my EXE and DLL on 32 bit machine for "x86", because it depends on C++\CLI library compiled for Win32. Then I tried to use this library on 64 bit machine from 64 bit process. Obviously 64 bit process can't load 32 bit libraries, so I got this error, which does not really help to understand the problem.
So the reason could be that you try to use 32 bit library from 64 bit process.
Building over nogard answer, try setting the Solution Platform to x86
try going to app advance settings .. Enable 32 bit processing ..
if the app was built in .net 2.0 and current server is IIS 7
I have a console application which works perfectly in 32 bit machine. But I'm having problem running the executable in 64 bit windows server. The error message I get is:
The type initializer for "Sybase.Data.AseClient1.AseConnection" threw an exception. System.BadImageFormatException. An attempt was made to load a program with incorrect format. at Sybase.Data.AseClient.Unmanaged.AseGetDriverVersion at Sybase.Data.Aseclient1.AseConnection.CheckVersion().
Has anyone seen this error?
Update: After compiling in X86, I get:
Major version mismatch sybdrvado20.dll. Expecting major version '2'. Loaded version 1 at Sybase.Data.AseClient1.AseConnection.CheckVerison.
Please note that the server has latest Sybase version.
Even easier, download the x64 version http://www.sybase.com/detail?id=1051287&elq=00000000000000000000000000000000
I had similar problems, because the driver is 32 bit. so try to build your application for x86. You can do this in your project properties.
Regarding the error "Major version mismatch sybdrvado20.dll...", what solved for me was replacing the old version of sybdrvado20.dll that was in the bin folder of my application (located in the server) for the new one, located in C:\Sybase\DataAccess\ADONET\dll or C:\Sybase\DataAccess64\ADONET\dll.
To check the version of the dll, right-click the file, go to Properties and click in the tab Details.