Background:
I have a program that links to a third party library. There are two versions of the library, so I have created two solutions that point to the same code. This may seem odd, but the code doesn't have to be different. Only the settings within the solution need to be different (i.e. library names are different and the CRT version is different).
SolutionA uses versionA of the third party library (uses CRT version 8.0).
SolutionB uses versionB of the third party library (uses CRT version 9.0).
Both SolutionA and SolutionB point to the same code.
I have set up a Macro in the Project Property Sheets that points to the correct version of the library. The library files are not located within the solution folders. This Macro allows the projects to build correctly.
In order to get the executable to run, I have to tell it where the third party libraries are located. In order to do this, I can go to Configuration Properties-> Debugging -> Environment and add the path to the libraries to the %PATH% environment variable.
Question:
This works fine but is limited to debug mode. How can I add to the %PATH% environment variable in release mode? Can this be done using Project Property Sheets?
Notes: When the program is deployed, a batch file sets up the environment before it runs. However, I would like to be able to run the release executable within Visual Studio to keep things consistent (it would be easier for other developers).
Someone will probably ask why I don't have the libraries in the solution folders or why I don't throw them in with the executable. I hesitant to do so because one version of the libraries takes up about 180 MB. I only need two versions right now, but that is sure to change.
You do not need to create separate solutions with separate properties. For one solution, you can create several configuration. Each configuration have its own compile parameters.
Right Click on your project -> Properties -> Configuration Manager -> New.
Regarding "This works fine but is limited to debug mode". Yes, you are setting parameters for Debug mode only. So this is normal it works in Debug mode only.
For you libraries, if they are static:
Properties -> Linker -> Input -> Additional Dependencies
Properties -> Linker -> General -> Additional Library Directories
The way we've gotten around this problem is to run visual studio itself using a batch file which sets up any environment variables (e.g., PATH) prior to the start of Visual Studio which inherits the environment. This allows for the environment settings to be temporary to the run of VS and inherited across all build configurations.
This works for Debug, Release, and any custom build configurations you may have.
Related
I'm working in VS 2019 on a C++ program in which I want to link into a bunch of 3rd party dlls, which are located in a folder separate from my executable. I don't want to copy all the dlls into the executable folder and have found the following solution.
Just like in the solution, I create a registry entry to define the keys with the information about the executable and the required path information to link to the DLLs:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\MyExe.exe
%Path2MyExe%\MyExe.exe (default key)
Path = %Path2DLLs%
The compilation from within VS works fine and when I start the generated executables from outside VS by (a) double clicking or (b) by using the command line, the 3rd party DLLs are found and the program is executed as expected.
However, when I invoke the debugger from within Visual Studio (c), execution is halted right away complaining that DLLs cannot be found.
I have checked the present working directory from within the code using _getcwd and for all options (a-c) it indicates the same directory.
So the question is: why does option (c) - debugging from within VS - not work?!
Cheers, Sebastian
It's probably because the executable that's launched when debugging is a vshost executable, not the generated executable for the project, and so it needs a separate entry in the registry.
If you want to stick with this kind of a build (highly not recommended), the easiest way to debug is to disable the hosting process:
Following the suggestion by drescherjm I tried to prepend the DLL directory to the PATH variable in "Configuration Properties -> Debugging -> Environment" following this solution.
However, this did not work for me. I also added the path directly in the system environment dialogue without success.
What did work in the end is setting the working directory under "Configuration Properties -> Debugging -> Working Directory" to point to the DLL folder. Now all three calling routes (a-c) work as expected.
Thanks to everyone for taking the time to help me out on this.
Sebastian
I've read multiple posts with regards to this topic, but none of them have enabled me to build a statically linked exe.
In my release configuration (x64) I have the following:
Configuration Properties -> General : Use of MFC - Use MFC in a Static Library
Configuration Properties -> C/C++ -> Code Generation : Runtime Library - Multi-threaded (/MT)
Configuration Properties -> Linker -> Command Line : Additional Options - I have all the required Windows libs "kernel32.lib", etc. (as use of MFC removed them from the "All Options" window above)
Configuration Properties -> Manifest Tool -> Input and Output : Embed Manifest - No
Note that in Configuration Properties -> Linker -> Input there are 5 lib files that I'm using in my project, eg glfw3.lib and I'm using Full optimisation (/Ox).
After building the project and running the exe myself I receive errors "The code execution cannot proceed because glfw3.dll was not found..." etc.
Using dependencywalker I can see that it needs the dlls associated with the libs, which it of course cannot find.
Am I misunderstanding how to do this or is there something else that might be wrong?
(I'm using Visual Studio 2017)
Yes, it appears you have a slight misunderstanding.
If something is offered as a DLL, then it is meant to be used as a DLL. There may be some way to incorporate a DLL into an executable, but it would be a hack. That's not how things are supposed to work.
The lib file that you are linking against exists simply in order to provide you with functions that you can link against, and these do nothing but delegate to the corresponding functions in the dynamically loaded DLL. Without it you would have to locate each entrypoint of the DLL yourself, which would be perfectly doable, but a bit cumbersome.
So: you must either find a version of glfw3 which is packaged as a statically linkable library (I have no idea whether one exists) or live with the fact that your .exe will need to be shipped together with glfw3.dll.
I am using VC++ with multiple projects that require a 3rd party library. As developers may have this library in different paths, each developer sets the local machine/user's Microsoft.Cpp.Win32.user property sheet with the appropriate paths.
Now we using a new version of the 3rd party library with some of the projects. As before, different developers may have the new library in different paths. How do we set local machine and project specific paths so that we can compile both old and new library projects?
Modifying a project's 'VC++ Directories' changes the project file (.vcxproj) which then poses a problem as we do not want to commit local settings into the repo.
We normally set an environment variable for each library that can be set by each developer in their environment in a env.bat file they run before running devenv (some made up examples) :-
ZLIB_ROOT=c:\somewhere\thirdparty\zlib
BOOST_ROOT=c:\somewhere\thirdparty\boost\version_123
and then in the project files add directories use "$(ZLIB_ROOT)/Include" or "$(ZLIB_ROOT)/Lib/x86" (all made up examples again...)
That way they will resolve correctly for any developer and they can have a different env.bat script for each version
Create a new solution with a C++ console command-line project
Create a new project, a C++ static library
Make the command-line project depend on the library
Make sure "Link Library Dependencies" is turned on in Configuration => Linker => General (it is by default)
Visual Studio will still not link the library.
How can I fix this? It worked in Visual Studio 2008.
This still works, but was changed in VS 2010:
"With VS2010, we stopped supporting project dependencies defining implicit references and we also introduced a new way of defining project dependencies at the project level. Since a project reference and a project dependency are close concepts, both applying to a project, it made sense to have them represented together, in a consistent way, in the project file. As you will see in the snippets below, the only difference between a project reference definition and a project dependency definition consists in metadata that defines the output assembly inclusion/exclusion into/from the main project link command line.
Although we did not remove the “Project Dependencies” dialog, we recommend defining new project dependencies via the “Framework and References” dialog. You need to set the “Reference Assembly Output” property in the property page UI to false for a project dependency and to true for a project reference."
Just right-click on the console project, select "Properties->Common Properties->Framework and References->Add New Reference" and add the static library project; also check that "Link Library Dependencies" is True on the right hand side. Seems to work for debug and release builds. You learn something new every day. ;)
They changed the UI for adding C++ project dependencies in VS2010, but oddly enough, without removing the old UI, or in any way indicating that it no longer works.
To create the dependency in VS2010, you need to use "Add New Reference" (can be found in project properties), and maybe also in the project's right-click menu (don't have VS here to check)
The old "Project Dependencies" dialog is basically broken now.
For MSVC 14 (2015 version) right-click on the project, then "Add->Reference..." and check all the needed dependencies.
Yes, it has changed somewhere between 2010 and 2015 versions. Fun!
And if you are looking to link a project that has resources in it - you need to specify the .res file directly in the list of linker input dependencies (project's properties dialog box) as it doesn't get picked up by the above configuration.
UPDATE
Still the same (new) behavior in MSVC 2017
I believe the old UI (dependencies) affects build order for Visual Studio, when building from within the IDE, for info. The new project configuration system embeds the references in each project file so that you can build from outside the IDE (whereas in previous versions, you could not, because you would not get automatic linking for dependencies, since dependencies were only done at the solution level).
There are also some issues with more complex projects in the new system; specifically, all resulting binary projects need to have explicit references to every dependent library to build correctly, whereas previously they could be effectively inherited from other dependent libraries. Same underlying cause, though.
I'm wondering how to make a release build that includes all necessary dll files into the .exe so the program can be run on a non-development machine without it having to install the microsoft redistributable on the target machine.
Without doing this you get the error message that the application configuration is not correct and to reinstall.
Choose Project -> Properties
Select Configuration -> General
In the box for how you should link MFC, choose to statically link it.
Choose Linker -> Input. Under Additional Dependencies, add any libraries you need your app to statically link in.
You need to set the run-time library (Under C/C++ -> Code Generation) for ALL projects to static linkage, which correlates to the following default building configurations:
Multithreaded Debug/Release
Singlethreaded Debug/Release
As opposed to the "DLL" versions of those libraries.
Even if you do that, depending on the libraries you're using, you might have to install a Merge Module/framework/etc. It depends on whether static LIB versions of your dependencies are available.
Be aware that Microsoft do not recommend that you static link the runtime into your project, as this prevents it from being serviced by windows update to fix critical security bugs. There are also potential problems if you are passing memory between your main .exe and .dll files as if each of these static links the runtime you can end up with malloc/free mismatch problems.
You can include the DLLs with the executable, without compiling them into the .exe and without running the redist tool - this is what I do and it seems to work fine.
The only fly in the ointment is that you need to include the files twice if you're distributing for a wide range of Windows versions - newer OSs need the files in manifest-defined directories, and older ones want all the files in the program directory.
You'd be looking to static link (as opposed to dynamically link)
I'm not sure how many of the MS redistributables statically link in.
If you are looking to find out which dll's your target machine is missing then use depends.exe which used to come with MSDev, but can also be found here. Testing this on a few target machines should tell you which dll's you need to package with your application.
You should use a static link and add all libraries you need under additional dependencies.