Lately I've been working on a C++ project in Visual Studio. I had to configure the project in every detail: libraries, linker options, optimization, optional compiler setting etc...
Now I'm moving to another similar project and I'd like to reuse the settings of the current one without manually setting them again.
You do this with a project property sheet. I typed up an answer recently to show how to use them.
Related
I have VS solutions with hundreds of C++ projects built using Azure Devops, these projects have a big mess of different project settings as projects have been created at different times over 2 decades, converted from different VS versions, etc.
We want to standardise some settings for instance building everything using c++17 standard. That's a compiler setting cl.exe /std:c++17 but I cannot see any way we can override this via msbuild/YAML; I'd initially assumed I could set it as a project property msbuild -p:std=c++17 but this isn't possible (for reasons I don't fully understand).
In another couple of years we might want to force all our code to build against the c++20 standard. Equally, we might want to compare builds flip-flopping between two settings. So: is there a way we can apply compiler settings at build-time which override the project-specific settings?
There seem to be two approaches (other than editing all the project files individually):
Use switch p:ForceImportAfterCppTargets on the msbuild command-line. This allows a .props file to be specified which is evaluated and overrides project settings. More information here: MSBuild: Custom.After.Microsoft.Common.targets for native C++ projects in VS2010 and in the docs
Use directory-level file Directory.Build.target file, this will be auto-discovered by msbuild and similarly override project settings.
The one downside is that these methods both seem to only apply to msbuild, not within Visual Studio itself, which can lead to confusion when something will build in the IDE but not on the build agent or vice versa.
Having to manually editing the settings for every new project I create is quite tedious.
And it is quite error prone so I sometimes forget to add something and a compile
error happens.
Is it possible to set up Visual Studio so that the settings I need for OpenCV are automatically applied to every new project?
By the way, I'm using Visual Studio 2010.
Certainly under VS2012 you can set properties in microsoft.cpp.win32.user and they become global.
And according to this (and my vague memory) it works for VS2010 too:
http://www.curlybrace.com/words/2012/12/17/setting-global-c-include-paths-in-visual-studio-2012-and-2011-and-2010/
However, what I do is have a property sheet with all the OpenCV settings in it and when I create a new project I add the property sheet. (actually I have two, one for debug and one for release, although if I used conditional properties I would only need one.).
If I change versions of OpenCV I edit that property sheet and all my projects get the new settings.
Also see http://blogs.msdn.com/b/vsproject/archive/2009/06/23/inherited-properties-and-property-sheets.aspx
Your should consider using CMake (as OpenCV itself does) for generating your project and solution files. It will allow you to (re-)generate your solution files on any machine in a consistent manner for multiple versions of IDEs and OpenCV updates.
All you need is a single CMakeLists.txt file along with your source code.
You can import/export your project settings.
In Visual Studio(2010), goto Tools -> Import and Export Settings..
There you can, backup/save/export your current project settings. Now every time you create new project, import this setting and you won't need to repeat complete procedure.
I asked about debugging dylib in Xcode in this post. For Visual Studio, I can use the 'Add New Reference' in Property pages to assign a dynamic library project from the project that uses the library. And, I can put all the project in one single solution file, and make the project as 'Startup Project'. I just set breakpoints and run to debug the dynamic library.
Can Xcode do the similar/same thing?
Can Xcode have two or more projects in one something like VS2010's solution file?
Does Xcode provide something like referencing project to debug dynamic library?
Can Xcode have two or more projects in one something like VS2010's solution file?
You can include an Xcode project in another Xcode project. Just use the Add Existing File action to add it. Then you can reference any of the included project's build products.
My problem seems pretty simple. I have a Solution with multiple projects and basically I am trying to do some mixing with C++, C# and CLI. My problem is that I need to add references from my c++ project. When the "Add Reference" dialog comes up, I only get tab for "Projects".
I know that usually you get multiple tabs for adding different reference types. What I am interested in is the "Browse" dialog. I need this to add a reference to a dll that is prebuilt. I am targeting .Net 4.0.
It seems like there is a project property that can be set to limit this but I'm not sure. MSDN seems to mention something along the lines that if you have multiple projects in a solution and they target different versions of the .Net framework, the list of possibilities may be limited.
In "How to: Add or Remove References in Visual Studio" MSDN mentions: "The number of tabs available at the top of the Add Reference dialog box can vary, depending on the type of project open and the resources it is using. C++ native projects contain only a Projects tab."
It doesn't really mention what these are specifically so maybe its just a broad subject. Anyways, I have stripped down the solution to only my C++ project and I can build successfully. However, I can only add References to other projects.
Apparently, setting the CLR option on the project is what opens up the list to include more options. I only wanted to enable it on one source file, but I guess Visual Studio will not add reference capabilities unless you turn it on for the whole project.
Therefore, my solution was to enable it for the whole project, add the reference, and then remove the option on the project. Basically a dirty trick but just in case people run into the same issue, that is what worked for me.
Erik
When you unload a project in Visual Studio, any referencing projects get warning triangles on their reference to the unloaded project. I've written myself a macro to do clever stuff (detect add/remove of project and transform any references from-to file/project dependency), but I can't believe that I'm not missing something much simpler. How can the unload function be any use if I have to go around manually changing references (and it breaks the 'personal solutions/shared projects' team development paradigm).
(This question is related to answers to this question about structuring large solutions in Visual Studio - some answers mentioned having solutions with lots of projects, but 'unloading' unused projects to improve performance.)
For my projects, I create an assemblies folder which the projects automatically copy into from a set location to which other projects copy builds.
Post-build for referenced assembly's project:
if not exist "C:\builds\Project1" md "C:\builds\Project1\"
copy "$(TargetDir)$(TargetName).*" "C:\builds\Project1\"
Pre-build for referencing projects:
if exist "c:\builds\Project1\" copy "c:\builds\Project1*.*" "$(ProjectDir)assemblies"
The project file points to its assemblies subfolder for references so even if the source projects are unloaded from the solution, the last-built assemblies will be used without the performance problems of having the whole project in memory while developing.
What are the advantages of having projects in the same solution if you use file references?
If your app.exe uses utils.dll and you change the code for utils.dll, then if it's in the same solution VS will notice the dependency and recompile both. If it's not in the solution you'll have to jump out, recompile utils.dll seperately, then jump back in and recompile app.exe.
This becomes either more or less important depending on how many other dll's your exe is referencing, and how often they change (in team environments shared dll's change often in my experience).
There is also the side effect that if you have 100 projects in VS it will take a long time to process them all just to figure out if they need recompiling or not.
Unloading projects is meant to be a temporary action so you can edit the actual project file as XML (text). If you want to completely remove a project from your solution, you should use the "Remove" menu option, which will take care of removing any references to that project.
One advantage to using project references is that it allows you to easily debug through the code. It also automatically ensures that you are using the correct configuration build (ie, if you are building in "Debug" mode it will use the Debug version of the assembly). That being said, you loose some determinisim about which version/build of the dependent project you will pick up - project references mean you always use the latest.
Yes, for Visual Studio to determine build dependencies it must be able to see and build all of the projects which would mean project references.
I've just had a eureka moment reading through MSDN doc on structuring solutions and projects.
What I hadn't noticed is that in a multi-project solution, the context menu in the Solution Explorer proposes a Project Dependencies popup. Here you can define the project dependencies manually, if you haven't defined them by project references between projects.
See here (MSDN link, so will self destruct after a few weeks)