I am working on a Visual Studio 2010 c++ project where i have 2 DLL with same name but different version. one is build on VS 2010 and another is on VS 2017. Requirement is there is a number of projects link together and placed there binary on a single folder along with statically linked DLL's. i have to put 2017 DLL on this folder and created a folder here where i put 2010 DLL and its path is set on environment variable, among these projects only 1 project is required to use 2010 version DLL, i read on internet its possible if add DLL in these project's manifest file but not get much info how to achieve it is it possible by manifest or any other way. can anybody please help me to get rid out of that.
Related
So I am working on an example project that displays video from a network stream.
The project is in C++.
After building the project in release, and trying to run the project on a different computer, I get errors on missing DLL files.
These DLL files are located within the installation location of Visual studio.
one example is msvcp140d.dll.
After copying all the missing files, I get a generic error with no specific file.
So:
Is there a way to tell visual studio to add all relevant files when building the project?
Summary: I am using Visual Studio 2019, and trying to create an example that links a plain-old-C++ project to a C++/CLR project that targets .NET 5.0. The solution compiles and builds, but attempting to run it produces an error message saying "not a valid Win32 application."
Question: How can I produce an executable that will actually run?
Steps to reproduce:
Using Visual Studio 2019, create a new solution. Set the configuration to Debug and x86.
Create a new project that is a C++ desktop application, using the C++ Windows Desktop Wizard project template with default options. Name it Interop5Test, and verify that it builds and runs.
Create a new project that is a C++/CLR project targeting .NET 5.0, using the C++ CLR Class Library (.NET Core) template, and name it CppShim5.
Modify the properties and source files of CppShim5 to remove the use of precompiled headers. (I did so to match the requirements of my intended use case.) Verify that the solution still builds and runs.
In the project properties for Interop5Test:
modify Linker | Input | AdditionalDependencies by adding ../CppShim5/$(Configuration)/CppShim5.obj
modify Linker | General | AdditionalLibraryDirectories by adding
C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Host.win-x86\5.0.3\runtimes\win-x86\native
(or wherever ijwhost.lib can be found on your machine).
Build the solution, which should succeed.
Press Local Windows Debugger in Visual Studio to start the executable, and observe a popup window that says "Unable to start program ... not a valid Win32 application."
Browse to the Debug folder of the solution, and observe that Interop5.exe, CppShim5.dll, ijwhost.dll, and CppShim5.runtimeconfig.json are all present.
Use ildasm to examine Interop5.exe and CppShim5.dll, and observe that they are 32-bit portable executables with COFF Header | Machine value of 0x14c which means "Intel 386 or later processors and compatible processors."
Open ijwhost.dll with Visual Studio and observe a reasonable looking Version resource. Perform a binary comparison of ijwhost.dll with the one in the additional library directory of step 5, and observe that the files match perfectly.
Examine the contents of CppShim5.runtimeconfig.json and see something that looks reasonable.
I discovered that I can get a valid executable if I link to CppShim5.lib instead of CppShim5.obj.
Details for how to alter the example in the original question:
Add a class to CppShim5 and mark it as exported from the DLL (by using __declspec(dllexport), see also: https://learn.microsoft.com/en-us/cpp/build/exporting-from-a-dll-using-declspec-dllexport?view=msvc-160). This causes Visual Studio to generate CppShim5.obj and to put it in the Solution's Debug folder.
Edit the properties of Interop5Test, changing Linker | Input | AdditionalDependencies from: ../CppShim5/$(Configuration)/CppShim5.obj to: ../$(Configuration)/CppShim5.lib
In Visual Studio, add to project Interop5Test a dependency on project CppShim5.
With these changes, build the solution. It should now execute.
I want to build a single standalone executable file for a windows console application built in Visual Studio 2019. By standalone, I mean that I want a single exe file that I can move to any location on any computer and it will still run without extra files surrounding it (no dependencies).
For the life of me, I can't find a clear answer anywhere.
Question 1: Is the visual studio "release" executable file standalone?
Question 2: How do I make a standalone exe file that will run anywhere, no matter what libraries my code depends on?
Question 3: Can this be done inside visual studio, or do I need other software to do it?
You could use Microsoft Visual Studio Installer to deploy a Visual C++ Application.
For third-party libraries, you could select static linking version. If there is no static link version and only dll, copy the corresponding dll together when publishing.
For the c++ runtime library, select the static compilation method: Properties->C/C++->Code Generation->Runtime Library->Multi-threaded (/MT).
Also, you could use depends.exe (a Microsoft small tool) to view the dll, and then package it together.
I migrated a visual C++ solution containing 70+ projects to VS2013 Update 5 from VS2008 SP1. The VS2008 SP1 was using merge modules and in VS2013 I am using this plugin to achieve this functionality. However, the merge module is not detecting external dependencies of the dlls I am building. For example, one of the dll is dependent on ace.dll (and specifies ace.lib in linker->input) but that dependency is not detected. In VS2008, the same dependency was detected. Any idea what could be wrong or where to look for?
I'm surprised that it previously detected that dependency in the VS 2008 setup project. To my knowledge, there is no link between the VS 2008 development project that you might be using to build your code and the dependencies in the setup project.
a) You can drag and drop files from anywhere into your setup project. There's no requirement that a VS setup project generate an MSI file from the files in your VS 2008 project.
b) A dependency on a particular Dll cannot result in that Dll being included in the setup because a huge number of dependent Dlls are included in separate redistributables. These Dlls might even be in the prerequisites of the setup project and that's how they get installed. You don't want (for example) every Crystal Reports Dll, SQL Dll etc in your MSI setup because they are required to be installed via redistributables or their own merge modules. There is no grand database of every Dll and which redistributable or merge module should be used to deploy it, so VS projects certainly don't know.
c) Not all dependencies can be detected by looking at the binary file. COM dependencies are not listed anywhere in a binary because they're linked dynamically via guids, so they can never be detected that way.
In general the bad news is that the developer needs to know which dependencies need to be installed individually, which come in redist setups, and which are standad Dlls, such as those that are part of the OS and never need installing.
We recently converted a C++ project from Visual Studio 6 to Visual Studio 8. Everything went well until we reached the compilation of a project who put all the static libraries inside one big static library. By default after the conversion between the two version of projects the project didn't do anything (no big static library was created, it only said that the project was up-to-date).
We found a working solution by adding a dummy (empty) file to the project (it had no other files before, in the Visual Studio 6 solution). Everything went well and we managed to compile the project with the new development environment (Visual Studio 8).
My question is: Is there any other way to do this, without dummy files added to the project?
Thanks in advance for your responses
You can use the method described in the answer by nobugz also with multiple configurations and different directories for debug and release input libs. Just add all input libs, debug and release, and use "exclude from build". In the debug configuration exclude all release input libs from the build, in the release configuration exclude all debug input libs.