Search Unity

  1. Welcome to the Unity Forums! Please take the time to read our Code of Conduct to familiarize yourself with the forum rules and how to post constructively.
  2. We have updated the language to the Editor Terms based on feedback from our employees and community. Learn more.
    Dismiss Notice
  3. Join us on November 16th, 2023, between 1 pm and 9 pm CET for Ask the Experts Online on Discord and on Unity Discussions.
    Dismiss Notice

[Workaround found] Referencing UnityEngine.Networking in a managed plug-in

Discussion in 'Scripting' started by Twitwi, Feb 18, 2016.

  1. Twitwi

    Twitwi

    Joined:
    Apr 11, 2012
    Posts:
    22
    So I am currently developing my code by compiling it in visual studio, and then copying the .DLLs into Unity (i.e. http://docs.unity3d.com/Manual/UsingDLL.html).

    It has worked great, but I have stumbled into an issue. I wanted to use the new Networking library (which is a separate DLL). My code compiles, it gets copied into Unity, no errors, but every script I have written that references anything from UnityEngine.Networking disappears. By contrast: Every script that does not reference anything from the UnityEngine.Networking library is available inside Unity with no issues.

    I find this strange as I have been referencing UnityEngine.UI and using stuff from that and never had an issue.

    Is this a known issue or is it just me?
     
  2. zoran404

    zoran404

    Joined:
    Jan 11, 2015
    Posts:
    520
    Does the code really get compiled into the dll? You can check this using ilspy or similar software.

    Btw why do you do this? All the code you compile in unity will be put in a dll anyway.
     
  3. Twitwi

    Twitwi

    Joined:
    Apr 11, 2012
    Posts:
    22
    There are a few reasons to do this:
    Code (CSharp):
    1. // C# 6.0
    2. text = $"Something {count}/{max} Something";
    3. m_LobbyCamera?.gameObject.SetActive(false);
    4.  
    5. // is the same as
    6. text = string.Format("Something {0}/{1} Something", count, max);
    7. if (m_LobbyCamera != null)  m_LobbyCamera.gameObject.SetActive(false);
    • When adding a file to the project, you do not have to reload the solution (gets annoying, especially on large projects where reloading starts to take time)
    • By keeping your code outside of Unity you can use Git as version control for your code, and another version control system for your Unity assets, such as SVN. (Again, helps with large projects)
    • You can keep your Unity independent libraries truly separate from Unity. (This keeps your code clean, and helps if you have libraries you share among projects)
    • If you use a visual programming language that uses code generation to generate trash code (e.g. uScript) it will not end up in your solution.
    • Some have reported shorter compile times.
    • MSIL generated from Visual Studio is different from Mono (this means that in some cases your code might run faster than on Mono, and in some cases it will not, generally the difference is negligible)

    I could probably find more reasons but reason 1 was enough for me. You can find other threads talking about it here:
    http://forum.unity3d.com/threads/how-to-build-and-debug-external-dlls.161685/
    http://forum.unity3d.com/threads/re...ce-excessive-recompiling.148078/#post-1026639

    But if I am unable to reference the UnityEngine.Networking library then it is kind of a deal breaker. (side note: I can reference UnityEngine.dll and UnityEditor.dll as well as non-Unity libraries such as MoonSharp and fastJSON)

    Regarding your other question; whether the code actually gets compiled, the answer is yes (double checked with ILSpy).

    (Before someone asks: “Does that mean I can do [this .Net 4.0/4.5/4.6 thing]”, the answer is no)
     
  4. Twitwi

    Twitwi

    Joined:
    Apr 11, 2012
    Posts:
    22
    I have found a work around now.

    This is not a good idea, but since the UnityEngine.Networking source has been posted (https://bitbucket.org/Unity-Technologies/networking) I was able to download that, rename the namespace to something else (and fix a billion errors that this action made), compile, and import.

    This allows me to use the UnityEngine.Networking components, but it is such a dumb way to do it. If Unity updates the network I have to do this again. I rather be able to reference the UnityEngine.Networking.dll directly that going through this every update.
     
  5. Twitwi

    Twitwi

    Joined:
    Apr 11, 2012
    Posts:
    22
    I found another workaround, this one is a lot better. You can reference the library, like you would normally do, then build you code and copy over the assemblies. Then copy over the UnityEngine.Networking assembly and put it next to your assemblies (so inside the unity editor). This causes all the components to show up as if it all worked.

    However, if you are building the project you will get 2 errors ("Plugins colliding with each other." and "Plugin 'UnityEngine.Networking.dll' is used from several locations:"). To fix this simply click on the assembly, in the inspector window where it says "Select platforms for plugin" select only the Editor.

    Still not perfect but workable.
     
    mhusseini likes this.
  6. zoran404

    zoran404

    Joined:
    Jan 11, 2015
    Posts:
    520
    Good job :)