I have a .NET project that's always been built/run by/on 32 bit machines. I got a new a 64 bit computer and am trying to tackle the task of getting it working there. The build script is in nant, and at one point we compile some boo code using the nant task. The boo code references our core DLL, which is built from c# source earlier in the build process.
I've tried two things: build it to run in 32bit mode and build it to run in 64bit mode. By using corflags on several programs (including booc), I was able to build the project built in 32bit mode, but ended up with a bunch of downstream issues at runtime. So I need to get it built in 64bit mode, which I think is preferable anyway.
According to the nant/booc source code, the booc nant task calls the booc.exe in-process using the CLR's Process class, so (I think) it should inherit 32bitness or 64bitness from the parent process. That doesn't reflect what I'm seeing, though.
Here's what I've done:
Used the 64bit version of powershell to invoke nant
Specified platform="x64" on my tasks. I feel like I shouldn't have to do this because anycpu should be fine, but it seems to make a difference.
Here's the error I'm getting:
[booc] Compiling 5 files to 'C:\dev\build\MyProjectBoo.dll'.
[booc] BCE0106: Failed to access the types defined in assembly 'MyProject, Version=5.5.0.0, Culture=neutral, PublicKeyToken=null' - (C:\dev\build\MyProject.dll):Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information.
[booc] is not a valid Win32 application. (Exception from HRESULT: 0x800700C1)
[booc] is not a valid Win32 application. (Exception from HRESULT: 0x800700C1)
[booc] .
[booc] 1 error(s).
Which means, according to the booc source code, "I tried to reflectively list the types in your referenced assembly but failed". I don't know if that means, "I think I'm 32bit but these are 64bit dlls" or what, and I'm very confused.
Any ideas on how I can get this to work?
Update after some work, I've discovered that the issue has nothing to do with boo. I wrote a quick c# program that reflectively loads the dll and it breaks in the same way. So for some reason, no matter what I set as the platform (x86, x64 or anycpu), I can't load it reflectively on an x64 machine. So not really boo's fault. So I'm going to dig into this and repost if I have a better question.
Newer Update
Turns out that one of my main DLL's third party dependencies insists on being in a 32 bit environment, even though it isn't built with corflags. This causes assembly.GetTypes() fail in 64 bit mode.
The problem is dependencies on third-party DLL's that require 32 bit mode, which is possible even if they don't have corflags set.
Related
I have a simulink model (2016b with MC 2013 C/C++ and Mingw-64 compilers) that I'd like to generate a standalone executable for windows-64 bit.
I was able to run the grt executable but due to the fact that I need to read a mat file runtime as opposed to compile time, I am using rsim code generation for this purpose, however the executable that gets generated appears to need quite a bit of .dll, I provided the dll it was asking for however, the application still unable to run. This is the error that results
The application was unable to start correctly 0xc000007b. Click OK to
close the application
What am I missing ?
Your main program is compiled for x64 (64-bit) target, but the dll you provided is compiled for x86 (32-bit) target. Or vice versa.
If it is Mingw-64 stuff, you should be able to obtain all (or most) of them by using the official online installer. Link is here.
I'm trying to learn the basics of dll injection, so I created a really simple hello-world type DLL and an injector based off of code I found online. I wasn't able to find anything that works out of the box, so I had to make a few adjustments.
Injection Code, DLL Code
I'm running these on 64-bit windows. I'm compiling with Visual Studio 2010. The injector is a win32 console app, and the dll is win32 as well. I'm trying to inject my code into an existing notepad process (also 32-bit). All of this is running on Windows 7 x64.
When I run the injector, it fails every time at CreateRemoteThread, with GetLastError returning 5 (i.e. ERROR_ACCESS_DENIED). I've confirmed that the dll path is correct (although changing it to a bogus path gives the same behavior), and I've confirmed that the path is getting written to notepad's memory at the correct address using Cheat Engine. I'm having a difficult time with this because I'm not sure how to debug the problem further.
What could be causing CreateRemoteThread to fail?
The problem is that notepad.exe is a 64-bit process in 64-bit windows, and I was trying to inject with a 32-bit process.
I also come up with the same problem. My situation is this:
My system is 64-bit and the notepad is also 64-bit.
But the injector is the 32-bit process.
My solution is to replace the 64-bit notepad with the 32-bit notepad in the system directory.
I am currently writing a PowerShell snapin that has specific dependencies on mixed-mode assemblies (assemblies containing native code) that specifically target x64 or x86. I have both versions of the dependent assembly, but I am wondering how best to manage the build and deployment of this snapin, specifically:
Is it necessary to have two versions of the snapin, one x86 and one x64, and use the two different versions of installutil to install it, once for each architecture?
Assuming #1 is true, is it recommended to install the two different versions of the snapin in the different "Program Files" and "Program Files (x86)" directories?
What is the ideal (least hassle) way to structure a pair of projects that share everything but a single reference, in order to build for the two different architectures?
If the snapin is compiled as "AnyCpu", and the dependent dlls are both loaded into the GAC, will the runtime load the correct assembly from the GAC based on the architecture of the currently running PowerShell host?
Is there a slick way to dynamically, at run-time, choose which dependent dll to load (if it cannot, for various reasons, be installed in the GAC) without running into headaches with assembly load contexts?
Mark, we have this very situation with the PowerShell Community Extensions with 32-bit and 64-bit versions of 7zip.dll. You can pretty easily work around this by PInvoking to LoadLibrary early in your snapin startup (or before you need to call out to the native DLL). You can then test if you're a 32-bit or 64-bit process (IntPtr.Size) and then load manually the correct DLL using the LoadLibrary PInvoke. After that the, DllImport("YourNative.dll") will notice that the dll is already loaded and use that DLL.
Take a look at these two PSCX source code files:
http://pscx.codeplex.com/SourceControl/changeset/view/74794?ProjectName=Pscx#1358100
http://pscx.codeplex.com/SourceControl/changeset/view/74794?ProjectName=Pscx#1358102
I ended up creating a module (thanks, Richard!), but that didn't solve the problems related to processor architecture. In order to solve that, I put both versions of the dependent dll in the module directory, and in each cmdlet's constructor I put some initialization code (that only runs once) to load the appropriate version of the dependent dll.
Thanks, all, for the pointers.
I have a 3rd party application that doesn't come with an installer. It's a very small exe, a simulator.
Anyhow, it crashes on startup due to some missing libraries. But the error doesn't tell me which ones. Is there an application on windows that tells me which libraries are going to be loaded at program load time?
It's been a few years since i've used it but Dependency Walker got me through a lot of DLL hell.
Also, Process Explorer is a great and fast way to see what DLLs are loaded by an EXE on a test machine... for comparison purposes when hunting down missing DLLs.
Only a partial answer: DEPENDS.EXE tells you what dlls a dll needs. I think it works for EXE's too.
Do PowerShell scripts run under Mono?
I would like to run them on a Mac.
There is an open source version of PowerShell called Pash designed for Mono. It is not complete, but may be able to do what you need:
http://pash.sourceforge.net/ (this project has not been active for quite some time)
Checkout the re-start at: Pash-Project on GitHub.
Powershell has now been open-sourced and is available here.
As of right now it is V6.0 alpha. I've been running it on OS X for a lot of file operations and it has been working very well.
Note that you may need to install .Net Core to get Powershell to behave properly. Also note that system.management.automation.runspaces works right out of the box (for runspacepools).
The powershell.exe stub is actually a native win32 program, not a managed assembly. It may be possible in the future to host the System.Management.Automation assembly in Mono, but I'm fairly sure it doesn't work at the moment.