I'm using visual studio 2010, and its a C++ solution with multiple projects. I have project A which has reference to project B(Properties->Common Properties->Framework and References). Project C references project A.
Now the build order is B->A->C. C now indirectly references B, is it required that we should manually add Project B as reference to project C?
I want to make sure that when project C is built project B should automatically be built if any changes were made to it and it is not rebuilt yet.
Building your Solution should always build Projects that have changes.
A circular dependency is created if you try to make B->A->C->B. You can have circular dependencies in VS but the build order must be managed manually. See this post.
If a Project references an assembly and not the Project that builds that assembly then VS does not build the dependent Project. If the Project references the Project that builds the dependent assembly then any changes to the dependent Project are built before the target Project. This is the default behavior in VS. That behavior can be changed or managed using the 'Build Dependency' dialog.
Related
I've got a C# project in my solution. When I try to build it, a different C++ project is being built first. The C++ project is not listed as a project dependency of my C# project, or as a dependency of its dependencies.
And there is no "build only" option for C# projects so I cannot tell if this is a dependency issue, or some weird bug.
Anyone able to help?
We have a visual studio package (VS Package) that references a class library project (Project A). Project A in turn references another class library project (Project B).
So the dependency structure looks like this: VS Package > Project A > Project B
All projects exist inside the same solution and the dependencies have been set up as proper project references.
If I build the package in visual studio and look in the bin/Debug folder all necessary assemblies are there including Project B's. However when the package is deployed, only Project A's assemblies are present and Project B's are missing. How do I tell visual studio to include the indirect dependency of Project B in the package?
This MSDN document suggests that "By default in a multi-project solution, if a project that outputs to a VSIX package includes a reference to another project in the same solution, it includes the dependencies of that project."
However I am finding that this is simply not the case.
My question is very similar to this one except that I am having trouble with the main project assembly and not the localization satellite assemblies. The answer in this other post does not work for me because it seems to only work for satellite assemblies.
Is there some other Output Group that I can specify to direct the package to include indirect dependencies as well?
Thanks for looking.
The simplest thing to do in this particular case is reference Project B from the VSPackage project and set the "Reference Output Assembly" property to False to avoid introducing a compile-time dependency.
I had a similar problem: My VS Package project referenced another VS package project (~Project A) which in turn referenced a bunch of other projects (~Project B) containing the meat of our extension.
Inspired by this answer: VSIX package doesn't include localized resources of referenced assembly, I added 'BuiltProjectOutputGroup;BuiltProjectOutputGroupDependencies;GetCopyToOutputDirectoryItems;SatelliteDllsProjectOutputGroup' to the Output Groups Included in VSIX property of the reference from VS Package to Project A.
This had the effect of dropping all the dependency DLLs in the ...\Debug\ folder for my VS Project, but they still didn't get included in the VSIX.
Finally I went and added the BuiltProjectOutputGroup;BuiltProjectOutputGroupDependencies;GetCopyToOutputDirectoryItems;SatelliteDllsProjectOutputGroup flags to all the references from my Project A to each of my Project Bs - then they all got included in the VSIX.
(BTW this is with with Visual Studio 2013, but it doesn't seem to have change much since 2010)
I'm working in a project for a customer where one solutions has 3 projects.
Project A is the base, then project B depends on A, and project C depends on B. By the way, project C is the application, A and B are class libraries.
Usually, I can make a change in project A without the need of manually recompile B and C because Visual Studio does it automatically for me.
However, in this environment (after downloading the solution via Ankh SVN), the dependencies are somewhat not recognized when executing. I'm forced to manually recompile the dominant projects of the dependency hierarchy.
Why is this happening? and how to solve it?
Thanks!
Make sure you added the references of project B and project C as a project and you didn't add the project output as an assembly reference.
It is not possible to "Add reference" of managed project on native.
I have found here that this is possible via "Add item" - reference to dll. But in such case rebuild of dependent projects will not happen.
If I add dependency directly in project files via <ProjectReference> item group item, VS shows dependent project in References, but with Exclamation mark (!).
How to add reference of managed project on native one smoothly?
Thanks!
If you are trying to capture inter-project build dependencies at the solution level where those projects can't actually reference each other, you can set up explicit dependencies inside Visual Studio by right-clicking on the project in question and choosing "Project Dependencies...".
You can explicitly specify the dependencies here (but implicit dependencies will already be greyed out). Adding dependencies in this way will alter one or more ProjectDependencies sections in the solution (.sln) file so that building it from either devenv.exe or msbuild.exe will ensure correct build order.
Is it possible to tell VS not to recompile some projects every time and use already compiled dll-s instead?
You can exclude any project from building in Configuration manager. Just unselect desired projects in Build column. You still will be able to debug those projects.
Instead of project references, you can add the compiled DLLs as references.
Any such referenced project will not rebuild if not changed.
However, since the references will now be to DLLs, you need some strategy to keep them synchronized and up to date with your code.
As I understood your question, you have a solution with multiple projects and you seem to have dependency of some of them on some other.
VS will always compile all the "loaded" projects. But when you add a reference to a project, add it directly to a (preferred) DLL assembly file, and not to one of the projects. This way the other project will be compiled but you are referencing the same DLL assembly over and over. Since if you reference the project, the output of the project is always what you reference actually.