Preprocessor directives in DLL

Sigh I know this may be an old question, but the only post i found in forum was replied in 2012 and i hope something came up by now.
so here is the problem, i am developing a node editor, the code for custom editor drawing is sitting in the editor solution obviously, but, the actual code for nodes themselves, are sitting in the main project in the solution, now, when i select a node, the code inside the editor project will call methods on the node itself to draw for example the gui of the node, and the property of the node. obviously, those parts are editor stuff so i have to use preprocessor directive (#if UNITY_EDITOR) in the node class itself to keep it safe for build.
I planned to have this asset as two dll just to make it packed and simple to use in future, but as much as i read in that old post, if i compile these scripts into dlls, those code sitting inside that pre processor directive will be gone from the dll and the node GUI part will never ever work?
is there a way to utilize something and use this? remember, there are more than 50 nodes and i prefer to keep the gui and property part of each node on itself. because having another class for each node to draw it's gui stuff will cause a mess and head ache

 

I'm pretty sure what you're looking for is impossible. Preprocessor directives are meant to be evaluated come compilation time, and a DLL is a compiled assembly. By the time it's built, the directives have already been taken into account and have produced the appropriately transformed code to build the assembly. It's not a thing that might change with Unity updates, but something much more fundamental to programming in general.

If you don't mind exposing your code (which is really exposed anyways, unless you're somehow obfuscating it) then you can simply distribute and consume it as a .unityPackage which will simply zip/unzip the source code itself and your preprocessor directives will continue to function come compile-time. Other than that the only thing I can think of would require an overall refactoring of your solution.

Personally, I would recommend moving your node GUI drawing out of your node objects altogether and into your editor assembly - but you've already mentioned that is not your preference. Only other thing I can think of would be to have your node objects depend on an abstraction defined in your main assembly to do their GUI operations and have the editor assembly register an implementation of that abstraction that would serve as a proxy, forwarding GUI operations to UnityEditor implementations, you know?

Good luck!

 

Hmm actually last night i was thinking about decoupling the gui code from the main code, for 2 different reasons :
1- because of the gui code i have few more elements to serialize into the node run time object, it may look like nothing but when you think that this graph will be a behavior tree, and maybe 100 npc will have their own trees, those little blocks of data become huge amount of bits in memory that are really not usable at run time
2- decoupling the gui stuff from the main code should not be that hard when i thought about it, but now i have another question, the way i am implementing my graph, both the graph and the nodes are scriptable objects and being saves as .asset, if i use another scriptable object for the graph schema (the gui stuff) and put them under Editor folder, will the build process drop that schema automatically at game built time or not, because i would like to drop that scriptable object during the game built.

 

Unity should include assets in a build that have a serialized reference in the scene or if they are located in a Resources folder - if neither condition is true then Unity should cull the asset from being included in the build. I'm fairly certain this holds regardless of the resource being in an Editor folder or not.

Although if you have your gui ScriptableObject definition itself in an Editor folder then you should end up with a broken build if anything in the scene is containing a reference to it, which is what I should think you'd want. That way you'd be enforcing the decoupling of runtime and editor objects, ensuring that nothing in runtime would have a serialized reference to your editor objects and thus having any such assets dropped from the build. You might also want to consider placing editor .assets in the Assets/Editor Default Resources folder.

Hope that helps!