I have a big VS2008 solution containing >30 VS projects with legacy code. One of these projects (let's call it A) generates a header file, which is needed by a few other projects (for example B). When I go to "Project Dependencies" of the VS solution, I can check project A for project B's dependencies - but VS includes in the project B's linker command line options an additional argument for project A's lib ("A.lib"). Unfortunately, since project A does not create a lib file, this project B will never find one and cannot be built.
Is there a feasible solution for my problem?
Thanks in advance!
Cheers,
Chris
You should set Ignore Import Library in project A.
This option specifies that the (import) library generated by this configuration should not be imported into the dependent projects.
Related
It seems that since VS2010 and MSBuild 4.0, VisualStudio and MSBuild are able to resolve and build project references that are not located within the solution.
Let us create an example to be more concrete. Create a solution called Solution1 with a C# project named A and another project called B. In project B, add a reference to project A. Now create a new solution called Solution2 and click "Add Existing project" and select Project B. There is a warning that can be seen in Solution Explorer and the Warning List.
The trick is that even with "warning as error" we are able to build Solution2.sln. Actually, project A is found
and built by Visual Studio or MSBuild. Let us verify this by opening a VS2010/VS2012 command line and execute the following commands:
msbuild <dirPathToSolution1> Solution1.sln /t:clean **cleaning up solution1 with project A"
msbuild <dirPathToSolution1> Solution2.sln /t:build
ProjectA is effectively built and worse: the warning mentioned above is not even raised there. With previous versions of Visual Studio such situation could not happen (I have tested it with msbuild 3.5 and VS2008).
However, in our situation we would like to prevent such things. Indeed, we have a large source repository with several solutions and many committers. We are reorganizing our dependencies aiming finally to the extraction of smaller repositories. Meanwhile, we do not want developers to add hidden project dependencies without seeing it. We would like to allow only project references "inside" a solution, leaving other dependencies to assembly references.
So the question is "Is there a way, to prevent such solution such as Solution2 to build ?". Ideally, it should not compile with both VS2012 and MSBuild. However a solution involving only the MSBuild command line would do thanks to our Continous Integration.
edit I checked Microsoft.Common.Targets and there does not seem any way to achieve what you want. Either project references are built, or they are not (this is for instance influenced by the BuildProjectReferences flag of my original answer). There is no way to build them selectively depending on which solution they are in unless I'm missing something - which is mainly because project references are set on the project level, not on the solution level: in your project file there is an MsBuild ItemGroup named ProjectReferences and that is used. (Actually this makes some sense: if you ask MsBuild to build projectB.csproj, and B says it references A, then no solution comes into play and you could expect it to build A, after all you are referencing it).
Now as I understand it, you want to prohibit referencing across directories whose structure happens to be represented by solutions. If that is the case, and you really need this, you could probably get away with a tool that parses the MsBuild log and looks for lines like
Project "somedir\projectB.csproj" (2) is building "someOtherDir\projectA.csproj" (3) ...
then extract the directory info from it and make the tool raise an error when they do not match. Then incorporate the tool in your CI server and feed it with the msbuild log files.
original answer
Try with /p:BuildProjectReferences=false on the command line. As the name suggests it will disable building of referenced projects. When building solution1, this should not be a problem since projectA will be built anyway as it is in the solution. However when building solution2, it won't build projectA and you'll get a build error.
I've been developing for iOS for over a year now, and in the last few projects, I've been using other projects, such as RestKit or SSZipArchive to name a few. When doing these projects, I would include these projects as cross-referenced in the workspace underneath my main project.
What I find baffling about the process is that this is unlike any other language that I have encountered. Normally, in other languages, I take compiled output files from a project (.dlls or .jars, for example) and those are included in a project. I know that when you build a static library in Xcode, the resulting file is a lib*.a file.
What is the reason for keeping these projects cross-referenced as opposed to just copying the lib*.a files into the project?
What is the reason for keeping these projects cross-referenced as
opposed to just copying the lib*.a files into the project?
Sounds like you're talking about adding the library project as a subproject. The reason for doing it is to set up a dependency between your project and the subproject. If changes are made to the subproject, Xcode will rebuild your main project so that the newest version of the library is incorporated.
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.
I saw the suggested link :
What is the difference between a "build" and a "rebuild" in Visual Studio?
in stackOverflow but theres something strange :
I have project with many library dlls. ( projects)
If i add even a space into one *.cs file , and press build on th project - it scans all
the files in the project ( i see some outbput message for the other files - meaning that it scans them)
but in the article it says - ONLY THE CHANGED FILE
my inspection is : ALL THE SPECIFC PROJECT FILES WHERE THE ALTERED CS FILE
p.s. : what about reference to other projects? Does they always rebuild ?
i.e. : Project DLL A has reference to Project Dll B
when i Build A - does B also REbuilds ?
Rebuild is a COMPLETE "Clean" (remove previous binaries) and Build each project, as per the order of Dependency
Build is based on changed files + Dependency
The fact that it scans all projects in your solution when you put a space to a *.cs file implies that this particular file is in a Core project where other projects are dependent upon
Project DLL A is built will trigger a build on Project B, since B is dependent