How to create DLL for Unity with Visual Studio

[@TheSpacecraftX]

Remember to switch to Release mode instead of Debug mode to get faster running code without the debug feature flags turned on.

[@sandraeise9080]

Thank you sooo much !!!! Your example worked perfectly ! Directly afterwards i tried a transform.Translate for a cube, same way as you have explained and it also worked without problems !!!

[@CodetoCreate]

Glad it helped!

[@zenxah_2514]

My entire assignment has been explained in 7 minutes

[@Demix224]

oh thank you this was exactly what I was looking for.

[@007walk]

Thanks for this quick run through for creating a dll.

[@DavTheCanadian]

Thank you so very much Macy, that's exactly what i was looking for !

[@sadafshabbir165]

thank you soooo much. *code to create*.. now Ill do code easily

[@johnmoore5309]

Very helpful and straightforward. Thank you!

[@C.F_Studio]

thanks for the info Macy :D

[@unityvictor787]

Thanks for the tutorial, it's very easy to understand.

[@dreamisover9813]

Thanks, really useful!

[@phyzxengrmoore6928]

Thank you. This is very clear. The further question I have is can I use calls from an EditorWindow class DLL to call methods in a Monobehaviour class dll with the correct assembly references added?

[@sampalacio]

Great! What would be a good use case for this?

[@CodetoCreate]

Sharing your code with others

[@murat303]

thanks, can u make a video about how to obfuscate dlls?

[@MineGugi]

My visual studio 2017 is not finding reference of Monobehaviour after add UnityEngine.dll reference and add 'using UnityEngine;'

[@tzebruh]

You have to add UnityEngine.CoreModule.dll for that to work.

[@rickyreddy5894]

Awesome. Thanks for sharing

[@unityvictor787]

But I found out the comment I wrote in Visual Studio, It won't show up in the script opened with Visual Studio in Unity. How to make it show up?

[@toptunesiran]

Hi, Thank you for the tutorial. I have a question, will this plugin work on android or ios?

[@CodetoCreate]

Dll is windows format. It only works on Windows.

[@RagnarLothbrok-bk7zi]

yo can you help me with my project please? whenever I import my C# script it shows me error that system.data.sqlclient namespace not recognised

[@lucasaraujo3722]

thank you! ( Você é muito linda!)

[@VirtualSUN]

Thank you very much!

[@westparezal]

How can i get dll class methods from another class in unity?

[@unityhub-d8g]

Good Work

[@CodetoCreate]

Thanks!

[@monsunstudio3871]

unity.visual scripting.antlr3.runtime.dll was not found Whats should be i do?

[@autorotate1803]

Thank you!!

[@foly9032]

can i use some dll without monobehavior?

[@CodetoCreate]

Yes

[@jeb9472]

thank you

[@HericksonWargames]

Thanks!

[@troyna77]

ty

[@GameDevNerd]

"MonoBehaviour is the most used class in Unity projects," -- Yep, it sure is ... and it's also the most widely _abused_ class in the entire Unity API, and one of the primary reasons people complain about getting only 18 to 32fps frame rates in their games! Only thing people might abuse worse than MonoBehaviour is probably those _evil_ coroutines ... 😬 When I talk to beginners or look at junior devs' work, I tend to notice that they are usually blissfully unaware that _constructors_ are a thing or how to write plain ol' basic C# classes and use them. They create MonoBehaviour after MonoBehaviour for every little snippet of code they want to write, and turn their projects into a spaghetti-coded swampland no one can navigate that performs unbelievably slow for the simplicity of their scenes and their games. And to make it worse, they will have crazy coroutines going all over the place for absolutely no reason. No one ever explains to them that MonoBehaviour is a very special and _expensive_ class we _only_ use under very special circumstances, and that _most_ game logic belongs in ordinary classes we write and design ourselves ... or that coroutines are _not_ threads, they are _not_ asynchronous and they are _not_ faster (they're actually slower), and they also have a _very_ specific, special purpose. What are those purposes? To oversimplify things and make a long story short, MonoBehaviour is only necessary when you _must_ glue some code to a GameObject _directly_ and have its state serialized in the editor. Don't confuse that with seeing things in the editor inspector window, even though that's a _benefit_ of it, because you can see regular classes and structs in the inspector too, if you mark them [Serializable] and use them as a field in a MonoBehaviour or ScriptableObject that's editor-serialized. Simply mark the field [SerializeField] but do _not_ make public fields ... that's another terrible, awful thing beginners are being incorrectly taught to do. Public fields are the Devil in a big project ... you may not notice while you're working at very small scales on short-term scenes, but one day you'll find out the hard way when scripts are changing stuff, screwing up the whole game and you can't get a debugger breakpoint to hit for anything modifying the variable! What is the special purpose of a coroutine? A coroutine is made for splitting up a long or slow process and doing work over multiple frames without _blocking_ the game loop. Like if you need to fetch some data from the web or iterate over 2-million items in a huge array. If you tried to just do it all on one update, the game will freeze until its done. Coroutines are for letting it do a _little slice_ of that work each frame. It's _not_ for trying to speed your game up, make a delay or count-down (that's _not_ what WaitForSeconds is for lol) and it's not asynchronous or a thread whatsoever.

[@Justinjaro]

idk who you're working with or how bad they code, but dude, if public methods/fields and such are changing in your game and you can't track them down, I really don't think it's the fault of using "public", it seems like poor coding to me. Yeah it may be bad practice to have everything in classes be public, but in the end it's still up to the developers to close/track down anything utilizing that public class/field/method. There's more than one way to cook an egg, and if someone ships a game/experience that doesn't break with they shipped a game that doesn't break. But to add on to your MonoBehaviour point, yeah that Update method is crazy abused. Telling juniors to just code with callbacks and events instead of using the Update method is a real hard one for people to get used to. No need to check every frame if a thread is still processing/grabbing data.

[@GameDevNerd]

@Justinjaro someone in our Discord had precisely that problem with a boolean value in a script ... it kept ending up unexpectedly *false* when they set it to true, and it was a naked public field. A completely different system was setting it false without them realizing it, which was written before they even started working there. But he changed it to a property and found out the cause by using a breakpoint ... if he'd used a property in the first place he wouldn't have been pulling his hair out his head and wasting 2 days fighting it and writing hundreds of Debug.Log calls all over the class. Using properties and following good practices are essentially "free" (doesn't hurt anything, and carries no extra effort or difficulty) and give you a way to instantly get yourself out of such trouble when trouble comes. In the real world you're gonna be working with a lot of bad programmers and bad code other people wrote, teaching junior devs and trying to simplify complex things. So you might as well think ahead and make good choices your default.