Swapping Managed libraries in standalone to switch between development_build being enabled

Unity Engine
1

Hi,

So I had this thought today. Is there any good reason not to swap the entire ‘Managed’ folder ( i.e all the Unity compiled dlls for your project) between the same versions of a built standalone project?

Specially, if you have a project to be built as a standalone ( i.e. Win or OSX ) and want both a release and a development build, but not the overhead of two copies or managing two versions. Is there any good reason for not doing the following;

  • Build Release version.
  • Build Development build version.
  • Duplicate or zip up the ‘Managed’ folder for each version so you have a backup.
  • Delete the Development build version.

Now when running the project, by simply unzipping in place the desired ‘managed’ folder back up you can quickly switch the project between release and development build code.

I’ve made some quick tests and it seems to work fine, indeed I can’t think of a good reason it wouldn’t.

The only difference is that it would appear Debug.isDebugBuild remains false even when swapping in the development build version of the dll’s. However that isn’t much of an issue as I don’t use that for reasons i’ll explain below.

So why not just have two distinct versions of the project?
It doubles storage and transfer requirements when often the code base is just a few MB, but more importantly its more awkward to keep track of, you have to rename one to make it clear its a development build, you have to make sure you have both versions around and they are of the same version of the project.

More specifically in my case due to my client work being done off-site and at long distance it would be highly beneficial to be able to just replace the smaller ‘managed’ folder than send two visions of the whole project. This is especially true for kiosk installations that can often be worked on right up to going live.

By having both versions of the Managed folder zipped up and within the project Data folder you keep both versions of the code together and in-place unzipping makes switching between them easy and quick.

So why the need for a development build?
Having a development build is useful for testing, QA and bug hunting. It can log large amounts of information that you may not want or may adversely affect performance in a release version. Though i’m also aware that the very act of having different code paths and essentially two versions of the code can introduce its own errors, it still still seems like the better option.

One issue is that (AFAIK) Unity does not strip calls to Debug class when compiling for release. It even recommends using ‘if(Debug.isDebugBuild) Debug.Log(“hello”)’ to avoid calling Debug.log and while this certainly replaces a potentially very expensive call ( especially with stacktracing) with a cheaper conditional check, its still a needless cost, not to mention looking bad and increasing code complexity. i.e. it takes just that little bit longer to process what a line of code is doing when you read it. Not to mention i frequently would prefer to have specific conditional checks for specific types of debug.log messages I want to emit so now you have to write ‘if(Debug.isDebugBuild && enableHelloLogs) Debug.Log(“hello”)’.

One alternative is to wrap your Debug.Log calls within a define, so it becomes a compiler time check, but this often looks even worse and requires considerably more code lines and additional effort when coding.

A far ( in my mind) superior option is to use c# ‘[Conditional (MY_DEFINE)]’ attribute, which when compiled will not remove the method ( good for compiler code validation), but will remove calls to it should the define not be present. Its a very clean, efficient approach both in terms of coding and computation.

Of course to utilize this you have to wrap Unity debug calls within your own debug class so you can apply the condition attribute to your methods. Which in turn sadly means you lose the ability to open up the script from the Unity console as it will always go to your debug class and not the class that called it, but its not too bad.

You could even go further and make multiple development builds that have different compilation defines to further tailor the amount of information logged.

2

I’d imagine this should work just fine. When making a PS4 build on our project, there is an option to just do a “Script Build”, which retains all the assets and just re-compiles the scripts. This is sort of what you want to achieve, just doing it manually. I’m assuming however that there are some changes done to the EXE file itself, which is where the Debug.isDebugBuild flag is defined, so perhaps swapping that file as well will give you all the functionality you need.
Essentially you are creating a separation between the assets and code, which unity supports (ie AssetBundles) so I can’t think of any issues that might arise (especially if you swap out the EXE file).

1 Like
3

Thanks for your reply.

What you’ve written matches my assumptions, but its nice to know about the PS4 having a script build option as that lends even more weight. As you say assets and code are separated in Unity, though sometimes I wish they weren’t, and that is where my initial assumption came from.

Good point about the exe probably containing the isDebugBuild, I’ll test swapping that too. Though in my case I doubt I will use it as half the point of just swapping the managed dlls is to avoid having two different exe’s since we have systems in place to re-run the exe if it detects a crash on the kiosk ( rarely happens ) and thus its simpler to stick with a single exe.

4

There might be other things defined in the EXE that could affect running a successful debug build. I’m not sure exactly how symbols are loaded in C#, but your PTB files could be excluded when loading a release build, so debug info could be missing (at the minimum). Might have other effects as well, so I guess if I was implementing this, I would vote to swapping out the exe as well.

1 Like