Understanding the requirements to build and replace Unity UI dlls

Unity Engine
1

Hi,
I’ve been getting into the Unity UI system of late and finding I need to make modifications to the source code and thus rebuild the dll’s. However i’ve had very limited experience of building dll’s in the past and much of what I have done I appear to have forgotten, add in getting use to VS2013 and its all be rather confusing.

This has led me to a number of questions about the process which i’m hoping some kind souls can put me straight on since googling doesn’t provide any answers.

EditorConfig
It was easy enough to download and install editorconfig, however even after restarting VS2013 and reloading the UI project I find myself unsure if the formatting is actually correct. I would expect that when editing existing source files that tabbing should result in the same format/layout as the original, but that is not what i’m seeing. For example in the Selectable.cs file i’ve added a new public field but after the type decleration and tabbing to try and match the existing public field ( e.g. navigation entry) i’m always one character space short!

e.g.

Existing formatting in file
public Navigation        navigation        { get { return m_Navigation; } set { if (SetPropertyUtility.SetStruct(ref m_Navigation, value))        OnSetProperty(); } }

My line
public bool             navWrapAround     { get { return m_Navigation; } set { if (SetPropertyUtility.SetStruct(ref m_Navigation, value))        OnSetProperty(); } }

So is this correct? If not any idea what could be wrong?

Ok i’m obviously missing something here since whenever I alter a line VS2013 reformats removing all tabs. Will investigate further.

Location of dll’s to replace
So the readme explains where to replace the dlls, although the use of {Unity Version} at the end of the folder name seems wrong?

Data\UnityExtensions\Unity\GUISystem{UNITY_VERSION}

So here I would expect to find a version number folder within GUISystem ( i.e. GUISystem /Unity 5.1 or something), but there is none. Further more I wouldn’t expect per Unity version sub-folders at that level, not when the UnityExtensions folder itself is within a specific Unity application install. This would make senese to me if the UnityExtensions were stored in a user folder e.g. (AppData/Roaming or AppDataLocal or even User/Documents) and indeed having it split by version number in these places would certainly make the process of building, copying and keeping these extension dlls so much easier to work with. Afterall these days i’m finding i’m upgrading Unity very frequently, sometimes every two weeks with patch fixes and having to remember to replace those dll’s each time is a pain.

Hmm on further searching I’ve seen other posts where users have referenced the folder including a version number, so perhaps this behavior has changed ( using Unity 5.1.2 ) and the Unity UI readme has not been updated?

Additional files
However my real issue from looking in the Data\UnityExtensions\Unity\GUISystem\ folder is that it contains several files that are not mentioned in the readme and i’m unsure if anything must be done with these when updating dlls? For example we have

  • ivy.xml
  • UnityEngine.UI.dll.mdb
  • UnityEngine.UI.xml
  • UnityEditor.UI.dll.mdb
  • UnityEditor.UI.xml

What are these additional files and are they important? I guess that mdb is some debug database and the dll.xml files appear to provide text based loook up information for each class/method. However i’m unsure how to build these, certainly making a debug build in VS2013 doesn’t generate the mdb file ( you get a pdb as you might expect ).

Then there is the question of the ivy.xml file that includes guid values, but I can’t see this guid in the project files. Are these important? Are they meant to be linked to the dlls?

Plus in the Standalone subfolder we have what I thought were exact duplicates of UnityEngine.dll, but the filesize ( not size on disk ) is slightly different to those one level up in the directory?

So specific questions on this point

  1. Can I just replace the dll files in Data\UnityExtensions\Unity\GUISystem or should I somehow be regenerating the mdb, ivy.xml and other xml files?
  2. How to generate the mdb, ivy.xml and other xml files?
  3. Why is there an absolute size difference betwen the GUISystem UnityEngine.UI.dll and the one in Standalone?
  4. Are there any good methods for removing the pain of frequent uninstall/install new Unity version and thus losing you custom UI.dll’s?

Thanks

