I am looking to provide a better way of managing the distribution and storage of binary dependencies for a large VC++ project.
Currently we have the situation where externally and internal built libraries are stored within the the source control repository resulting in the .cpp and .h files forming less than 3% of the space that is retrieved. This makes the process of creating a branch slow, and prevents sensible migration to a DVCS.
I don't want to change the main method of building through MS visual studio solutions, but I am willing to add an additional step to fetch/setup all the binary dependencies.
This is currently achieved for some libraries using are existing Source Control, by mounting different repositories containing the built files. This could be one approach (which I don't favour).
Has anybody got experience of using Ivy or Maven in a VC++ environment?
The maven-nar-plugin might be solution for you.
Maybe vcpkg is a alternative solution for you.
Documentation is available here or for Visual Studio here
Related
While exploring about the platform setup for OpenCASCADE, I came to know about WOK commands which arent needed for CMake build system to use with OpenCASCADE
However another option of genproj tool (for which I havent yet found any exe but DLLs..) to be used with MSVC+ in built compiler so that we dont need any gcc installation
Whats the difference between the twos and which one is better and easier??
Also suggest me how to download and install and setup genproj on windows
OCCT project provided the following build systems:
CMake. This is the main building system since OCCT 7.0.0.
It allows building OCCT for almost every supported target platform.
WOK. This was an in-house building system used by OCCT before 7.0.0 release.
The tool handled classes defined in CDL (CAS.CADE definition language) files (WOK generated C++ header files from CDL) and supported building in a distributed environment (e.g. local WOK setup builds only modified source files and reused unmodified binary / object files from local network). WOK support has been discontinued since OCCT 7.5.0 and unlikely will be able building up-to-date OCCT sources (although project structure remains compatible with WOK).
genproj. This is a Tcl script allowing to generate project for building OCCT using Visual Studio (2010+), Code::Blocks, XCode and Qt Creator. This script has been initially extracted from WOK package (where it was implemented as command wgenproj in it's shell) and now maintained independently from it.
qmake. Experimental adm/qmake solution can be opened directly from QtCreator without CMake plugin (the project files will be generated recursively by qmake). Although header files generation (filling in inc folder) still should be done using genproj (qmake scripting capabilities were found too limited for this staff).
genproj doesn't require any DLLs or EXE files - it comes with OCCT itself and requires Tcl interpreter. On Windows platform it can be executed with genconf.bat and genproj.bat batch scripts in the root of OCCT source code folder. At first launch it will ask to put a path to tclsh.exe.
While CMake is the main building tool for OCCT project, genproj remains maintained and used by (some) developers - mostly due to personal habits and hatred to CMake. They differences of genproj from CMake that could be considered as advantages in some cases:
Generated project files can be moved to another location / computer without necessity to re-generate them.
Simplified 3rd-party dependency search tool genconf with GUI based on Tcl/Tk.
Batch-script environment/configuration files (env.bat and custom.bat), although CMake script in OCCT emulates similar files.
Generated Visual Studio solution contains Debug+Release and 32bit/64bit configurations.
Running Draw Harness and regression tests can be started directly from Visual Studio (without building any INSTALL target).
No problems with CMakeCache.txt.
Limitations of genproj:
No CMake configuration files. Other CMake-based projects would not be able re-using configuration files to simplify 3rd-party setup.
Regeneration of project files should be called explicitly.
Out-of-source builds are not supported (however, each configuration is put into dedicated sub-folder).
No INSTALL target.
No PCH (pre-compiler header file) generation.
It should be noted, that several attempts have been done to make compiler / linker flags consistent between CMake and genproj, but in reality they may be different.
Can you please advice how I can speed up a compiling, loading big solution (~50 projects).
I mean only VS 2012 studio or Windows settings, not hardware changes.
Thanks
Consider your need for 50 projects in one solution - having many projects that are referenced by each other is one of the main reasons for slowdowns.
One of the few valid reasons to have separate projects is because you need to deploy the generated assemblies separately. If this is not the case, consider combining projects - use folders for the logical separation.
The lower the number of projects, the faster your build will become.
In addition, if you change the builds to output to a specific shared directory and reference the DLLs instead of the projects, the number of unneeded re-compilations should go down drastically, though you will have to manage the build order yourself.
I use 100+ projects in a solution with Visual Studio 2012 Update 3, and it builds fast.
I agree with shared output directory comment by Oded, but I'd like to mention that project references work OK too.
Make sure that your \Users\\AppData\Local\Microsoft\WebsiteCache folder is empty. Somehow, this is a problem even with desktop-only solutions.
I have disabled Productivity Power Tools 2012, since they compile code in the background, a bit too much for my liking. Disable all plug-ins and extensions and see if it makes any difference.
Suppress excessive output messages to disk and to screen by reducing output verbosity
Use multicore with MSBuild.
As you code, try to limit dependencies between projects by using interfaces and abstract classes (C#).
Try fresh *.suo and fresh *.sdf files. (Make a backup of the user settings and DB, then remove them and try building again)
When all else fails, use ProcessMonitor or attach with another instance of Visual Studio to profile your Visual Studio while it's building.
Try excluding file system filters, such as antivirus, from your build. For example, some antiviruses have a way of skipping scanning in certain directories or by file names.
I inherited a project setup from a previous programmer. He used to develop for linux, but instead of coding directly in ubuntu, he shared the drives with samba and used Visual Studio to edit the files.
Now I can't compile this project in Visual Studio directly obviously, so I can't get data for intellisense and such. Would it be possible to associate symbols without compiling?
I know that what I ask seems counter intuitive, but Vim plugin OmniCPP does not come with a compiler and yet, is able to provide code completition up to a certain degree.
The commercial addin Visual Assist X can help. How well it helps is dependent upon how much information it can get from the project (if one exists): things like source files, header files and include directories. If no project is being used, you can create a dummy project just as a container to associate source and header files (not for compiling).
I have an application that uses the ms vc++ runtime. How should I install it on the end-user's system if it is not present? I was thinking of bundling it with the installer... but how would I do that as far as what to include? Is there some silent installer? If so, where can it be found? I can't seem to find it in the Windows SDK.
There is an interesting post about deploying the runtime libraries on the Visual C++ blog. The post is about VC8 so I'm not sure all the recommendations apply to VC9.
Here are your options according to Microsoft:
Use an .msi installer including the .MSM files for the VC
libraries you're using. These MSM
files install the libraries globally.
They also keep a reference count so
that the libraries are removed when
the last application using them gets
uninstalled.
Use "app-local"
deployment i.e. copy the
libraries and manifest files in your
application directory. This is a simpler
solution if you don't use an .msi
installer. Your app should still use the
system version of the libraries if they are more
up-to-date than your own.
Link everything statically (and avoid crt usage across dll boundaries)
Another option Microsoft discourage you from using is running the Visual C++ redist installer from your own installer.
I'm not sure what their reasons are. It will take a few extra megabytes and will not be reference counted but it still works very well AFAICT. You can pass the /q option to vc_redist_x86.exe to perform an unattended install (no user interaction).
It has it's own installation program. I've seen it usually run as a prereq step of a larger installer.
One way or the other, you need to list it in your manifest. So you might just as well deliver it as via SxS in your application rather than try to deliver a global copy to the target machine. SxS is a big hard subject, sadly. Hopefully someone will supply an answer with more details and I'll delete this one.
I'm developing in an environment that is severely constrained, but the developers also have tight control over.
VCRedist_x86.exe - A 4Mb redistributable - is no fun (four hours to transfer). I'd really prefer to just redistribute MFC90.dll, msvcm90.dll, msvcp90.dll and msvcr90.dll - that's more like 2Mb. However, Redistributing Visual C++ Files says:
It is not supported to redistribute C/C++ applications that are built without a manifest. Visual C++ libraries cannot be used by C/C++ applications without a manifest binding the application to these libraries. For more information, see Choosing a Deployment Method.
My original plan of copying the DLLs into the program's working directory doesn't seem to
work in this brave new world of manifests.
My next guess is to bodge up the registry entries required to populate the files into the WinSxS directory and populate it myself (rather than using the 4 meg program).
[edit] The software is frequently updated, so DLLs are strongly preferred to static linking. [/edit]
How can I sucessfully distribute the necessary files but keep the overhead down?
[I'm the current SxS maintainer at Microsoft]
I would strongly suggest against removing the publicKeyToken attribute from manifests. Private deployment of the dlls will work just fine with this attribute left intact.
However, removing it will prevent your app from benefiting from security updates should there be a newer version of the CRT installed centrally on the target machine, as the dependencies will no longer match up.
So, to summarize: it's safe to embed your manifest, with the default. Copy the CRT manifest + DLL files directly into your executable's directory, with no edits. That's it. Compatible Win2k+.
We use this: Howto: Deploy VC2008 apps without installing vcredist_x86.exe
Essentially
Don't embed a manifest in your exe files.
Copy the C++ DLLs and their manifests to your app's directory.
Remove the "publicKeyToken" from all manifests (yours and Microsoft's).
If necessary, change the version info in your app's manifest files to match the Microsoft manifest files (or vice versa)
Specify /MT (Multithreaded) for the "runtime library" setting in the compiler property page. This statically links against the runtime library so you don't have to install the redistributable.
Install them as private assemblies. See here:
http://msdn.microsoft.com/en-us/library/ms235291.aspx
Note that if you don't need all of the DLLs provided you can modify the manifest files to only reference the ones you need.