I have a set of utility classes that I reuse in several xcode projects.
I want to include the utility classes in every project.
I currently do this by adding inside every xcode project a group and dropping there the files from the file system.
This way, they are included in the compilation.
But every time I do filename changes in the utility classes (e.g. add/rename/delete a file) I have to go through all the projects and reflect the change there.
Some notes:
The projects are irrelevant, i.e. not different products from a suite of products. So I cannot use an all products project and do the separation at the targets level for each of the products.
When I do changes in a utility class from one of the projects, the changes should be reflected in all other projects.
the utility classes are already on a repo of their own.
I prefer not to make copies of the files of the utility classes inside every project
I do not want to do the trip of creating a framework that will then be used by every project. Not all classes are used by every project. I just want to have them compiled as a source files.
As a test, I made a project containing the utility classes and no target, added the project as a child of one of my projects.
I.e. instead of having the yellow folder icon of the file group, I have a project icon containing the files.
The compilation does not seem to pick these files.
Maybe a cmakelists.txt file could serve this purpose? I.e. give to xcode an additional list of files to include in the compilation?
For the Windows's edition of my projects, I use Microsoft's Visual Studio "shared items" project which accomplishes exactly all these requirements.
What is your advice for xcode?
Thanks!
Similar to:
Sharing classes between projects in xcode/objective-c
Sharing classes between Xcode projects
dll project for which i want to create unit tests.
In order to run unit tests i need my test project to compile all dependencies and i don't want to add my cpp files to test project.
The solution is to add lib in references but i have no clue how should i compile my project as both dll and as lib. Is this even possible ? I suggest that could be easy with naked cmake/make.
What i could do is create another project with same files and build it as a .lib. I think this solution is very primitive and it will require me to add .cpp files to projects twice if i ever want to add something new. I would prefer a solution in which i could have only one project in solution and have it build .dll (a main component) and a .lib for UT project reference.
I know i could also make UT load my .dll and have that kind of dynamic linkage, but that would make it harder due the need of creation of dll wrapper to access those functions.
I also considered using batch build and have custom build configuration. But this will require me to batch build every time i want to run UTs. I'd rather have it chose automaticaly. Maybe if i set UT project to be build under custom configuration the dependency will also be build with custom config?
Does Visual Studio 2015 bring any simple solution to this problem?
I have a project that is referenced by many dependent projects, and some files in that project that must be in the binary directory of the dependent projects for the dependent projects to run.
Currently, I have several custom AfterBuild targets defined: one in the referenced project to copy the necessary files to a shared location, and then one in each of the dependent projects to reach out and copy the files from the shared location to their bin directories. This works, but it's annoying to maintain and it feels brittle and hacky.
What I would like to achieve is to get my files worked into the primary project outputs for the referenced project (i.e. alongside the .dll and .pdb), such that the files are automatically copied to the dependent projects' output directories at build time via the MSBuild ProjectReference.
Is this possible? If so, what is the mechanism by which primary outputs are discovered and to which itemgroups must I add my files? Is MSBuild "hardcoded" to look only for .dll and .pdb?
For reference, I would consider myself somewhere above an MSBuild novice, but far below an MSBuild expert. I've read Hashimi's "Inside the Microsoft Build Engine," understood it mostly, and I've been able to dig through the MS targets files a couple of times for other tasks, with moderate success. This problem is beyond me so far, though.
Also, I have reviewed this similar-looking question, but it doesn't address project references; only producing additional files with a project.
I'm developing a plugin for Eclipse (4.2 on windows) that uses a bunch of external files (batch scripts, xml files, ecc).
I'm asking if there is a good method to manage those files inside the project in order to:
keep all the plugin resources inside the project for version control in SVN
possibly have an automated plugin installation (including those files outside the plugin jar)
Edit: Can an additional "Feature Project" be a solution?
Instead of having a project I would manage two: one for the plugin and one for the "feature" that references the plugin and gathers the non-plugin data.
In that case, I see that eclipse "Features" have an "installation" section (in "feature.xml"). How could I specify for each "non-plugin" file the install path location?
I'm using nested projects for this.
Create a parent project that will contain everything. For each sub-project, deactivate the default location when you create it and select the parent project's root folder instead.
Here is an example: http://git.eclipse.org/c/tmf/org.eclipse.xtext.git/tree/
It doesn't have a .project file in the root but having one doesn't hurt.
Just remember to import the sub-projects before you start working on them. Otherwise, you and Eclipse might get confused.
I have an msbuild project which builds a SLN file from visual studio which holds all the projects in (about 70+ project), and a lot of the projects are dependent on each other meaning they need to be build in order - sometimes a developer forgets to set the build order manually in visual studio in the solution file causing the msbuild on a clean solution to fail as something gets built out of order/cant find a dll.
Is there a way for msbuild to take all projects and work out the dependencies and build the projects in order, if there is how do i do this? using an MSBuild task? With current tries it seems to just build in the order it reads the projects in - if i pass in a list of project files+paths.
Currently the only way i can think to solve this is a external app which scans the proj files and references and then manually creates a solution each time.. but this seems overkill for such a simple thing.
Anyone solved / seen this before?
How are you calling MSBuild? If you point MSBuild to the solution file, it should be able to work out the dependencies. If you point it to individual project files, then it won't be able to resolve any project references.
If you don't use project references you can still control the dependency order in a solution by using the "Project Dependencies" dialog to manually set the dependencies.
While Project Dependencies are hard to maintain and not shared across .sln files, Project References are honoured and do dictate the order consistently - see the ResolveReferences task in Microsoft.Common.targets.
ASIDE: A 'friend of mine' may 'during a refactoring' have accidentally stubbed out their Build Task and it's DependsOnTargets linkage to the Microsoft.Common.targets ResolveReferences task and ended up with ProjectReferences not being honoured in ways that sound like the question here. If you read some of the posts, you might get the idea that it's all mad shaky - it's not; the shaky bits are the Project dependencies, not the Project references.
See this excellent MSDN Blog article by Dan Moseley that really explains the topic, including some useful workaround strategies. (via this mildly related issue with building xUnit.net).
If all of your dependent projects are in the solution and you are using Project references, Visual Studio should manage the dependencies for your and build in order of that dependency list.
It sounds like you are not using project references. I always recommend project references.
This is an old question but the issue was most likely that projects in the solution used direct references to dependent DLLs (Add Reference > select Browse tab > select dependent DLL) instead of using project references (Add Reference > select Projects tab > select dependent project). With direct references, Visual Studio can't figure out the dependency chain. You must tell it by right clicking on the solution node and select Properties. Pick Common Properties > Project Dependencies to set the required projects. Mr. Klaus is correct but I wanted to document how to fix this issue.
While it is correct that MSBuild should observe the build order when you use project dependencies there is one caveat. It doesn't at present observe the reverse build order when building the clean target (as I have blogged about here). For regular build however it works nicely as described by others here.
I am using Msbuild 4 found at c:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe
It seems to solve the problem.
There is no Microsoft tool that will examine all the dependencies of your 70+ projects and generate a solution file with dependencies clearly declared for you.
You have to do that on your own by using 2 different methods:
Manually specify a dependency, for the solution, in visual studio.
Specify a project reference in the project file itself.
If you don't want to do that, then you will have to swallow the medicine and accept that you will to use an external tool to do that for you. Yes it's clunky but it can be made to work. If you check in your solution file to your source control you can mitigate these problems. As long as you have an active solution file to work with.
I at one point didn't, and I had 600+ projects in the build. So I wrote a tool (years ago) that would automate 99% of this work. It uses the .NET MSBuild API's to read the msbuild files (no recreating the wheel here with xml api's). It then examines outputs and inputs and generate a dependency tree which I can then do a few things with it:
Spit out a solution file.
Do a dependency sort (also a topological sort in academia), and spit out those projects in order they should be built (for a non-parallel type of build, which can be useful sometimes).
print out all sorts of diagnostic information about dependencies.
The only limitation I have seen with the tool is with a few crazy COM dependencies which are pretty sketchy anyways. Which I added a super simple work-around.