2

It is wrong. Fixed in the readme (this was from 4.6 and I didn’t realise we changed it). With regards to placing the DLL’s in a different location… we want to be able to override them by placing them in the project folder. We are not there yet.

  • ivy.xml -File that tells unity how to load the dll / dll GUID information
  • UnityEngine.UI.dll.mdb -debug database for the UI dll
  • UnityEngine.UI.xml -Documentation data for the dll (not sure how to rebuilt this as it’s build from our internal documentation tool). This allows for data in intellisense.
  • UnityEditor.UI.dll.mdb -debugdatabase
  • UnityEditor.UI.xml -Documentation data

We compile two UnityEngine.UI.dll’s. One with UNITY_EDITOR defined, the other without. One is used for the standalone, the other has embedded editor functionality.

Just replace

MDB will happen if you build from mono develop, don’t worry about the other two files.

See above

Not currently :frowning: Best thing to do is NOT modify the dlls, but extend / change the classes yourself in a project.

1 Like
3

Thanks for your Reply Tim, that has helped clear up a great deal of the questions.

With regards to mdb vs pdb are you saying in VS2013 I can simply dump the pdb into the folder as an alternative to mono’s mdb?

One aspect of that I forgot to mention is that wont the mdb/pdb only be built in debug config, but wouldn’t the final dll’s need to be release config? Is it actually possible to combine release dll’s with a previously exported debug mdb/pdb? Just a bit unclear of the process one should be following here, not helped by the fact i’;ve had limited experience using these db’s.

Thanks for clearing up the difference in file size, that was keeping me up at night, so I can sleep soundly now knowing why there is a difference.

Finally I assume that I don’t need to update the ivy.xml then? As I mentioned looking through the csproj properties in VS2013 I couldn’t see a guid defined which concerned me a bit. In testing this didn’t seem to matter, no errors in Unity when simply replacing just the dll’s, but I kind of figured a guid mentioned in the xml would relate to a guid used in the project when built or something.

Oh one last thing. How do developers work with making dll’s like this for Unity? Its simple enough to code/build/test, but seems rather inefficient. I’m wondering if its practical or possible to have the Unity UI project open in Unity itself for more streamlined developing testing, where by Unity compiles the source ( as it would normally with lose .cs files) then when you are happy everything is working use VS2013 or MD to build the dll.

4

I’m trying to create a custom version of the UnityEngine.UI module using the source from HG/instructions, but I’ve been unsuccessful at seeing my changes take effect in Unity itself.

My test:

  1. cloned the repo from HG (updated to 5.0.3 tag to match my unity version)
  2. Add a Debug.Log and/or throw Exception to StandaloneInputModule::Process (just to see I can change behavior)
  3. build all
  4. copy contents of Output to overrwrite contents of
    /Applications/Unity/Unity.app/Contents/UnityExtensions/Unity/GUISystem

Result:

Seems like it’s still not running off my modified module. I can’t even get it to print a debug log to console or to throw an exception.

I’ve checked the timestamps of the dlls and their location, etc.: all seems to be correct.

Am I missing something?

Thanks,
Larry

5

So it seems to me the README on BitBucket is still not correct. It tells you to still put things in a {UNITY_VERSION} folder.

Also, when i overwrite the files it is not running off my modified module either. (same issue as harleywinks). I am using Unity version 5.2.1p3

6

Any updates on this? I love that this side of Unity is open source and potentially replaceable.

I’d really like to be able to replace the UI DLL with my own if possible.

7

Is it possible yet to replace core dlls for a specific Project? If so, how?
If not, how would I go about changing a class for my project?

I made a change to ‘MaskableGraphic.cs’, but it is a collaborative project and I would like to be able to commit the changes to our repository instead of requiring everybody to replace their dll with my custom one every time they install a new Unity version. Placing the file into my project doesn’t work, since all UI-Components still use the dll-version to derive from. Having to implement all UI-Elements myself would not be an acceptable solution…