I'm trying to run an exe which calls Microsoft.ACE.oledb.12.0 but get the error "Provider not registered on local machine". There has been quite a lot about this error on Stackoverflow. Recommendations to correct this are to install AccessDatabaeEngine and compiling in x86. I've done both and although the path in project is set to x86 I suspect it is still compiling to 64 bit as VS continues to place the exe in that 64 bit folder. But I 'm at a lost as to how to correct this. Any one know how to fix this or confirm if the exe is 32 or 64 bit regardless of which folder it is placed in. Running vs2012 on windows 2012 server 64bit (Hyper-v)
regards
Erick
ok...so this is what happened. I changed the cpu type to x86 on the project properties. Which did compile to 32bit but placed it in the incorrect folder. I confirmed this by opening the exe in notepad as there is a way to tell what type it is.
However, the debug version remained at 64 bit. The fix is to use the drop down list on the toolbar which says "Release" or "Debug" and set it to Configuration manager. In there set both the release and debug values to x86. This compiles it to x86 and puts it in the correct folder. I don't know how this is different but it now happily uses the 32 bit dll.
Related
So I built a huge website for my company using the AnyCpu option. I didn't think it would matter - I have a 64bit machine with x64 windows, it's getting deployed to a x64 server, and there's no attached dll's, so it should just all be in 64, right?
Well, in the process of trying to implement some security, the company's support told us the application MUST be strictly x64. I figured it was, but to humor them, I went into the configuration manager, and changed all the target cpu, platform etc settings to x64.
Unfortunately now, it breaks when I hit f5 to run it. I've run into this before, I think, and I vaguely remember needing to delete some temp internet files somewhere, but I tried closing VS, deleting the bin folder, deleting the root folder from /framework/tempASPfiles... but I still get the BadImageFormatException - "an attempt was made to load the program with an incorrect format."
What's the best and fastest way to convert an app to x64? and am I right in thinking I need to delete some files somewhere?
I have a WPF 4.0 application that I have compiled for x86. When running on 64bit Win7, I need to start up an on-screen keyboard, located in %windows%/System32/osk.exe. Problem is I can't do it- I get an error 'Could not start On-Screen Keyboard'.
I found this thread:
Unable to launch onscreen keyboard (osk.exe) from a 32-bit process on Win7 x64 which sounds exactly like my problem.
I used all the relevant bits from that post, but the error persists. And even worse, I managed to get a 32 bit version of osk.exe and when I try to start THAT I just get a blank error box- no message at all, just a red 'X'.
So I can't compile my app for AnyCPU (3rd party interop libs), and have read that that might not solve the issue anyways. I have also read that one workaround is to disable virtualization using Wow64DisableWow64FsRedirection, but that this is unsafe. Seems like a lot of effort just to run a little app :(
What can I do to launch this little thing from my app?
Wrapping the offending app in a exe compiled with AnyCPU works fine and seems to be the least painful approach.
When I compile my SharePoint 2007 solution on a 64-bit machine in Release mode and the platform set to AnyCPU or x86 I get the following error:
An attempt was made to load an assembly with an incorrect format: C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\ISAPI\Microsoft.Office.Server.Search.dll.
When I use .Net Reflector on Microsoft.Office.Server.Search.dll it says the platform is set to x64. So I change my settings to Release mode and the platform to x64 and get the same error.
The strange thing is when I change Release to debug, It complies. Can anyone explain this?
I would prefer compiling with the settings Release/AnyCPU if its possible. Can anyone give me a push in the right direction?
Thanks
p.s. I also asked the question here: http://social.msdn.microsoft.com/Forums/en-US/netfx64bit/thread/21d14405-ca6f-4503-b416-f56bfb27168b/
I too have experienced this same issue, for me it seemed that my changes to the build configuration weren't actually taking. After several attempts at saving, reopening project, choosing build/rebuild, I was able to get it functioning after choosing "Clean" from the build options.
Does a System.Runtime.InteropServices.COMException of 0x80040154 always mean that the class isn't registered? I'm getting a COMException which says "Retrieving the COM class factory for component with CLSID {29131539-2EED-1069-BF5D-00DD011186B7} failed due to the following error: 80040154." It's trying to load Interop.Domino.dll which is a reference I got from the COM tab of Add Reference called "Lotus Domino Objects" which points to domobj.tlb in the Notes program folder.
I wrote the code years ago - it's the only thing I've ever done with interop and it's fair to say that I never really got to grips with it.
I'm seeing this error again after moving the code to a 2008 R2 server (so it's x64). It was written on XP and run on 2003 (both x86). In order to diagnose the problem, I built a Win7 x86 (because there's no R2 x86) box and it worked. I also built a 2003 x64 box and it fails with the same error, so it looks like it's caused by moving to x64 architecture. Is there something I should do when doing interop to get x86 COM DLLs to work on x64 machines?
I had the same problem trying to build and run a .NET application on Windows 7 x64 that called interop.domino.dll, which is 32 bit only.
To resolve, I recompiled the .NET application to run specifically as x86 when run on x64 operating systems.
I was using Visual Studio 2010 Express Edition which is trickier to target specifically for x86 platforms than the paid for versions.
The solution was:
Click TOOLS > OPTIONS > PROJECTS AND SOLUTIONS
Check the box "Show advanced build configurations" and click OK
Click TOOLS > SETTINGS > check EXPERT SETTINGS to see the build configuration manager
Click BUILD > CONFIGURATION MANAGER select the platform dropdown to X86 and click CLOSE
Now rebuild the project
Pay attention to register of 32-bit components using the correct register (C:\Windows\SysWOW64\regsvr32.exe).
If you have already registered up with the 64-bit version, unregister each dll with the same version.
More help you find here Team is Going from XP32 to XP64 for .NET Development - Any Gotchas?
Good luck
There's an IBM technote that indicates that the Domino COM classes are not supported on a 64-bit OS. See https://www-304.ibm.com/support/docview.wss?uid=swg21454291 So it seems like even by compiling the code to run as x86 (as per mpownie's answer), you're still taking some chances.
I'm moved from Windows to Ubuntu Linux, and now I want to set up development environment here. The problem is that I need
C/C++ IDE comparable to Visual Studio
Way to generate Windows PE binaries
Way do debug Windows PE binaries
At first time I tried Code::Blocks. Here I find guide to setting it up for cross-development so I managed to get "Hello World" compiled and running under Wine. Moreover, debugging worked too.
But then I found that Eclipse + CDT plugin is far more advanced IDE. I spent some time and finally get project compiled and linked.
Now I'm trying to get MinGW Insight version of GDB working within Eclipse CDT. Simple way to use debugger described in Code::Blocks guide won't work anymore. I continue to receive "Error creating session" messages.
So my question is, how I can use MinGW GDB under Wine as debugger back-end in Eclipse?
Or, what is best IDE for Linux->Windows cross-development?
I'm wondering that nobody answered this yet.
QtCreator. Don't be confused by its name, QtCreator works is pretty well with any kind of C++ code, you don't need to code in Qt to use it. It is just like FOSS Visual Studio: it does even have a syntax checking "on fly".
MinGW. Here's not much to say, it is just creates Win PE executables, and it works. It is available in repositories. Note, that a Win GUI applications have special bit in it's PE header set; so, in order to create GUI application with MinGW you have to pass an option -mwindows to set this bit.
This is a problem. Really: I'm just trying to debug a windows application, and didn't find yet a way to do it. I will shortly recall here what I tried so far, just in order for you to not step on my rakes:
winedbg. Probably it should work, but for me it didn't. When I set a breakpoint, i.e. like this br 43, it says Unable to add breakpoint (unknown address 7b860807).
winedbg. Yeah, again, but this time we will use it like this winedbg --gbd to make it proxying a commands to gdb. Probably this is the only way to debug an application, but it have a drawbacks: first, in order to restart an application you have to exit debugger; if you enter run it says that the remote target doesn't support this. Second, I have no even idea how to debug a multithreaded application; when I first started this, I stumbled upon an error Non-stop mode requested, but remote does not support non-stop, and after setting a breakpoint and starting it says:
Cannot insert breakpoint 1. and Cannot access memory at address 0x401654. So, in order to make this work I was needed to rename my .gdbinit file (i.e. non-stop mode is set there).
gdb.exe. I was sure that I found a way: simple usage of a windows version of gdb should solve problems; more over, for me, as I am a Emacs guy, it would be absolutely the same as debugging with native gdb. But alas, the windows gdb just didn't work. If I run it, and enter any command, it simply does nothing. It only reacts on Ctrl-c and Ctrl-z commands. Probably I will try on my spare time to ask a question about it on mailing list. Well, now we can't use it...
So what we have do with debug? Most probably seek another Windows debugger that works under WINE. If I correctly recall, OllyDbg worked, but I don't know at the moment how to make it show a source code.
you can try NetBeans.It's a good free, open source
and Cross Platform Support IDE.
Run Windows in a VM?
Seriously, your question is good, but it's probably not worth spending the time to figure out the answer (especially: since nobody seems to have a ready answer). If you have real work to do, native Windows or Windows in a VM is the answer.