Edit: Clarification, this explains how to create a custom C# Visual Studio project, link it to unity, compile a DLL of it, use the scripts inside the DLL in Unity and how to debug it. I know you can use visual studio as your “unity editor”, but this is not the same thing.
Edit #2: Some people have reported that they have to specify either .NET 3.0 or 3.5 to be able to reference UnityEngine.dll, I’m not sure why this is as you can clearly see in the video that it’s possible to link it against 2.0 (could have to do with different unity versions, I’m not sure).
This is a video tutorial (about 9 minutes) that explains how to use Visual Studio for both coding and building your unity code, it also shows how to debug the custom assembly that visual studio generates from inside Unity. I would advice you to watch it in 720p on YouTube to see all the text, etc. properly.
Here’s the text snippet I paste into the Post-Build Event in visual studio in the video (watch the video and you will understand).
echo f | xcopy "$(TargetPath)" "C:\MyProject\MyProject.Unity\Assets\Assemblies\" /Y
echo f | xcopy "$(TargetDir)$(TargetName).pdb" "C:\MyProject\MyProject.Unity\Assets\Assemblies\" /Y
"C:\Program Files (x86)\Unity\Editor\Data\Mono\lib\mono\2.0\pdb2mdb.exe" "C:\MyProject\MyProject.Unity\Assets\Assemblies\$(T argetFileName)"
A few benefits of using this method
You can use compile time constants (defines in the project)
You can use an obfuscator on your DLL very easily
Unity will not mess with your project files and force you to reload them
At work about a year ago we were playing with this, and found that the pdb2mdb which shipped with Unity was broken. We installed the latest Mono and used pdb2mdb from there instead, just to generate the mdb files, and it seemed to work. So you could try that.
However, that was a while ago, and it looks like Unity is already using a newer version now, as it works out of the box for everything I’ve tried recently (including IEnumerator functions). YMMV.
Hi thanks for the input, should I be able to find a reference in the Microsoft.Build.CommonTypes.xsd for IEnumerator? I don’t see one. I’m using latest Unity 3.5.
Thanks fholm for the tips. I’m kind of using the same method since a while, but even if I got the “official” pdb2mdb I still can’t get it to work with IEnumerators
Thanks for the tutorial! You mentioned that there were several issues with using .NET 3.5 for the target framework.
Obviously I can understand that errors/exceptions will occur when functionality that is unavailable to the Unity-supported mono version are used. However, are there any other undesirable side effects to this?
When creating an editor DLL for the asset store, is it better practice to develop using the technique that you describe, but then to build final releases using MonoDevelop?
There are some compiler differences too - the generated code for automatic events, for example, is different, and I recall having some problems with that in the past. I don’t remember whether this was connected with AOT compilation, but it may have been.
I just want to warn anyone out there who might be thinking of using MonoDevelop to compile DLLs in UnityScript. It does not work correctly through MonoDevelop. Even though it’s possible to compile a DLL, you cannot set a compile target and therefore will always get a .Net 4.0 DLL which may cause errors in Unity. See my post here for details. (Note: The particular error I was having has a workaround, but I still don’t know whether using .Net 4.0 dlls in Unity is a good idea for other reasons.)
If you’re looking into Unity for the first time and you think you will need advanced features like this, stick with C# and stay away from UnityScript at all costs. Trust me, it will save you so many headaches. Just my 2 cents from 2+ years of coding with US.
Edit: Well, I came up with a workaround that uses the same internal compiler Unity does and outputs a .NET 2.0 library files without the annoying errors. See this post for details.
I have a further question: I’d like to use the debug version of my dlls for development and the release version for deployment (for the reason of performance and size). Is it possible to handle this in unity through different directories? Or do I have to exchange the dlls before I build the final release?.
You will have to overwrite the DLLs. You can’t keep 2 instances of the same DLL in the same Unity project, because they will conflict with each other.
An easy way to handle this is to just have your Visual Studio solution compile to your Unity project assets, so when you change from DEBUG to RELEASE, you just have to recompile the solution and it’s done.
At one point you mention the issue with Unity hanging onto your dlls. Using xcopy, I’m still struggling with that. In particular with dlls that are loaded dynamically (as opposed to being copied directly into the project). When the postbuild runs, after a run of the game that has used the dll, I get the following:
3> MyLibrary -> C:\Users\Share\git2\DllProjects\MyLibrary\bin\Release\MyLibrary.dll
3> C:\Users\Share\git2\DllProjects\MyLibrary\bin\Release\MyLibrary.dll
3> File creation error - The requested operation cannot be performed on a file with a user-mapped section open
Have you perhaps run into this and found a workaround?
If you are looking for Visual Studio, shoot me an email.
I’m an evangelist at Microsoft, working with startups and indie developers, so I can likely set you up with a copy of Visual Studio through our BizSpark program. We’ve also got tons of tutorials and content for Unity devs too. Here’s one I did on using Prime[31]'s Azure Leaderboards.
