Including source and binaries (DLL) in same project / attaching source files to project?

In normal programming languages and engines, you can “attach” the source code of your files to a project, while using the DLL/compiled version. When there’s a crash (or you run the debugger), the debugger opens to the source code, even though it was running the compiled version.

Is there a way to do this in Unity?

There’s an obvious workaround that Unity prevents (for languages that don’t have this feature, you copy the source code in and delete the DLLs temporarily) because it sees an identical source .CS / DLL class, and declares “those are different! (even though they’re the same)” and the Unity serializer simply wipes all GameObject/MonoBehaviour data if you attempt to use one rather than the other.

(also … I believe this used to work in Unity 3.x, 4.x, 5.x … but Unity broke/disabled it in 2017 or 2018)

Did you find a solution?

Sorry, no.

Im not sure if I 100% understood your question, but what I do and works is create a C# project in Visual Studio and C# library (DLL) as project type. Change the project setting debug to “Portable”. Write your code, then build (Debug build) and copy the output Dll(s) + pdb files into my Unity project Asset folder.

(Some people say that you should put in a folder called “Plugins” but for C# dlls it seems to work no matter where you put them. Maybe that was a requirement for older Unity versions? I still put them in a “Plugins” folder just to be sure)

Now you can use the dll in Unity, go back to your Visual Studio editor (with the dll project code) and attach debugger to the Unity process or download the VS Unity tools, then you get a new “Attach to Unity” button (or something like that), select your Unity editor and attach it.

Now you can press play in your Unity editor and your breakpoints in the Visual Studio “dll project” will hit.

If it doesn’t hit then you most likely using the wrong debug format (C# project setting), the wrong .NET version (.NET 4.x or Standard) or you changed your C# dll and forget to copy the new built dll and you are using a old version, to avoid this you can also change the output folder in your “dll project” to build directly inside your Unity project “dll folder”.

I hope this answers some of your questions?

This will also work for the release build as long as you provide the correct pbd files and you have to make sure that the code is still the same, so make sure that you are using your release build pdb files, they should be created by default, but if you don’t got any, then you have to make sure that they are enabled in your release build config.

This will also work for a built game which runs standalone (not in the editor) as long as you run it on windows with C# (not IL2CPP), then you have to manually attach your VS to the running game process. But Im not sure how to debug on other plattforms or if you use IL2CPP, I never tried to debug these.

I don’t use MS’s tools - currently using Rider - but this is a good reminder that I should try again :). Sadly, JetBrains’s settings for DLL building are terrible (error prone and very bad UX - definitely not written by people who came from a C/C++ background :)).

If you have the source files and want to include them in your Unity project, why do you want to put the compiled dll manually in there as well? Unity compiles all your code to assemblies on it’s own. You can use assembly definition files in Unity to tell Unity that a folder and all it’s sub folders should be compiled into a seperate assembly / DLL. There isn’t really a need to include compiled DLLs unless you don’t have the source code or you don’t need it. For example if you inlucde the SharpZipLib you usually don’t care about the source files since it’s a well tested assembly. There’s no need to debug the internals of that assembly.

@Bunny83 Not sure about OP reason, but I use Dlls for shared code, for example I put code that I use in multiple projects in a “Common” Dll and copy the compiled dll in these Unity projects, that’s a lot cleaner than copy&pasting the code files in every single project.

How else are you going to test/debug a DLL?

Assembly definition files are officially slower - often much slower - than DLLs. If you have a small project - great! Use asmdefs! If you have a big one … that may not be possible (there’s a recent thread on the forums where someone has many minutes per recompile because of Unity’s asmdefs handling code).

I hope that Unity comes up with a better implementation for asmdefs, so that everyone can use them in the future, but for now they’re only of limited use.

I publish a free version of some of my assets without source-code. DLLs are the only way to do that.

But for my paid assets, where people get the source code, every asset has at least a few people asking me for precompiled DLLs as well because they are faster and easier to work with.