I am trying to add an external project to my unity solution.
It works fine using mono develop but whenever I switch back to unity it seems to remove the reference from the solution.
Is there a way to prevent unity from doing this ?
Thanks,
Unity rebuilds (i.e., removes the existing file and build it again from scratch) MyProject.sln file whenever it finds changes from ~/Assets folder. As such, any manual modification done by you or outside Unity's automated process on MyProject.sln will be discarded each time Unity compiles.
As #Kamalen mentioned, the usual way to import an external project is to have the external project be a library project, build *.dll from it, and put the *.dll file somewhere under ~/Assets. When there are *.dll files under ~/Assets, you have a reference to the classes and methods defined in the library file from any code you put under ~/Assets.
However, it seems that you have the access to the source code and tend to modify the external project often from your comment.
In that case, you could consider putting the source code of the external project under ~/Assets. The folder structure would then look like:
MyProject/
MyProject/MyProject.sln // this is rebuilt again each time by Unity
MyProject/Assets/
MyProject/Assets/ExternalProject/... // This could be a git submodule
MyProject/Assets/scripts/...
You can of course have the ExternalProject be a git submodule and maintain it as a separate git repo. Then you can either make changes to the ExternalProject from inside Untiy folder, or the original location of ExternalProject and then sync the ExternalProject under Unity folder with a pull from git.
As a rule of thumb, import *.dll files if you know the library is complete and it is unlikely to have changes in the library project, which includes the case when you do not have access to its source code. When there exist *.dll files in a project, it's common to assume the library is complete, unlikely to change, and outside of our control, and hence it's called an external project.
Your best way to have an external project into Unity is to... not have an external project directly. Unity does rebuild the solution file regulary and is almost like a temporary file.
What you can do is configure your external project as a library project, and configure the project (or an external tool) to output the generated DLL in any subfolder of the Assets folder.
If your external project uses Unity classes, it will need to have references to UnityEngine.dll and UnityEditor.dll, located in folders :
Applications/Unity.app/Contents/Frameworks/Managed/UnityEngine.dll for Mac
Program Files\Unity\Editor\Data\Managed\UnityEngine.dll for Windows
Related
I am trying to compile several scripts in my project into an easier to move and manage DLL file, however several scripts call UnityEngine.UI, and I know that the DLL file used to exist in /Contents/UnityExtensions/Unity/GUISystem/Editor/UnityEditor.UI.dll however the only data I can find for it now are the uncompiled files inside the Package Manager, where is the compiled DLL stored now?
The simplest answer that I just found is to look in the project folder of one of your projects in Library\ScriptAssemblies
In most examples I see the paths to the files are relative ("Assets/Models/monster.fbx"), and this seems to work fine. But is it possible to have a file from outside my project included in a package? ("/Users/angrymonkey/Documents/dragon.fbx")
I'm doing this by code btw, not from the IDE. So I want to refer to files outside my current project from code.
I am currently working on an effort which makes use of Windriver's Workbench tool, which I understand is built on top of Eclipse.
Our source control tool is ClearCase and we are working primarily out of snapshot views located on the workstations of individual developers. As a result the absolute path for each developer's view is different. As deeply nested relative paths can be somewhat cumbersome (e.g. ../../../../../Some_Package/src/) we are using a Linked Resource PROGRAM_ROOT_PATH which identifies the particular view directory for a given developer.
This is working relatively well for for referencing header and library directories in the build properties, but we are trying to reference that Linked Resource from our build scripts in order to do build post processing such as copying the compiled program to a release area.
Accessing the Linked Resource as though it were an environmental variable appears to be the wrong thing to do as $(SOURCE_ROOT_PATH) provides an empty string. Is there a way to access this information from Eclipse / Workbench from a makefile?
Look inside the .classpath and .project files in the root of your workspace project - I believe the linked resource should be defined in one or the other of those (probably .classpath). From your script (you don't mention if it is Ant, Maven, Gradle, etc.) you should be able to find a way to get that value out of the .classpath (through some plugin or custom code).
We use Eclipse, ClearCase, and Ant. The easiest way I have found to share projects is to include the .project, .classpath, and build.xml files in the top level of the project in ClearCase. Then when you create your view, mount it in your Eclipse workspace, and do a File -> Import, then choose Existing Project from the popup. Browse to the top-level of the project in the view and import it.
The paths in the build.xml and .classpath are relative from that point down, so it doesn't matter what the absolute path is up to the project. For example, your build will define your source directory as something like ./src/java, test directory as ./test/java, etc. Whether your absolute path is c:\workspace\project or /home/someuser/project or whatever doesn't matter to your build script.
I'm working with an open source library that's made available as a git repository (XML-RPC) and I'd like to use it in an iPad application. As I understand it, iOS applications should use static libraries for their linking.
Since this comes as a dynamic library, how can I convert it to something I can link with my app and use?
Maybe naive answer but why not just add all the relevent files in the repository to your app and just build it?
Put the files in a seperate folder obviously so you can update them to a newer version if you need to etc. Lots of projects I've done have an 'external' folder that just contains codethat I use from 3rd party sources. I've usually got the source so just compile it into my app and don't bother with making it a library.
Or are there tricky conditions that need to be met to compile this code?
I ended up doing this in several steps:
First, I opened the library project in Xcode and created a new target for the static library. I then made a directory in the project folder called "XMLRPC" and moved all the header files to it. I deleted the now-red invalid references to the header files, and re-added them (but kept the box for copying them to the current folder unchecked).
I added this Xcode project to my main project with a relative reference. I opened my main app's target and added the library project as a direct dependency, and checked the "Always search user paths" option on my main app's target settings.
Lastly, I modified the general Xcode preferences to use a shared build directory. I haven't tried it without that since it was something I wanted anyways; it might not be necessary.
My revision control has two folders in it: one's my project, and the other's the library. The library is still under git control within mercurial; I'm hoping this doesn't cause any issues.
I have a bit of code for a dll that is needed by two or more projects in eclipse. Currently each project has a copy of the code and builds the DLL separately. I want to separate the dll code into a separate eclipse project so there is a common location. But I want to avoid the situation where we have to build the dll in the one project, then copy the dll back to the other projects and check the dll to each respective project. This will create a dll for each project that isn't traceable to the exact code that it was built with.
Is there a way to somehow symbolically link the dlls to another eclipse project that is using CVS as the version control system so that it is possible to tell which version of the code was used to create the dll? Am I making this too complicated or missing something obvious?
I thought about working sets in the package manager for eclipse, but I have to investigate more on how to use them with CVS to avoid making it a nightmare for the next person who checks it out and can't figure out why their project won't compile.
Thanks.
What about creating a new folder in a separate project. In the advanced section of creating a new folder there is an option to link to another location on the file system.
Or you could also create a container project that makes use of a projectset.psf file. Have the projectset file link to the different projects in your repository. When you want to check out that project, check out the container instead and right click on the projectset file and select Import Project Set...
If you are working with one workspace, you end up with three projects, each mirrored in CVS: One is the dll, the others are the projects using the dll (configured as a project dependency of these projects upon the dll project).
With three projects I wouldn't aim for working sets - they are good for managing a lot of projects within one workspace, for three projects, I'd consider them overkill. I usually tend to aim for several workspaces instead of working sets.
Regarding the next person working with these projects: You need to keep some kind of documentation about how to setup your projects. You might say that your eclipse project files do just that (as they define a project dependency upon another project) but this is for the machine - humans tend to like other communication means.
If you are worried about changes to the dll being incompatible to one project (because the person applying these changes doesn't care about the other project), aim for a build server. This will build all projects and dependent projects whenever something under version control changes, run all tests, provide a build number and package it all ready for use. This way you can be sure that - whatever is in your deliverable - can be reproduced, because the buildserver is not able to make local (uncommitted) changes to the code. Also a buildserver will signal failure (either broken API or broken tests) at the moment of the last commit (well - a few minutes later) and place the burden of repairing the damage on the one causing the damage.