VS2010: Add project reference in the properties sheet file - c++

Our solution contains ~50 projects. There is a special one among them which has to be build almost first because almost every other project calls its executable. I know that through the Framework and References the build order can be defined by adding a reference to the project. Since I don't want to do it for every project and I want to ensure that every newly added project will reference the special one, my hope is that it is doable with the Properties Sheets
However, it seems that the Property Manager does not have option to modify the References for the .props files, at least I couldn't find it. Still, is there a way to do it?

Related

What is project reference in Visual Studio

there is a possibility to add an existing project as a "reference" to a solution in VS(talking about C++ now). As far as I understand it means that all the project files will be added to a solution and I can modify any properties and source code, and it will affect the original solution to which this project belongs. Do I have a correct understanding of it? Or is it something else?
I don't really get why we need it, if I need another project I can use it as a lib or DLL file, this reference thing seems to make things more complicated - if I do any changes to project properties I need to think how it will affect building another solution this project belongs to.
In Visual C++ "project-to-project" references within a solution really does two things:
If the referenced project is a static or DLL library, it's implicitly included in your referencing project's link statement.
The referenced project is considered a build-dependency for the referencing project so it will be built first.
That's pretty much it. If you want to include headers in the referenced project, you need to add it your AdditionalIncludes property for the referencing project.
For a DLL project, you can set a property on it to get it's DLL copied to your referencing project's build directory.
See Visual C++ Team Blog which was back in VS 2010 when it was first introduced.
There's a different model of code sharing called Shared Projects where the shared code is built in each referencing project--i.e. there's no shared binaries.

Duplicate project reference in SSDT Database solution

