I am trying to integrate one application into another and I thought that a simple way of doing this may be to add the one application into another. (Simply going to File->Add Files to "Project")
However, when I do this and try to use files that are in that other project, it says that the files can not be found. Am I doing something wrong, or is doing this even the correct way of going about this?
Depending on what you're trying to do, you could either just import the source files (not the project file itself), or you could make the part of the original project you want to use into a framework (library). Then you import the entire framework in one step.
You just add the project (project A) and configure it as a dependency of the app (project B).
If it's iOS, you likely want to deal with this shared program using a library.
If OS X, then you still need to link to what symbols you reference (e.g. create a library). If you just want to bundle a helper app or executable with your app, add it as a dependency, then you'll probably want to copy the product (project A.app) as a resource to your bundle of project B.app. If you only want to build or test, then a simple dependency will do.
If you're really sharing sources, look into using a library (static, dynamic, framework) rather than copying your sources or their references.
Related
[UPDATE 03/04/2015]
The question is now 4 years old, and applies to a specific version of XCode which I have now specified in the subject.
I have searched a lot for this argument, but I couldn't find a solution, I even post on stackoverflow, but I soon deleted the question becuase of very little access.
Now I am trying again.
I have a workspace with two distinct projects A and B.
B has two targets, one that build a static library Blib.a, and one that build a bundle B.bundle. All of them get built in the derived directory.
In project A I can easily add the static library from the build phases. However I cannot find a way to include the bundle. B.bundle is not visible from "copy resource" tab in A.
Therefore I need to add manually, with all that implies.
I also thought about using a script, but I would like to use this as a very last option.
Has someone a solution for this ? Did I miss something ?
thanks
After long investigation, it came up there's no easy way of doing this. The B.bundle is never visible to A project, and there's no settings in workspace to change that.
At this point there are three solutions:
Include the bundle manually from "copy resources->other", I started with this, but everytime there's a change you have to drop and include the bundle again
Create a script to be run in build phase, if everything is built into the PRODUCTS dir you can find the bundle easily and having copied automatically into the app.bundle. This is not a bad solution. If you are using svn the script got included in project, and users have it for free without additional work.
As suggested by Apple tech support, use folder references.Build bundle B into a folder and add such folder to project A using the "Create Folder References for any added folders" option. Xcode 4 will update your bundle into that folder every time you built it.
The added folder will appear as blue once included in your project A.
Thats's it, I personally use the script, because this solution is path independent if you use standard xcode reference variable such as BUILT_PRODUCTS_DIR and so on, and the shell script is just a cp -r-f
[UPDATE 03/04/2015]
I would like to point out that the question is now 4 years old. At that time there weren't many "official" options available. I even spoke with Apple Tech Support, which proposed solution 3 as the only available solution. It is of course very likely that things are now changed, and there is a much better solution. Just to speak, I also like to add that the three above are not "hacks" but "solutions", maybe technically outdated, but they can still be used nowadays. I intend a "hack" as a..."hack", which means it probably not going to work in future software release.
Here is how I did it.
Drag and drop B.bundle from Project B → Products → B.bundle into the Copy Bundle Resources build phase of your app in Project A (select the Create groups options when asked). This will add B.bundle at the root of your Project A outline. You can move it into the Frameworks directory near Blib.a if it you prefer.
Select B.bundle and check its Location in the Identity and Type right panel (Utilities area). By default, Xcode chooses Relative to Project. This is wrong, select Relative to Build Products instead.
The path to B.bundle will now look something like ../../../../../../../../Projects/MyApp/B.bundle. This is not what you want, but you can easily fix it. Open ProjectA.xcodeproj/project.pbxproj in a text editor, search for this path and delete everything in it except for B.bundle. Your project.pbxproj should look like this:
explicitFileType = wrapper.cfbundle; name = B.bundle; path = "B.bundle"; sourceTree = BUILT_PRODUCTS_DIR; };
Save your project.pbxproj file. Xcode will automatically reload your project and your app should build just fine.
After searching for a long time and failing many times, I found this resource that has been an absolutely great tutorial to create Static Libraries and include bundles in your main project or even for distribution to 3rd party developers that may consume your library.
Absolutely recommended:
https://github.com/jverkoey/iOS-Framework
In project A, is the product of project B a dependency in your scheme's Build action? I think you might have to set up this dependency (sometimes disabling the automatic dependency discovery option is best) for it to show up and be available for copying into another target. I believe this is because it doesn't really exist (like an image resource file) until it's built and Xcode needs to ensure it's built before working with it from another target.
As of Xcode 5.1.1 I was able to drag and drop B.bundle from the Project Navigator to the Copy Bundle Resources list of project A Build Phases. I assume creating B.bundle target is not an issue.
Switch build to Generic iOS Device. This step is needed to create a non-simulator reference.
Drag the .bundle to the other project's Copy Bundle Resources.
Select the .bundle in the Project navigator of the other project, and change its Location to Relative to Build Products
Make sure your .bundle in added to Target Dependencies of your static library
My solution has a library project which needs a special environment to be built (lots of external libraries and tools)... but it is not vital to our application. We'd like to avoid installing these tools when not necessary (most of our developers work on other parts of code).
We have created another project which has the same API, but has an empty implementation and is compilable without those external tools. I'd like to be able to easily switch between those projects and still get all the references in other projects correct.
I don't know VS/MSBuild very well, but willing to learn whatever is necessary. Is it possible? I am looking for ideas... We're using Subversion, and solutions involving some hacks inside VCS are also welcome.
It sounds as if your library project is one that can be separated from your primary solution, taking the tool baggage with it. Doing that, you could build the speciality solution separately, an link the compiled assembly from the main solution.
Create another build-configuration for your project.
So you will have at least 2 build-configurations e.g. Debug_SpecialNeeds and Debug.
For discussion, I'll assume you have a project directory containing your solution file, a "RealLibrary\RealLibrary.csproj" project file (your "real" library, with the dependencies), and a "MockLibrary\MockLibrary.csproj" file (your "mock" library, with the empty implementations).
If I understand correctly, you want to easily "swap" the MockLibrary for the RealLibrary in your solution, and vice-versa.
The easiest/hackiest way to do this, assuming your solution (and dependent projects) are configured to look for the "RealLibrary.csproj" project, is to rename the "RealLibrary" directory (it doesn't matter to what), and rename the "MockLibrary" directory to "RealLibrary" and rename "MockLibrary.csproj" to "RealLibrary.csproj". This will effectively "trick" your solution and dependent projects into loading the "mock library" even though they are referencing the "real library".
A slightly more complex (and perhaps cleaner) solution is to actually modify your "sln" and "csproj" files to reference "MockLibrary.csproj" instead of "RealLibrary.csproj". In the "sln" file, you'll need to change the path to the project in the section near the top:
Microsoft Visual Studio Solution File, Format Version 10.00
# Visual Studio 2008
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "RealLibrary", "RealLibrary\RealLibrary.csproj", "{E1714F9A-E1D9-4132-A561-AE2B4919391C}"
EndProject
You need to change that path "RealLibrary\RealLibrary.csproj" to "MockLibrary\MockLibrary.csproj". If you're going for completeness, you can change the name as well (or perhaps just use a generic name like "Library" for the name).
Likewise, in the dependent csproj files, you'll need to find all instances of the "ProjectReference" node where you reference "RealLibrary.csproj" and modify the path. These sections look like this:
<ProjectReference Include="..\RealLibrary\RealLibrary.csproj">
<Project>{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}</Project>
<Name>RealLibrary</Name>
</ProjectReference>
You could relatively easily write some scripts to perform this swap. However, I think there's a deeper problem here that can be addressed more directly. I'll post that as a separate answer, but I wanted you to have the actual answer you were looking for first.
The deeper problem I see here is that your library "needs a special environment to be built", specifically because it depends on "lots of external libraries and tools". I would suggest that you NOT go down the path of creating the mock library, but instead focus on getting the library to build correctly without a special environment. You can achieve this by including all of those dependencies in source control along with your project, and reference those dependencies via relative paths inside your working copy. In my build environments, I try to avoid static environmental dependencies as much as possible (ideally limiting it just to the .NET framework itself).
To get the dependencies into source control, you can either check them directly into the project itself, or you can check them into a different location and then "reference" them in your project via svn:external definitions. In my environment, I have a separate "bin" repository used just for these kind of third party library dependencies, and then many dependent projects can pull them in via externals.
If you can eliminate your library's build-time environmental dependencies, your build will be much more robust and it will be much easier for developers to work with the project.
Maybe that's silly, but I'm confused again when trying to find appropriate names for my projects.
I have a solution with two projects. First project is a library, which will be used by other libraries in the future, for creating plugins for my app. Second project is a exe, which uses first project to create GUI and do some stuff, eg. load plugins.
In similar situation, when one project is a dll and second is an exe, how do you choose names for each project?
Lets say, that I would like to peek a name GraphDemonstration. The exe should be GraphDemonstrationGUI and dll - GraphDemonstration? But exe is not just a GUI. So maybe GraphDemonstration for exe and GraphDemonstrationLib for dll?
I have had similar situation in the past. Maybe there is some kind of naming convention? I don't even know if my "problem" is related to VS only.
GraphDemonstration for your EXE is fine because it describes the purpose of the EXE. However, you said the library will be used by other projects later so the "GraphDemonstration" part of GraphDemonstrationLibrary may not be the best choice. Perhaps GraphLibrary, or GraphHelper, or maybe more specific depending on what is actually included in the library. For example, if the library handles instantiating an Excel object to generate a graph you could call it ExcelGraphHelper.dll.
If this is library of main class CSomeClass I name project SomeClassLibrary.
For projects smillary but non from main object.
I have been using the Codesmith framework NetTiers to generate a DAL etc., into a folder called, say, 'NetTiers', outside my main project's folder, and referencing the DLLs within that folder from my main project.
I've started using the Plinqo framework, and want to use the generated files from that framework within the same project as the one I'm using with NetTiers. (The reason I'm using both frameworks is that I want to get/learn the newer LINQ goodness from Plinqo, yet also have the familiar NetTiers code DAL, BLL syntax available, for compatibility.)
My question is: what's the best Visual Studio solution and file structure to use when using Codesmith templates like these? Should the frameworks' generated code be contained outside the main project and added as projects to the overall solution? Or should each template's generated code have its own solution? Should the generated files be within the main project's file structure?
I've tried combinations of each of these, and they each have their pros and cons. I'd like to know if there's a tried and tested pattern.
When it comes to .netTiers, I always compile the generated solution and add the assemblies as references to my project. This makes it much easier to upgrade/diff and regen.
However, there are going to be some cases where you would want to add your custom logic so keep this in mind.
Thanks
-Blake Niemyjski
I tend to just keep the .csp and the generated folder outside of my main app's folder. When adding a reference Visual Studio copies in the .DLLs from the built generated code. All of the generated projects sit under a main folder such as D:\CodeSmith Projects\
If you want to version control the .csp file it might be beneficial to move it in with the rest of your version controlled app files to tie it all together.
We put the generated projects inside our solution. In fact on my current project I generated the nettiers files to the location that I wanted the files to be, and Started adding my own project files to that...But we have always kept the files in the solution, that way if i need to add something to the code in the concrete classes I can do it without having to open a whole new project.
We have tried both scenarios. We settled for including the assemblies in a dependencies folder, which was shared by multiple projects.
We had problems with TFS when the projects were included in the solution. the downside, is that you can't so easily step into the .NetTiers generated code when debugging, though after a while you get used to this, and accept that whatever is in .NetTiers stays within .NetTiers!
I am writing a small application at the moment and am trying to organise my build output to be a little closer to the finished product. The application is made up of a number of different projects. There is a core library that contains most of the functionality, a GUI app and a command line app that both reference the Core Dll, and a number of Plugin Dlls that are loaded at runtime and implement different data sources, these all reference core.dll, these also may include some other third party dlls. There are also a number of peripheral files such as a readme. And finally the core.dll and the datasource plugins are unit tested.
I would like to configure my build so that everything is output into directories as I would expect it to be when installed. I want debug and release builds to be built into different directories but otherwise have the same directory structure. I only want tests to be built for debug builds, and want them to be runnable, but seperated (I guess all test dlls would get output into a seperate directory). Here is how I imagine the structure will be.
Code/
solutions etc here
Debug/
Project.Core.dll
Project.Gui.exe
Project.Cli.exe
readme.txt
lib/
ThirdParty1.dll
ThirdParty2.dll
DataSource/
DataSource1.dll
DataSource2.dll
Tests/
Project.Core.Tests.dll
DataSource1.Tests.dll
Release/
same as Debug but without tests.
Is there any way of getting a solution to build like this? I'm beginning to think it will be difficult to build the plugins and the app all from one solution, and probably not even wise, but as they will all be distributed together it would be nice. I am open to using Nant or another build tool if that will make it simpler.
It is possible. Just modify OutputPath tag manually in each .csproj in both Debug and Release file to something like this
<OutputPath>..\$(Configuration)\any_subdirs</OutputPath>
You can disable tests building for Release using Configuration manager.
Modifying each project every time you create a new one is annoying.
Here's the solution:
Locate the real vs project, it'll be somewhere under ("%programfiles(x86)%\Microsoft Visual Studio 10.0\Common7\IDE\ProjectTemplates*")
Copy it locally somewhere.
Extract it.
Edit the contents making changes that better suit your project layout style. Make sure you update the project name, the name is what you see when looking for the project in the new project dialogue box. It's xml tag is Name, you'll find it in the {something}.vstemplate file.
Compress the content again. (Note: the contents must NOT be in a sub folder, so /* and NOT /{somefolder}/*).
Place your custom project under ("%USERPROFILE%\Documents\Visual Studio 2010\Templates\ProjectTemplates*").
Add a new project is Visual Studio, selecting your custom one, and enjoy!