Eazfuscator.NET 4.1 brings official support for Unity applications. This is the great addition since Unity got a lot of traction during recent years.
Unity is a gaming engine that uses .NET for behavior definition and native code for fast rendering. And everything related to gaming is based on getting the things done. Often it doesn't even matter how.
It took me some time to enter the mindset. I read some historical articles from people who were in the gaming business during 1980s and 1990s decades just to find out that nothing had changed nowadays.
Artists and developers meet, create some stuff and then put it together. This is an artful and risky business as nobody can be 100% sure. Game is a vigorous fusion of story, art, action, culture and the current historical momentum.
Unity supports a considerable amount of target platforms: iOS, Android, Windows Phone, Windows and Mac desktops among others. This affects Unity in a way that while it can be treated as IDE, in fact it is a Disintegrated Development Environment.
Everything is split into parts: rendering, behaviors and even a building pipeline. For example, when Unity targets Windows Phone 8 it does not produce the Windows Store package you would expect. Instead, it outputs the Microsoft Visual Studio solution that should be built separately.
The same approach is used for iOS games where Unity outputs the project for Apple Xcode IDE. And yes, it should be built separately.
What about automation? That's possible but not a requirement. And most of developers just do it manually. This is a gaming world, after all!
The mindset is fueled by natural workflow diversity: doing paintings and design on Mac, coding in Visual Studio under Windows, building on Mac to get the iOS package.
If you are a Mac guy then it may go as follows: doing everything on Mac, going to Windows and Visual Studio just to get that Windows Phone 8 game everybody wants to play.
The main game logic is defined in Assembly-CSharp.dll assembly. Assembly-CSharp-firstpass.dll may have the important code too, though it is rarely used.
Once Unity finishes the build, drag and drop Assembly-CSharp.dll assembly in the green zone of Eazfuscator.NET:
You are done. Then, please do the final build in Xcode or Visual Studio as usual. Some targets like Windows Desktop do not need further building. It just depends on target platform.
Unity Script is a homebrew language for Unity. Like C#, it is based on .NET CLR. Probably it may be useful for some purposes but for the most it is hugely broken in many ways. It will work with obfuscation but renaming coverage will be non-existent. This happens due to reasons that go directly to weak Unity Script design.
Beware of Unity Script, use C#.
Is Eazfuscator.NET Special?
Yes. It just works and makes your code faster thanks to built-in advanced optimizer. This is a good fit for games where every CPU cycle counts.