For each release, provide 2 UnityPackages - one with precompiled DLL's, one with source files about nakama-unity HOT 5 CLOSED

Hey @prodigga - The only issue with this is we have conditional compilation statements in the codebase which get ignored if we precompile the DLL. For instance, we have an entirely different transport system for WebGL, or various tricks to support SSL in Android that won't work if we precompile a DLL.

What's your usecase for a precompiled DLL, and why is UnityPackage source problematic for you?

from nakama-unity.

Ah, I see, I hadn't considered that. Though Unity does allow you to specify which platform a specific DLL should be included for. So you could just package one DLL per platform and mark them appropriately in the inspector?

As for the 'why' - mainly Unity does not have to keep recompiling the dozens of source files whenever we make a change to a plugin script! :) Also, not as important but still worth mentioning, it is a little annoying having dozens of Nakama classes, methods and variables appearing in the search results. ie Just a random example, searching for the work 'join' (I have a class called MatchJoinState), I see this:

from nakama-unity.

I also would like to see that feature, as I compile all of my dll files outside of unity, i don't rely on unity's auto compiling. I do this so i can use the latest c# features and compile down to unity compatible version. Not having a dll means basically i have to find a way to compile all of the script files into a dll to reference it inside my vs solution.

from nakama-unity.

@arlenner Thanks for the feedback. I was actually doing some work a few days ago to improve the build system and provide both source packages and DLL releases. I'll speak with the team to bring the changes forward in our sprint.

from nakama-unity.

The way we package the Unity client has changed since the Nakama 2 release. I think it now covers what you'd like. Please re-open if we should discuss further.

from nakama-unity.