Search Unity

  1. Unity 2019.1 beta is now available.
    Dismiss Notice
  2. The Unity Pro & Visual Studio Professional Bundle gives you the tools you need to develop faster & collaborate more efficiently. Learn more.
    Dismiss Notice
  3. We're looking for insight from anyone who has experience with game testing to help us better Unity. Take our survey here. If chosen to participate you'll be entered into a sweepstake to win an Amazon gift card.
    Dismiss Notice
  4. On February 28th the Feedback website will shut down and be redirected to the Unity forums. See the full post for more information.
    Dismiss Notice
  5. Want to provide direct feedback to the Unity team? Join the Unity Advisory Panel.
    Dismiss Notice
  6. Unity 2018.3 is now released.
    Dismiss Notice
  7. Improve your Unity skills with a certified instructor in a private, interactive classroom. Watch the overview now.
    Dismiss Notice

Understanding the requirements to build and replace Unity UI dlls

Discussion in 'Unity UI & TextMesh Pro' started by Noisecrime, Jul 28, 2015.

  1. Noisecrime


    Apr 7, 2010
    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.

    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!

    Code (CSharp):
    1. Existing formatting in file
    2. public Navigation        navigation        { get { return m_Navigation; } set { if (SetPropertyUtility.SetStruct(ref m_Navigation, value))        OnSetProperty(); } }
    4. My line
    5. 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?


    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?

    Last edited: Jul 28, 2015
  2. Tim-C


    Unity Technologies

    Feb 6, 2010
    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 :( Best thing to do is NOT modify the dlls, but extend / change the classes yourself in a project.
    Noisecrime likes this.
  3. Noisecrime


    Apr 7, 2010
    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. harleywinks


    Nov 14, 2014
    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


    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?

  5. tylercook


    Apr 15, 2014
    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. tylercook


    Apr 15, 2014
    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. Piflik


    Sep 11, 2011
    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...