I am using tSQLt in a solution having multiple SQL Server Database projects in it. For each project, there is a .Test project which is referencing the original one and the tSQLt source.
Here is quick outline of the solution:
Solution
Project DB1
Project DB1.Test
Project DB2
Project DB2.Test
Project TSQLT
Where
Project DB2 depends on Project DB1
Project DB1.Test depends on DB1 and TSQLT (using the 'Same database' option)
Project DB2.Test depends on DB2 and TSQLT (using the 'Same database' option) and on DB1.Test (Same server, different database with a variable). since DB1.Test depends on DB1 and TSQLT, this project also depends on them (using the same variable used for DB1.Test).
The problem is that the reference to DB1.Test does not bring the TSQLT and DB1 objects when it is referenced from DB2.Test, so I get a huge list of warnings about unresolved references.
Warnings related to DB1 can be solved by referencing that project using the same variable as DB1.Test, but TSQLT is already referenced here and when I try to reference it twice, it leads to a "duplicate reference" error.
An obvious solution would be to make a copy of the TSQLT project in the solution, but honestly I just don't want to dupicate code.
Another would be to build that project using different configurations and simply reference the .dacpac files instead, but this feels like a hack.
We in theory could move the TSQLT project outside of the solution and have multiple copies of the dacpac file and reference those, however I am trying to keep everything in one place.
Currently we don't have NuGet repositories in place, so distributing code using NuGet packages to keep that part up-to-date does not work either.
I tried to reference it twice, but with different variable names, it still leads to the duplicate reference error.
I am aware, that unresolved reference errors in nested references scenario can be solved by adding all levels to the the project as a reference, but in this case one of the projects is used twice and duplicates are not allowed.
Is there any solution to either carry forward the references when there are nested references?
Or to have the local copy of the dacpac file generated during build saved using a custom (unique) name when it is copied from one project to another during build?
Please note that there are no circular references, just a project is used in multiple levels in the solution and without having the TSQLT reference in place for all instances, the build works just fine, just the warnings are annoying.
I am aware of the 'suppress warnings' option, but I would like to have them turned off. (This won't make the object magically appear in IntelliSense).
Turning the 'Local Copy' option on or off does not make any difference in behavior in this case.
I found a solution, which is still a bit smells like a hack, but working properly.
Build event
Add a post-build event to the common project:
Right click on the common project (TSQLT in this case)
Select Properties...
Go to the Build Events tab
Click on Edit Post-build...
Copy the following code into the editor window
Modify it to your needs
Save all when done (this will save the project and solution files)
copy "$(ProjectName).dacpac" "$(ProjectName)_DB1.dacpac" /Y
copy "$(ProjectName).dacpac" "$(ProjectName)_DB2.dacpac" /Y
This will create copies of the TSQLT.dacpac file in the output folder (TSQLT_DB1.dacpac and TSQLT_DB2.dacpac files will be created).
Make sure, that the build path for the dacpac file is using the $(ProjectName) variable, or use a hard-coded name and modify the build event accordingly.
Database reference
Reference these files as Data-tier application in the projects.
If you have multiple build configuration, open the .sqlproj file and edit it to have the build path dynamic:
<ArtifactReference Include="..\.build\$(Configuration)\TSQLT\TSQLT_DB1.dacpac">
<HintPath>..\.build\$(Configuration)\TSQLT\TSQLT_DB1.dacpac</HintPath>
<SuppressMissingDependenciesErrors>False</SuppressMissingDependenciesErrors>
<DatabaseSqlCmdVariable>DB1</DatabaseSqlCmdVariable>
<Private>False</Private>
</ArtifactReference>
<ArtifactReference Include="..\.build\$(Configuration)\TSQLT\TSQLT_DB2.dacpac">
<HintPath>..\.build\$(Configuration)\TSQLT\TSQLT_DB2.dacpac</HintPath>
<SuppressMissingDependenciesErrors>False</SuppressMissingDependenciesErrors>
<DatabaseSqlCmdVariable>DB2</DatabaseSqlCmdVariable>
<Private>False</Private>
</ArtifactReference>
Notice the $(Configuration) in the path. This method assumes, that the build configuration name is the same for all projects. (Basically we want the same thing here what you have in the build path(
Now you can remove the original project reference.
Build dependency
By removing the project reference, Visual Studio also removes the build dependency.
Right click on the solution
Select properties...
Go to Common Properties / Project Dependencies
Select the project from the drop-down list
Tick the checkbox in front of the referenced project
This ensures that building the current project will trigger the build of the referenced one (and that will run the post-build event).
Notes
I did update all projects in the solution which are using TSQLT to have artifact reference instead of project reference, this keeps the solution more consistent.
I did not change the reference to other projects, since I don't have this kind of issue with them.

Copy Visual Studio project settings to new project?

Background
I'm running Visual Studio Community 2015 on Windows 10, writing C++ code.
I have been handed a solution with two projects in it. I need to create a duplicate of one of the projects, but using different source and header files (containing roughly identical code, but located in another place in the file system).
The project that I want to duplicate uses a lot of libraries, and I don't know how that was set up. All I know is that it works for that project, and I need it to work for the duplicate project too.
Problem
The problem I'm having is that at least one of the libraries does not seem to be recognized. This results in code with a red squiggly line under it, no auto-complete, etc. etc.. (This is not relevant anymore, see Edit 1)
Attempted solutions
I have tried creating a new project with the new source files, adding it to the solution, and manually copying project settings by right-clicking on the existing project, selecting Properties, and copying anything that is not set to its default value. This did not work.
I have tried copying the existing .vcxproj files, adding them to the solution, removing old and re-adding new source and header files. This did not work.
In both cases, when expanding External Dependencies in the Solution Explorer, the old project has a much longer list than the duplicate.
I am aware of this question, but the accepted answer relies on knowing which settings need to be changed. I don't know that, and I don't know how to find out.
Questions
So, is there a way to copy the entire set of settings that controls this?
Alternatively, is there a way I can check in the existing project precisely why it is able to resolve a particular external reference, so that I can find out which setting I need to change in the duplicate?
Edit 1
Well, now I feel stupid. I've been fighting this issue for a few days now, but I've made a few incorrect assumptions about the files I have.
It turns out, the second set of header files (located at a new place in the file system) are similar, but not identical, to the old ones. So at first glance, they look identical, and I never bothered to check.
The new header files has #if defined(WIN64) before the relevant #include statements, which of course is why the library wasn't being included.
So, my new question is, what's a sensible way to #define WIN64 without modifying the header file? Where can I put that definition so that it's valid in that header file, without changing that header file?
The correct way to use the same project properties for multiple projects would be not copy-pasting properties between them but to use Property Manager. You should figure out how exactly you original project is configured (note that properties for particular file can differ from project properties) and create a corresponding property sheet(s). Then apply this sheet for the new project.

Need to set a comman library file for all projects of a single solution Visual studio 2010

I need some help to add a .*lib file for my solution and this solution has many projects.
I am going to make it more clear. Lets i have a "ABC.sln" solution in visual studio 2010. This ABC.sln has several projects (VC++ Project (1,2,3....*vcxproj) and these 1, 2 and 3 projects required a 123comman.lib file in the linker option of their respective projects.
Currently i add this library file in all three projects and it works fine but i think there must be some way to set this library file as a common stuff for all projects inside a solution. So that i just set it once and all projects can share it.
Is it possible ? if yes how can we do that ?
Thanks!
VS2010 introduced the concept of Property Pages, which is distinct and separate from Project Settings. Property Pages are similar to Project Settings in that you can specify things like additional dependencies, language rules, optimization settings, etc. But unlike Project Settings, Property Pages use a different file to store these settings, and these files can be shared across all (or any) projects in your solution.
Documentation for Property Pages is here -- I'll leave the details up to you. But to get started, go to View > Property Manager, open up one of your projects, create a new property page for a given platform (x64 Debug, x64 Release, etc), and set your settings. Then you can use this Property Page in your other projects.
Projects can share configuration via property sheets. You can create them in the project configuration tree by right-clicking a project and selecting "add property sheet" or something like that (been a while). In a property sheet, you can specify the import, and then you can add the property sheet to all other projects as well.
This does not reduce the initial work: you still have to add something to every project. Solutions do not have the ability to inject anything into projects; they're a completely different file format.
However, it does save you work if you then have to do another task that is common to all projects, like changing the library name you want to include, or adding another library. Then you only have to do it once, in the property sheet.
Make a NuGet package out of this library, and use the package manager to add the dll to all projects.
An in-depth description of how to generate a NuGet package for C++ code can be found here.
If you do it this way, it only takes a single click per project (to enable the checkbox when adding the package in package manager) to add the library as dependency.
If your problem is only about sharing the same file among different projects in a single solution. You can add the file at solution level and then do add existing items in individual projects and choose to add them as link.
This way you have only one copy of file that is shared.

C++ Using projects instead of libs

I have a huge solution in VS2010 that includes several projects.
I am basically working with one of these projects.
This project needs the other projects.
However, they are currently linked with this one project only by Properties->Linker->Input.
These Input dependencies are filled by project1.lib, project2.lib, etc.
Does anybody know how I can make my project use the actual projects instead of their libs?
I am asking because I want to strip down the code, and if I remove something from the other projects, I would still have to generate the libs to actually see the changes.
That is why I would like to link directly to the other projects so that any changes are "visible" immediately.
You can use Project references
Project properties->Common Properties->References