Okay so here is my situation:
Project A is in solution A, lets call it's output a.dll.
Project B is in solution B, lets call it's output b.exe.
Project B references a.dll
Both solutions are under source code control in different repositories.
My question is: how can i assure that Project A's output gets redirected to project B's "External references" folder, overriding the previous version of a.dll, regardless of what the local developers path structure looks like, is there a way to do this? alternatively could solution A, invoke the build of solution B and then copy it's output locally?
To be brief, automating builds accross solutions without a 'common directory structure' is possible through the use of:
commandline parameters
environment variables
I would encourage you however to consider the "Convention over Configuration" mantra and think up a convention about the relative positions of solutions A and B.
Furthermore it's possible to build projects and solutions using the MSBuild task. The binaries can be copied to your "External references" folder using the Copy task.
Related
Situation: An application, that is built into several variations, with different functionality enabled. Each variation has its own main project, with its own output "bin" folder. Call the variations A and B.
There are various common class libraries, which generate dlls. Those all get automatically copied to both output folders. This is working fine.
Now, add another project. It generates an exe, C.exe. It will be loaded as a separate process by the application. (It creates a NamedPipe, providing a ServiceContract via NetNamedPipedBinding.)
When there was only "A" (no "B"), I simply had A and C specify the same output folder.
But now there are TWO places that C needs to go.
For Debug build, must go to A/bin/Debug and B/bin/Debug. Similar for Release build.
The source language is VB, but an answer based on C# projects would almost certainly be adaptable to my situation.
I've written an answer by using XCopy in Post Build Events.
Looking for alternative answers.
Is there a way that is easier to maintain / not dependent on manually entering paths?
My concern is that as variants are added, or moved around, it is necessary to know about the Build Events and manually edit them.
Doing work for a company that is not great at keeping track of such details over the years.
Looking for a way that is less likely to break, or easier for a junior programmer to maintain.
In Project "C", Properties, Post Build Events, use xcopy to copy the .exe and corresponding .pdb. Do this for both the "Debug" configuration and the "Release" configuration of Project C.
(For VB, this is under Compile tab, "Build Events..." button at lower right.)
In project A's Properties, find what its output path is. in this case, the path specified was bin\x86\Debug\. xcopy needs to be told this path, relative to project A inside the solution; this becomes $(SolutionDir)\A\bin\x86\Debug\. The resulting lines, to copy both the exe and its pdb for debugging:
xcopy /y "$(ProjectDir)$(OutDir)*" "$(SolutionDir)\A\bin\x86\Debug\"
This copies ALL files in "C"s output folder to "A"s output folder.
Before adding this line, examine "C"s output folder. Are there any files in it that should not be copied to A? If so, can they be deleted? (And will they STAY deleted, when you rebuild "C"?) If not, you will need to specify more carefully the source files, in xcopy line. Or use multiple xcopy lines, to specify the individual files.
Note the "A", which is the main project being copied to.
Repeat that line for "B".
As more variants of main project are created, add a line for them as well.
If one project specifies a different output path, then the lines need to be correspondingly changed.
A is a module project. There are some test targets and the relevant reusable code is compiled in a separate (static library) target. A uses the third party Lumberjack logging library. The Lumberjack code was simply dropped into the project.
B is a different module project, but otherwise it has the same properties as A.
C is the main project. It depends on A and B. It links the libraries of A and B.
Compiling C will result in duplicate Lumberjack symbols.
How can I have multiple separate module projects so that...
they don't know of each other,
use the same third party code,
can be compiled and tested on their own,
included in a main project without duplicate issues?
So, to elaborate on sergio's answer, I was able to succesfully build a test setup as follows.
I included the Lumberjack code in a separate project that builds Lumberjack as a static library.
I created a new project ProjectA with a static library target ModuleA and a test app target DemoA. I copied the Lumberjack project folder into the project folder of ProjectA and then added it as a subproject. I didn't make ModuleA dependent on Lumberjack or link Lumberjack in ModuleA. Instead, I made DemoA dependent on both and link both libraries. This way, I am able to compile the test target, but the library target doesn't include Lumberjack.
I created a second project ProjectB with the analogue setup as ProjectA.
In the main project, I included ProjectA, ProjectB and Lumberjack as subprojects. Unfortunately this will make Lumberjack included 3 times in the main project, which is a little bit inconvenient and ugly (for instance when selecting dependent targets, you can't really tell which one is which).
Finally, I made the main project's target dependent on Lumberjack, ModuleA and ModuleB and link all three libraries. Now, the main project can compile without duplicate symbol error and the submodules can also be compiled and tested on their own.
Since you are targeting OSX, the solution to your issue is building Lumberjack as a framework (as opposed to link the sources code in your A and B modules) and then using that framework wherever it is required (i.e., in any project using A or B modules).
Indeed, Lumberjack already includes a project that will build a Lumberjack.framework, check this: CocoaLumberjack/Xcode/LumberjackFramework/Desktop/Lumberjack.xcodeproj.
Elaborating more on this, you would define your A and B modules as you are doing now, but without dropping Lumberjack source code in it.
What you do instead is, whenever you want to use the A static library in a executable (say, your test target), you add the library to the target and also the lumberjack framework (exactly as you do with OSX SDK frameworks).
Adding the dynamic framework is just a different way to "drop the sources", if you want, but done properly.
When you want to use both A and B in a C project, you add both static libraries and your Lumberjack framework to C.
As you can see, this way of doing will comply with all your four requirements, at the expense of introducing one dependency: you need to make clear in your static libraries documentation that they depend on the Lumberjack framework. This is actually not a big issue, since the latter is available in its own project and any one will be able to build it on his own.
If you want to improve on the handling of this dependencies, cocoapods are the way to go (a cocoapod is a file associated to your library which describes its dependencies, so when you install your library, the cocoapods system will automatically install also the dependencies). But this is highly optional. One single dependency is not a big issue to document or comply with.
Hope this answers your question.
I hate to reference an existing answer but here's one solution that's cumbersome but works: What is the best way to solve an Objective-C namespace collision?
I have this same problem and I'm working on a better solution though. Another idea that might work but I'm not yet sure how to implement it I asked here: Selectively loading classes in Objective-C
A third idea I had because of something someone said on my question was to wrap one of the libraries in a framework and create functions that reference the functions you need. Then load using something like #import <myFramework/MFMyAliases.h>
Have you tried looking at the libraries with ar? If you are very lucky, running for example
ar -t libA.a
gives you a list of files like
__.SYMDEF SORTED
Afile1.o
Afile2.o
Lumberjack1.o
Lumberjack2.o
Afile3.o
SomeOtherLibrary.o
where the Lumberjack files are clearly separable from the rest. Then, you can kick them out
with
a -d Lumberjack1.o Lumberjack2.o
and link C against this trimmed library while using the full library when testing A alone.
I was trying to achieve the same thing before few months and "Easy, Modular Code Sharing Across iPhone Apps: Static Libraries and Cross-Project References" article got all what i needed. please check it out if its useful.
Are A and B binaries?
If not you could simply uncheck the compile checkbox for all *.m files of one of the projects, so as to avoid building duplicate objects.
Also if you could use A and B thorough Cocoapods it would be best.
Try this.
It is sharing libraries/modules between different projects.
So in the least clear question title ever, what I'm trying to describe is a situation like so:
Project A, with files that have "Copy output" set to "Only if newer" (or "Always", it doesn't matter in this case).
Project B which has Project A as a dependency.
The files marked as "Copy output" only get copied to Project A's output directory, but I also want them to be copied to Project B, since Project B relies on them.
Is there any way to do this while maintaining MonoDevelop compatibility? (MonoDevelop does not use MSBuild or Mono's equivalent for doing actual builds, so any solution has to be one that doesn't use custom MSBuild steps)
I'm not super familiar with Mono. Do "Post Build Events" work there?
In the properties of ProjectA, go to properties.
Go to "Build Events"
Add this event:
copy $(TargetDir)ProjectAAssemblyName.dll $(ProjectDir)..\ProjectBThirdPartyReferences\ProjectAAssemblyName.dll
Then inside of ProjectB, reference \ProjectBThirdPartyReferences\ProjectAAssemblyName.dll
You may have to tweak the paths a bit.
My advise is to NOT copy ProjectAAssemblyName.dll to the \bin\ folder of ProjectB.
.........
My problem boils down to this base case: our solution has two projects, A and B, which project C then includes into its build process.
When someone pushes to project A or B, Jenkins builds the project using MSBuild, archives the artifact, and then kicks off a build of C.
When C begins, it has four "Copy Artifacts" tasks that need to run: first, it copies the artifacts from A into .\A\obj\Release\, then it copies the same artifacts into .\A\bin\Release. Then it repeats for project B. Then it builds itself.
That's right: for each project C relies on, Copy Artifacts has to be run twice, or else MSBuild detects that something is out of date and the whole thing is built from scratch.
Is there an easier way to do this? Can I pass a parameter to MSBuild (or configure the .csproj) that says "only build this project, assume the other project binaries are up-to-date, regardless of the timestamp"? Is there a better plugin that will take care of this for me?
This is really annoying (and confusing) in our real-world case where we've got almost 20 different projects, with layered dependencies between them.
You can pass BuildProjectReferences=false into MSBuild to tell it to skip auto-building references and just build the project indicated.
I just banged my head for a while and figured out a solution, but I want to make sure that I'm doing things right and that I actually know what I'm doing (I'm pretty sure I never know what I'm doing :)
I have two projects that I've been working on, each offering different functionality. I want one project (A) to be able to use the functionality of the other (B). I tried going about it by creating a workspace and putting both projects into it, but I couldn't "see" project B's files from project A (autocomplete after #import did work, but it gave a compiler error). So I tried adding it as a "sub-project" and found the same. I figured this would be easy, but guess not.
What I ended up doing was creating a new project (C) as a "Cocoa Touch Static Library" project, and put my files from Project B into it. I built it.
I then went back to project A and added project C into it as a sub-project.
Then I added the path on the filesystem of project C into the User Header Search Paths setting under Build Settings of project A.
Then I added the .a file from Project C into the Link Binary with Libraries section of Project A.
Then it worked.
But honestly I have no idea what the meaning of a static library is.
Is all this necessary? Or is there an easier way to just integrate two projects (without me having to copy the files from one project to another)?
Thanks in advance!
Jon
You were on the right track with workspaces. What I do is have three projects in the workspace. One with no targets just to hold the generic classes. A second for my iOS target Project. And a third for mac. Keep the original files in the one with no target, then drag the files to the other two projects that creates references, so when you edit one it changes all three.