I have a .Net project built in VS2010 compiling against .Net 4 that uses an older 32 bit dll. The project will be deployed to a Windows 2008 64 bit server where the dll used is registered in SYSWOW64 and is being used by other legacy programs. I had an issue with it that was solved by changing the platform target to X86 on the build tab in the project properties. Initially, I compiled the project and the dll in question is copied to the bin folder. To test, I copied the release folder to the server desktop and the program runs fine. However, if I set the copy local to false the dll is not included in bin - as expected, but the program no longer runs on the server. The development environment is XP service pack 3.
Why can't the program find and use the registered copy of the dll in SYSWOW64?
Related
I have built a program using Visual studio 2013 in visual basic. I am using a set of DLLs to communicate to some external hardware. The computer I developed the software on is a Win7 64bit machine and I can compile and run the software with no hiccups on it. I also have another computer (Surface Pro 3 64bit) that I use to test my software on and that works as well. Basically I just locate the debug directory of the development computer and copy the EXE and support DLLs to the new computer and run the EXE. This all works with my surface pro 3 computer.
My company purchased some other surface pro 3 computers for our production department and I am trying to get the software running on those as well. I do the same thing. Grab the EXE and support DLLs from the debug directory of the development computer. Except on these computers when I run the software program it tells me it can't find the DLL for the program. The DLL is sitting right in the application's folder, yet it says it can't find it.
I have tried multiple things, like publishing the software and including the DLLs in the installation, then running the installation on the "problem" computers. This still doesn't work. Same issue, it can't find the DLL.
This could be a number of things:
Incorrect version of .NET - do the new computers have the target version of .NET installed on them?
A required DLL is not being found, you should enable assembly bind failure logging and try again - How to enable assembly bind failure logging (Fusion) in .NET
So it turns out that the DLL I was referencing requires the VC++ redistributable packages to be installed on the computer. I downloaded and installed these on all of the problem computers and now the software recognizes the DLL and run.
I'm working with a native C++/Win32/MFC application built using Visual Studio 2010 Pro on Windows 7 x64. The application is linked with some other DLLs using their .lib files.
I'd like to be able to run this application and have it find the DLLs in their respective directories without 1) having to put the DLLs in the application directory or 2) add the DLL directories to the PATH or 3) resort to dynamically loading the DLLs and having to lookup stuff at runtime.
Is this even possible? Is there some way to direct the OS loader to go find the DLLs in an arbitrary location I specify without having to add that to the PATH?
Basics:
In Visual Studio project settings, keep everything default specially in Release configuration.
Ensure that you give Release build to the client (Where VS wouldn't have been installed).
If client OS is 32-bit, you must give 32-bit. Otherwise you can give 64-bit (Release build in any case).
Now comes distribution and VC++ runtime library.
You must install appropriate Visual C++ Runtime on client's machine,
ensuring that:
The version should match (VC7, VC8,.. VC14 etc.)
The bit-ness should match. If your application is 32-bit, you need 32-bit
redistributable, and same for x64.
The service pack version must also
match!
It should be noted that all of them can co-exist! VC10 RTM, VC10 SP2, VC10 x64 RTM.. all can co-exist
We are developing a DLL, which calls generic WinUsb functions from WinDDK. This DLL needs to work in 32-bit and 64-bit versions of Windows, including xp, vista, win7, and possibly win8.
My question is, how can we manage the Visual Studio 2010 solution by targeting all these platforms? WinDDK libraries are different for each OS, so if I reference a library from the code:
#### #pragma comment (lib , "C:\\WinDDK\\7600.16385.1\\lib\\wlh\\i386\\winmm.lib" )
Or by referencing the library from the project options->includes section, this project only becomes correct for a particular target architecture. (In this example, Vista 32-bits, since I am including 'wlh').
Are we supposed to create a different project for each different OS target?
The WDK/DDK version does not constrain the OS version for which you build. You can pass the target OS as a build environment/compile parameter.
I think you should build DLL through DDK and use that in your VS project.
You can write pre-build event for your VS project to run a batch file which will build the DLL and put it in some well-known place for the project.
Also, you may have to create different project configurations for each platform you want to build for (at least different for 32-bit and 64-bit) and run appropriate build command for DLL.
I have a Windows .net solution that is deployed with a Visual Studio Deployment project.
My exe is a win32 app that runs fine on either a x86 or x64 windows.
However I included a merge module (*.msm) from a third party vendor which is available in a x86 and x64 version.
Now I could copy my whole deploy project and just change the msm, but I'm a lazy guy and the best thing would be to include both msm's in my installer and only install the module which fits the processor of the client machine.
Is there a way to do this with Visual Deployment projects?
Merge Modules seem to lack a Condition property like included exe / dll files have.
I have installation solution that have installer project (not web installer but simple installer) that installs NT services, web service and web sites with help of additional two projects of dlls with my own code that performs my installation step. In user actions of installer project I call installer function of one of those projects, and this project calls to installer of second project: installer -> MiddleCaller -> InstallationCore.
All this developing on Windows 7 and work fine when I compile all in 32 bit.
The project must run on Windows 2008. Because of some reasons all must be in x64 bit.
For this purpose, in MiddleCaller and InstallationCore I click right button of mouse on project -> build -> targer x64. For to move installer project to 64 bit in properties of installer (when project is active) I check: Target platform: x64.
When I run installation on x86 I get error:
The installation package is not supported by this processor type"
And this is good, because now I know that my installation compiled in 64 bit, but when I run this on windows 2008 I get:
Error 1001. Exception occured while initializing the instance:
System.BadImageFormatException: could not load file or Assembly
'MiddleCaller, v...' or one of its dependencies. An attempt was
made to load a program with an incorrect format.
Any one has some idea what I need to do for run fine the installation on x64?
May be I still not moved the installer project to x64 bit, if yes, where I do this?
Thank you for ahead.
Found a quick tip on Microsoft's website that could be useful on troubleshooting setup and deployment projects:
64-bit managed custom actions throw a System.BadImageFormatException exception
If you add a 64-bit managed custom action to a Setup project, the Visual Studio build process embeds a 32-bit version of InstallUtilLib.dll into the MSI as InstallUtil. In turn, the 32-bit .NET Framework is loaded to run the 64-bit managed custom action and causes a BadImageFormatException exception.
For the workaround, replace the 32-bit InstallUtilLib.dll with the 64-bit version.
Open the resulting .msi in Orca from the Windows Installer SDK.
Select the Binary table.
Double click the cell [Binary Data] for the record InstallUtil.
Make sure "Read binary from filename" is selected and click the Browse button.
Browse to %WINDIR%\Microsoft.NET\Framework64\v2.0.50727.
Note
The Framework64 directory is only installed on 64-bit platforms and corresponds to the 64-bit processor type.
Select InstallUtilLib.dll.
Click the Open button.
Click the OK button.
There are some unclear things in this scenario. I understand that you are having difficulty running a 32-bit installer that calls on 64-bit assemblies. If this is correct, then what you are doing is not allowed. You cannot have 32-bit and 64-bit assemblies in the same process - that is illegal. If the 64-bit assemblies are being referenced by the installer directly, then the installer must also be 64-bit.
As clarification: I believe a 32-bit installer can install a 64-bit application, but it may only do so by copying the 64-bit files and not by actually making calls into the 64-bit files. The only way this is supported is if the 64-bit files are loaded into a different process and you use IPC to call into them, but even this is likely to be a bad solution.
In your case, I would encourage you to convert your installer into a 64-bit installer.
So, eventually, I compiled MiddleCaller and InstallationCore in AnyCpu mode, when all dll and executables that I need to install were compiled in x64 bit. All this I compiled on Windows 2008 x64 bit with x64 bit outer dependencies (like Oracle client).