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.
Related
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.
We've recently converted a large MFC-based suite of projects from Visual Studio 2005/2008 to Visual Studio 2012 (Update 5). Our projects previously used a set of configuration-specific manifest files, embedded as resources, to specify the exact version of the side-by-side (SxS) assemblies to load. As an example, below here is a snippet from one of our old manifest files for the VC90 runtime:
<assemblyIdentity type="win32" name="Microsoft.VC90.CRT" version="9.0.30729.1" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
Previously, I could associate the identity above with a folder at C:\Windows\WinSxS. An example would be the folder "x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.1_none_e163563597edeada" which contains the correct binaries.
As you can see, the folder name contains all the information necessary to populate the assemblyIdentity node's attributes. Unfortunately, this (outdated) article confirms my findings that Microsoft no longer stores VC2010+ SxS files in this manner. I want to tell our projects to run against the latest Microsoft Visual C++ 2012 Redistributable (installer v11.0.61030.0). How do I locate the correct name/version/publicKeyToken information for these binaries? I could not find an MSDN listing or similar.
Note that I've been using sxstrace.exe / Dependency Walker and the like to investigate this issue. I can confirm the manifest files are being appropriately embedded in our executables; the issue is only the manifest files are specified incorrectly.
Thanks in advance!
Look at this. As I remember correctly by default your application will be linked to libs as in your Windows SDK. And to make project use default libs just delete info about them inside your project file or recreate project with default settings.
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.
When i use Visual Studio, my executables depends on microsoft redistributable package - the package that deploys MS's runtime DLLs. That is annoying to me. What disatwantages my executable would have if i would use MinGW?
I also want to try link with lib- avcodec/avformat, that are built by MinGW and i have no my own mind power to build them in VS from src.
In case of using MinGW you will depend on DLLs that are shipped with mingw. It is not big deal to change one vendor to another.
If you already have MS project, review possibility to statically link MS libraries (it is option is provided for some of VisualStudio projects on creation time in project options)
You can link everything statically with MinGW. Use the -static linker flag.
No need for redistributing any DLL's, but you have to make sure that in the c++, there's no exceptions being passed over DLL boundaries (so make sure every C++ library is linked statically in this case).
I am using VS2008 for developing a COM dll which by default uses CRT version 9
but I am using TSF (Text service framework) that is not compatible with the new CRT. I think the solution is to use the compatible one so how can I specify the CRT version?
I whole heartily join the recommendation not to manually change the CRT version you link against. If however, for some reason (which I cannot imagine) this is the right course of action for you, the way to do so is change the manifest for your project.
First make sure a manifest is not generated on every build (on VS2005: Configuration properties/Linker/Manifest file/Generate manifest), as it would overwrite your manual changes. Also make sure there that isolation is enabled.
Next, locate the manifest file - should be at the $(IntDir) (e.g., Debug). You should see a section similar to -
<dependency>
<dependentAssembly>
<assemblyIdentity type='win32' name='Microsoft.VC80.DebugCRT' version='8.0.50727.762' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b' />
</dependentAssembly>
</dependency>
(For debug builds, of course). You need to edit the version and publicKeyToken attributes of the CRT element.
You can inspect the files at your local WINDOWS\WinSxS folder to see the versions available. Check here how to extract the publicKeyToken once you find the version you want. (Although I'd first try and look directly into manifests of other projects, linking against your desired CRT version).
If you do go there, expect some rough water. You may have some luck if your application is a console app that does not link against other Side-by-Side components (MFC, OpenMP, etc.). If your application is non-trivial, I'd be surprised if there aren't some intricate version dependencies amont the SxS components.
(edit) You'd also need to distribute with your application the specific CRT you're using. Here's someone who did that.
The easiest way will be to build your DLL with a VC++ version that uses the CRT that is compatible with TFS.
I don't think that it is a good idea just to link your DLL with a different version of the CRT, unless you also use the same version of the header files. And the easiest way to do that will be to use the right VC++ version...
If you still want to try, you can:
go to "Configuration settings->Linker->Input->Ignore specific library" and enter the crt you are using (libc.lib, libcmt.lib, etc. see this code project article for details).
Enter the name of the crt version you want to use in "Configuration settings->Linker->Input->Additional dependencies", and its path in "Configuration settings->Linker->General->Additional library directories".
You can also try to change the default directories in "Tools->Options->Projects and solution->VC++ directories->library files". Maybe changing $(VCInstallDir)lib to the path where you other version of the CRT resides will do the trick
Don't try to use VS9 and link to another version of the CRT.
If you need your app to link to another CRT, say VS8's CRT, then you must compile & link your app in that version of VS.
The solution worked for me with Visual Studio Express 2013 x64 + OpenCV 2.4.9 x64 compiled, debug (I integrated that in LV2013 x64), but it should work for any other VS-version:
1) Right-click on your Solution > Properties > Debug Source Files ...
2) There are maybe two entires (depending on your VS-install-directory)...
C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\vc7\atlmfc
C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\vc7\crt
With these it would work for Visual Studio 2013 Express but should also work for other 2013. If you've got Visual Studio 10 or 11 just type "Microsoft Visual Studio 11.0" or 10.0 in each. You can also just add them.
These entries you can get from your OpenCV.sln under Solution > Properties > Debug Source Files (as described above). And as already decribed: CRT needs to match... and this happens in that place.