We have a c# executable that loads a 32bit dll written in C++ which dynamically loads another 32bit dll (the first dll is a wrapper).
When this is built on a 32bit machine (with VS toolset v100) it all works correctly.
When it is built on a 64bit machine (with VS toolset v110) it runs on some machines, but on others it gets a FileNotFoundException on the wrapper dll. It works on some 64bit machines, fails on some and fails on at least one 32bit machine.
The failure happens in Assembly.LoadFrom, where the location comes from Assembly.GetExecutingAssembly().Location. The dll is in the same dir as the exe, which was build as x86.
If build on a 64bit machine to get a failing version, then I drop in a version of the wrapper dll built on a 32bit machine, it works properly (so it's not really a file not found problem, but rather a 'correct' file not found one).
Any ideas why this is failing? Is it the build machine, or the toolset? Or something else? Is there something I can set in the build to get it working properly (I'd like to continue building on a 64bit box)?
Do you have all dependency dlls installed on the client machines? Like VC Runtime, other libraries you depend on?
Related
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.
I am trying to run this project in my VisualStudio 2010.
it build and run fine on my 64 bit Machine.
NOTE:I have to change build Platform of my project to x86.
my problem is when I try to run compiled assembly (after moving Debug Folder to another 64 Bit machine) I couldn't run my project. my exe breaks down when I open it.
as per my understanding problem is because of three DLL used in project are 32 BIT and Machine is 64Bit.
NOTE: below is three DLL
Interop.Office.dll
Interop.VBIDE.dll
Interop.Word.dll
I googled much but couldn't found any solution?
one solution comes in my mind is manage to get 64BIT version of above DLL for that also I have googled much but couldn't get anything.
could you please help me to find solution for this problem? or is there any way to found 64BIT version of above DLL?
If you have to use 32 bit dlls, probably you cannot run your application, compiled on 64 bits.
So you need to compile all your project (as you did for debug) in the 32 bits mode before release to another pc.
You can ensure your dlls compiled right (32 bits only), using Microsoft CorFlags.exe utility.
If you'll find that dll is not 32bits, you can also try to change it with same utility (/32BITS falg).
More information:
The default version of Office is 32 bit version.
To get 64 bit versions of the assemblies you need to specifically install 64 bit office (see here.)
The 64 bit version of Office should be able to use your 32 bit program (using WoW)
but it's best if you create (and test) two versions of it: one for 32 bit and one for 64 bit.
Unfortunately this means two development environments as the 32 bit Office cannot be installed along side the 64 bit one.
Are you positive that the office interOps are the problem?
What is the error message you are receiving? You have stated that you are compiling with x86 platform build mode. Therefore your dlls will run as 32 bit processes even on the other 64bit machine and will therefore call the 32bit office dlls.
If you had of compiled as AnyCPU then I could see how the error you are getting relates to office dll bitness, because your application would start in 64bit (on a 64bit machine) and then attempt to call into the 32bit office dlls.
But I fail to understand how you're finding that the 32bit dlls are the problem on any 32 or 64bit machine since you are compiling to 32bit (x86). So your assembly manifest is telling the JIT compiler, "hey Im a 32bit process".
Remember, ngen aside, the bitness of your code isn't determined till it's run. Post compilation the code is just IL waiting to be compiled and it's the same IL regardless of whether you had a build platform of x86 or x64 or AnyCPU.
When it's run the runtime looks at the manifest and compiles it to the platform of choice... which in this case is x86... from what you have said.
So the problem is not that:
three DLL used in project are 32 BIT and Machine is 64Bit.
32bit dlls are used all over the place on 64bit machines. Visual Studio itself is a 32bit application and runs just fine on 64bit machine. The problem (IMHO) is either
Not the office dlls at all but something else... Office is installed on the other machine I assume.
You've accidentally changed the target platform of the last build you did before deploying to something other than x86.
I am developing a 32bit WinForm app (target: .NET 3.5). My client insists the app be installed into "Windows\System32\clientname" folder and autostarts on startup. Also, the app must be 32bit, so I can't use "Any CPU".
I am developing under Win7 x64 with VS2010 and all versions of .NET are installed. When I start the app I get the message "Unable to find a version of runtime to run this application".
On Win7 x86 it works without problem. It's not the app itself and I am 100% sure all the required frameworks are installed.
I know that on a x64 system this folder is not to be used for 32bit apps but as I said: client insists and won't budge.
Before I tell client definitively that it can't be done I want to explore all options. I googled of course and also searched this fine site but nothing helpful for my particular situation came up.
My app spawns another 32bit process located in the same folder. On x64 that didn't work either, of course, but I solved that by using "Wow64DisableWow64FsRedirection" and then copying it to another location to start it from there (which works fine).
I have done my homework but I just can't find a solution for starting the main app under x64 and in that particular folder.
Is there one?
In an attempt to solve this problem I created two folders on my Win7 x64 machine:
C:\Windows\System32\ClientName; and
C:\Windows\SysWOW64\ClientName
Next I created a simple x86 WinForms application targeting .NET 3.5. I found that if I copied the executable to C:\Windows\System32\ClientName I got exactly the same error message as you reported.
However, if I copied the executable to both directories, then I could start it from C:\Windows\System32\ClientName, and it worked just fine.
I did not try this, but I suspect that if you have a multi-assembly application, you only need to copy the *.exe file to C:\Windows\System32\ClientName. All of the other files (and the EXE) would then reside in the C:\Windows\SysWOW64\ClientName directory.
This is a bit of an untidy solution, I know, but then again your client's requirement is a bit unusual to start with.
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.
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.