This question may be asked so many times. I searched for the solution too much. I got a solution (although that didn't work) to replace some .dll files.
Actually I made an application in Windows 7 Ultimate 64 bit, Visual Studio 2010, target Framework 3.5 with MS Access 2007 Database (Platform target x86). Then I tried to run this application (.exe file) on another machine having Windows 7 Ultimate 32 bit. But the error appeared.
As I got solution to replace those 5 dll files in \Windows\SYSWOW64 folder, but cannot find this folder on 32 machine. Even though I replaced/copied those 5 dlls to System32 folder. But the same error.
I also installed framework 4.0 on the target machine. But the same error.
Now how to resolve this error? Thanks...
Syswow64 is a folder just for 64 bit versions of Windows, where it stores files for 32 bit programs. It shouldn't exist on 32 bit Windows.
Try compiling for 32 bit Windows, then running on the other computer.
Several problems makes this happen (in my case)...
Most important to check for the VIRUSES;
Application is compiled in x64 and running on x86 platform;
If any dll, compiled in x64 platform, added to the x86 application;
These are some of those problems gives the error.
You need to change system target. On menu Build -> Configuration Manager, you can change the platform to x86 instead of x64.
Related
I have developed a C# winform application using VS 2012 on a 64 bit machine, now I would like to deploy it on a 32 bit machine, but I get the error of the form "... is not a valid win32 application" whenever I try installing and running the exe file on the 32 bit machine. Please suggest me the best way to get around this situation. Thanks!
It sounds like the project was compiled specifically for x64.
Pure .NET projects can and should be compiled to "Any CPU" which means they will run on either x86 and x64. This is usually the default.
http://blogs.microsoft.co.il/sasha/2012/04/04/what-anycpu-really-means-as-of-net-45-and-visual-studio-11/
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 have two laptops.
1) BuildLaptop-> The laptop that I have coded the application. Windows 7 Ultimate 32-bit, Office 2007 for database
2)TestLaptop-> To test the application. Windows 7 ultimate 64 bit, Office 2007.
My application contains several dll files that built as AnyCPU and the application is also built as AnyCPU.
When I tried to test my application on TestLaptop it gave me an error:
Microsoft.ACE.OleDb.12.0 provider is not registered on your machine.
So I uninstalled Office from TestLapTop and installed the Office as on BuildLapTop.
Again same error. Then I tried to compile all dlls and also my application to x64. The application could not start. Then I tried to compile only application to x64 and dlls to anyCPU. The error occured again.
So help me how to get my application run on the TestLapTop?
You need to compile any project as /platform:x86 if it uses any 32-bit unmanaged resources (DLL's, etc).
I'm not sure based on your comment you may be experiencing this issue. If you have any Microsoft Office programs installed:
Word
Outlook
Excel
Powerpoint
Etc
If they are the 32 Bit Revision then you can't install a 64 Bit Access Database Engine it will give you the following exception:
This will force you to install the 32 Bit Revision onto your 64 Bit Machine. You may also require some additional configuration for the database in your ODBC Data Source through Administrative Tools.
Hopefully that clarifies at least your error you mentioned in comment. As for the compile, Sixlettervariables has a solution for that.
Hopefully that helps though.
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.