0
\$\begingroup\$

I'm developing a core library that I will use in my other games. I've only heard of using Unity .DLLs recently, and have spent some time putting my core scripts into a namespace. If I understand .DLLs correctly, I should be able to take that .DLL, plop it into one of my other projects, and then immediately start using it.

The question is, how do I compile that namespace into a .DLL that I can use in other projects? I'm using Visual Studio and Unity 2018.2.17f1.

\$\endgroup\$
  • \$\begingroup\$ Does this help? Google is your friend. xinyustudio.wordpress.com/2015/12/09/… \$\endgroup\$ – Almo Jan 31 '19 at 14:32
  • \$\begingroup\$ @Almo Ew, MonoDevelop. That said, its similar process in VS. Later this year I think there will be a way to do it inside an existing Unity project (or better management of it) with their new package manager. \$\endgroup\$ – Draco18s no longer trusts SE Jan 31 '19 at 14:57
  • 1
    \$\begingroup\$ Did you follow the "Step by step guide" in the Unity documentation? Did you run into any specific snags in that process? \$\endgroup\$ – DMGregory Jan 31 '19 at 16:06
  • \$\begingroup\$ Using DLLs in Unity for a while now, my advise is to think really hard if you need it. The main difference between a (managed) DLL file and just *.cs files is that you can't change the DLL. For every change in there, you'll have to switch to your library project, make that change, build it, copy the new version to Unity, have Unity reload it, and then adjust the Unity code accordingly. No quick refactor=>rename anymore. Plus if you want to have MonoBehaviours in there, all of them are listed as direct children of the DLL on the same level and sorted alphabetically (no folders etc). \$\endgroup\$ – Raphael Schmitz Jan 31 '19 at 18:02
  • \$\begingroup\$ Furthermore, the connection with those MonoBehaviours is kinda brittle (I think only by class name?). So whatever advantage you get from DLLs needs to outweigh all of that. One example of that is when you sell it in the asset store, because then you want to prevent 3 hours of troubleshooting only for the customer to say "oh yeah I made this little change, that can't be it right?". If you just have code that you want to reuse in another project, an asset package or literally copy-pasting is easier. And your library probably will grow from project to project. \$\endgroup\$ – Raphael Schmitz Jan 31 '19 at 18:08
3
\$\begingroup\$

Yes, that's basically how it works. But DLLs aren't exclusive to unity. DLLs are a widespread concept for reusable code components in many different programming languages. Just to make clear that there are many many differences on how .dlls are treated.

1. TL;DR:

.NET was originally implemented for windows only. .NET by itself is not a specific programming lanugage but a whole infrastructure that can be compared to how Java works. The whole idea is to execute code on a virtual CPU. This might not appear like a big deal at first but it is.
By concept, .NET separates a program and its execution environment. While the .NET platform (the CLR which runs written programs to be more precise) must be installed on a system, programs remain platform independent. This allows you to write code on say Windows and reuse it on mac OS or Linux for example. While this is old news for .NET developers, this might be news for people who know .NET only from Unity.

Let's talk about Mono. Originally, there were no other platforms to support .NET other than differnet versions of Windows (Windows RT, Windows mobile, etc.). After a while, some people started to write a runtime which was capable of executing .NET code without relying on Windows. This lead to an abstraction of the underlying operating system. You can think of Mono as a cross-platform version of .NET.

Meanwhile, Microsoft is really invested in open source and dropped the 'Windows-only' part of .NET some years ago. That's the story behind .NET Core. Core has basically the same goal as the Mono project but is developed by Microsoft.

Why the history lesson? Because in the context of Unity this really is news. Until the version release in 2018, Unity was based on a super old implementation of the Mono runtime. .NET compatibility was there but only up to version 3.5. That version was released late 2007 and since then never updated for Unity until 2018. This means that no new C# language features were available for Unity developers for 12 years. That's huge.

If you're still rading this, I might as well go ahead and bother you with .NET Standard. Late 2018, .NET Standard 2.1 was released. This is nothing but a definition of language features which must be supported by a .NET runtime (Mono or Microsoft or others) in order to be compatible with a specific version. So instead of .NET 3.5, .NET 4.0 and so on, all versions - it doesn't matter if CORE, not Core, Microsoft or Mono - are identified by .NET Standard, .NET Standard 2.0 and .NET Standard 2.1.

You don't have to know all of this information but why not understand the technology you're working with. You'll see some .NET specific stuff in Unity so you might as well know the story behind. In Unity, check the 'Other Settings' panel under Edit / Project Settings / Player to see your .NET configuration:

.NET configuration in Unity

We finally have support for modern .NET and can use the latest C# language features. Awesome. This is important because you have to consider these things not just when consuming a .dll but especially when writing one. By selecting the right .NET version for your Class Library project in Visual Studio, you define whether your DLL is compatible with Unity and other .NET components. So take that into consideration when creating a new Class Library project. Without this knowledge you'll have a hard time understanding the differences between the many different project templates:

  • Portable Library
  • Multiplatform Library
  • .NET Standard Library
  • Class Library
  • Library

Make sure to understand which project template is compatible to which .NET version. If you select the wrong library type, Unity won't be able to understand the DLL and that will cost you some research time to figure out why.

Finally the answer

Just make sure to select a compatible Class Library project template and write down your code. The whole namespace thing: A DLL always exports the namespaces just as you use them:

namespace I.Like.Big.Namespaces.And.I.Can.Not {

    public class Lie {

    }
}

class Whatever {

}

There's nothing more to it. After building your DLL, navigate to your output folder (should be bin/ in your project's root directory) and copy the .dll file into your Unity project (Assets/Scripts/_dlls/ for example). Open Unity and wait until the newly added DLL is detected and there you go. Now you can import and use code from your lib.

While DLLs are a good way of organizing your project, there are some things to consider before using them. Be sure you really need DLLs in your project. You won't be able to access Unity classes out of the box for example. There are ways of adding certain dependencies and build complex Libraries even specifically for Unity, but that complicates your overall project setup.

\$\endgroup\$
  • \$\begingroup\$ How would this process change if I wrote up the namespace + code BEFORE creating the .DLLs? Would I just have to copy over the code to the new project? \$\endgroup\$ – del Jan 31 '19 at 19:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.