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.
Related
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.
I googled this a lot and I found very poor solutions on how packages are managed in C++.
Let's suppose that I am working on a project called Project C which is dependent on C++ project Project B, and Project B is dependent on another C++ project Project A.
Currently, we use Visual Studio to develop our projects. When Project A changes, every single developer pulls the changes and recompiles the project locally. Every single developer has a lib folder with all of these dependencies that contains the DLLs and header files that we copy for each project manually.
Then since we know the dependencies, we then go to every project that is dependent on Project A, copy the dlls of Project A from lib folder and recompile those as well until we get what we want.
I know however, that C# has nuget and one can manage external dependencies and Java has maven where one can do the same.
What we currently do is a manual, error prone and extremely time consuming process. Is there a way to handle dependencies for C++? We should be able to build with the debug ddls of the dependencies when compiling as debug and the release dlls when compiling as release. For now we just need to have the latest dlls.
We have jenkins installed and if we could use that to help us that would be perfect. For java projects our java engineers compile the project and maven packages are pushed into a maven repository from where everybody else is just pooling. As simple as that. But how we can achieve similar functionality in C++?
I've written a game using OpenGL, GLFW, C/C++. I use third party libraries like SOIL and irrKlang. I use Microsoft Visual 2015. Both the debug and release version run ok from visual studio. In properties -> C++ -> Code Generation-> Runtime Library I selected /MDd. I did try other settings but the release version wouldn't work with any other. All of my .dll are saved in the release and debug folders.
However, when I go to my release folder and copy and paste the .exe found there, onto my desktop,it no longer runs. I keep getting a message that says the irrKlang.dll is missing. Could someone please explain how to get a standalone .exe of my game up and running?
Two things here. First, the .exe is the executable which contains the entry point of your application. So this is indeed the first piece you need. However, your application is allowed to depend on code that's not linked into it statically, but rather dynamically -- such dynamically linked code is only loaded at runtime. These runtime libraries of code are called DLLs ("dynamically linked libraries").
If your application depends on a DLL, it will look for that DLL while it's running. If it doesn't find it, you'll see that message box about a missing DLL. So, you need to copy not only the .exe file, but all the .dlls it depends on (and that they depend on) too. Note that your application links against many default system DLLs, e.g. kernel32, but these don't need to be copied next to the .exe because they're always present in the system search path.
Now, the second part. If you want to run your application on a PC that doesn't have Visual Studio installed, you need to make sure that computer has the C/C++ runtimes that the VS2015 toolchain automatically links against installed. These are not DLLs that you copy by hand; rather, there is a redistributable installer for them which installs them globally on the PC for all applications. You can ship this with your own installer.
For this to work, you want to be linking with just /MD in Release (the debug CRT is for debugging only, and is only installed when Visual Studio is installed -- it's not meant to run outside your PC).
This statement:
"Both the debug and release version run ok from visual studio. In properties -> C++ -> Code Generation-> Runtime Library I selected /MDd. I did try other settings but the release version wouldn't work with any other."
Leads me to believe that maybe you don't have a release version of one of your third party libraries.
/MDd causes your application to use the debug version of the MS runtime, which means that something in your project is being built with or as a debug version.
I use the 'depends.exe' application to see the dependencies of my executables and DLLs. It used to be provided directly by Microsoft, but now seems to be supported via a third party. Older SDKs will have it.
http://www.dependencywalker.com/
My solution consists of several managed and unmanaged libraries. I am using NuGet for all projects (even for the unmanaged libraries). I am not storing the packages in source control (I am using the option "Enable NuGet package restore"). Since introducing this change with NuGet, the unmanaged projects files (vcxproj and vcxproj.filter) are checked out by VS even there were no changes made. Does anybody has a clue what could be the issue?. I think it is connected with NuGet.
I have an ATL/WTL project developed using Visual Studio 2008 and up until now I have been statically linking with the CRT libraries, avoiding the need to ship them. However, I now need to consider using the dynamic libraries (DLL) instead - in order to reduce the size of the code and because I want to use the excellent crashrpt tool (which requires you dynamically link to the CRT.)
Now, MS supply both a stand-alone installer (vcredist_x86.exe) and an MSM package but this is no good for me for two reasons:
I am not using an MSI based installer (I am using InnoSetup).
My application installs on a limited user account and the vcredist_x86.exe installer will not work.
Therefore I want to ship the CRT DLLs and install then in my applications program folder. Now, this is something you can do as I found the following blog post by Martyn Lovell, the MSVC Libraries Development Lead that says:
However, if you want to
install-applocal, you should make sure
that your application has a manifest,
and then copy the whole of this folder
into your EXE directory:
X:\Program Files\Microsoft Visual
Studio
8\VC\redist\x86\Microsoft.VC80.CRT
and other folders if you use more than
the CRT. Make sure you include the
manifest.
Just want I am after - except I don't understand this part:
make sure that your application has a manifest
My question is - how do I create an application manifest that references the CRT DLLs I want to use? The only manifest information my projects currently use is the following (which ensures the app uses v6 of the Common Controls):
/manifestdependency:\"type='win32' name='Microsoft.Windows.Common-Controls' version='6.0.0.0' processorArchitecture='x86' publicKeyToken='6595b64144ccf1df' language='*'\"
Can someone provide me with instructions on how to work the manifest magic using Visual Studio 2008? There is a Microsoft.VC90.CRT.manifest file in my Visual Studio VC\redist\x86\Microsoft.VC90.CRT folder - do I need to use this somehow?
Note: This is a similar - but different - question to this one.
Visual Studio will generate the correct manifest for you when you pass the /MD flag.