koobas.hobune.stream
Only recompile scripts instead of full build?
Is there a way to only recompile scripts instead of rebuilding the whole project? E.g. if I have setup my whole game and I only want to insert a Debug.Log or similar it is really annoying to have to rebuild the whole project.
Would it be possible to use MonoDevelop to do the compilation and then replace an assembly in an .apk for example?
I still haven't found a solution for this. I am looking for a way to either change/update the C-Sharp Assembly or the resources.asset in an XCode project to avoid doing full rebuilds if no assets were changed between two builds. I tried doing a build without the resources folder and then insert the resources.asset from a previous build manually, but if I do so Unity can't find the assets from resources, so I guess there's something else happening at build time. :(
This is a good question indeed when your projects reach a certain size. Would like to know an answer to it myself.
I'm surprised that in the 2+ years that have elapsed since this question was asked that incremental building of a standalone .exe or "Published Build" (or even just recompiling code without touching any other assets of an already-built standalone exe) is still not supported by Unity.
This is a major problem on my current project, because: a) Unity Editor performance is drastically, unplayably worse than standalone exe performance (eg solid 60fps for a standalone exe, and 1-10fps in-Editor) b) at least two instances of the (networked) game are necessary to play (a client and a server) c) it takes 40-45 seconds to build our simplest test scene into a standalone exe (a full production level is much longer)
Thus, for most tests -- even after the simplest one line change -- I have a $$anonymous$$imum of a 40 second turnaround, when simply rebuilding the code takes 1-3 seconds. (The designers have to wait several $$anonymous$$utes per iteration!)
Still no word on this?
http://docs.unity3d.com/ScriptReference/BuildOptions.BuildScriptsOnly.html seems like just the thing, but rumour has it that it doesn't actually work.
On Windows, we've been copying Assembly-CSharp.dll and Assembly-CSharp.dll.mdb successfully for several weeks. For us it's more than ten times faster than rebuilding the whole project.
While I haven't tested the approach on OSX, I'd love to know if it works in that environment!
You do need to specially handle the UNITY_EDITOR #define to make the .dll compatible between the editor and the built player.
More details:
There's not much you can do about that. xcode have to crosscompile anyways. If it's just for debugging, you could implement a plugin interface and try to load an external assembly. This assembly can be changed
I thought ios does not allow external assemblies to be loaded during runtime? I don't $$anonymous$$d the xcode compilation process, it's the building of the resources folder that is so annoying...
Yes, that's right, iOS doesn't support reflection since it's AOT compiled. Do you just worry about an iOS project? That's not very clear in your question.
Personally i never tried to do something like that with xcode. Unity compiles the code into Arm assembler code which is then build by xcode. I'm not sure if you can trigger the compiling process for the code manually.
$$anonymous$$y original question is over a year old and back then I was working on an Android project, but now I have the same problem on ios, so ins$$anonymous$$d of creating a duplicate I just edited the original question. But I am looking for a platform independent solution that will allow me to make builds without rebuilding the assets everytime.
Just for reference: Since Unity 2017.1, there is now an option in the build settings to do exactly that.
Quick side note on this - we found that while this option does work, Unity blows away the Data/Raw folder under your iOS build during the process, which is where our Bundles from the Strea$$anonymous$$gAssets folder go. We found success copying that folder to a temporary location and copying it back after calling BuildPlayer.
Another Update: They are currently in the process of reworking the whole AssetBundle system. The new system "Addressable Assets" can be teste from 2018.2 onward:
https://forum.unity.com/threads/addressables-are-here.536304/
https://docs.unity3d.com/Packages/com.unity.addressables@0.3/manual/index.html
While addressable assets sounds quite useful, i don't think that this covers scripts just like AssetBundles can't contain scripts. You can put scripts into seperate assemblies which could be inlucded as pure binary data in an assetbundle and loaded through reflection. However script / code that is loaded this way has several restrictions when it comes to referencing the classes defined in such an assembly. Also dynamic loading of assemblies usually doesn't work on AoT platforms. So the main issue remains. Assemblies are not assets in the sense of Unity. A script from the assetdatabase point of view is just a TextAsset ($$anonymous$$onoScript) which is an editor only asset type. At runtime this asset type doesn't exist.
You are absolutely right, of course. $$anonymous$$y thinking (which I didn't make clear) was more along the lines of "You can perhaps alleviate the problem and speedup build times if you use Addressable Assets to have as many assets as possible make use of the Addressable Assets System, so that a normal Build will not re-process them unnecessarily."
AssetDatabase.ImportAsset(AssetDatabase.GUIDToAssetPath(AssetDatabase.FindAssets("t:Script")[0]));
How does this make you're not required to rebuild your project? All you do is reimporting the first script it finds which makes no sense at all.
