[Released] Roslyn C# - Runtime C# compiler

Hi,
This is almost certainly a referencing issue causing the compiler to not be able to find the required types. When using Roslyn C# you will need to manually supply the necessary assembly references prior to compile requests to avoid these types of errors. You can add references either from the 'References' section of the settings window at 'Tools -> Roslyn C# -> Settings', or via a script prior to compiling:

Code (CSharp):

1. domain.RoslynCompilerService.ReferenceAssemblies.Add(typeof(UnityEngine.Object).Assembly);

This will add a reference to the assembly 'UnityEngine.dll' or 'UnityEngine.CoreModule.dll' depending upon your Unity version.

To fix your specific errors you will need to add references to 'UnityEngine.InputModule.dll' or 'UnityEngine.InputLegacyModule.dll' depending upon your Unity version which will fix the input error, and 'System.Core.dll' for the func error. You can do this via a script:

Code (CSharp):

1. class Example : MonoBehaviour
2. {
3.     ScriptDomain domain;
4.  
5.     void Start()
6.     {
7.         domain = ScriptDomain.CreateDomain("Example", true);
8.      
9.         domain.RoslynCompilerService.ReferenceAssemblies.Add(typeof(UnityEngine.Input).Assembly);
10.         domain.RoslynCompilerService.ReferenceAssemblies.Add(typeof(System.Func<>).Assembly);
11.     }
12. }

Hopefully that will fix your issues but let me know if you are still having trouble.

 

Thanks for the reply!
I should have written following before: I already tried to add .ddl references via 'Tools -> Roslyn C#' which caused Unity to crash instantly. I just thought that I did it wrong but it seems to be a problem with my Unity version 2019.3.0b6 (also tried with 2019.3.0b12). In version 2019.2.1f1 I have no problems doing so - maybe I should try to downgrade my project then (?)

The crash can be reproduced by
> creating an empty project in Unity 2019.3.0b6 or higher
> downloading the asset
> opening 'Tools -> Roslyn C#'
> adding an assembly
> tapping outside of the 'RoslynCSharpSettings' so it's not shown in the inspector anymore
> Unity should crash instantly without finding a solution

On the other hand assigning the UnityEngine.Input assembly via script worked perfectly fine! I did the same with System.Func<> but the error with the missing assembly still occurs (which is not a big deal for me because I can bypass it with a different query). Maybe also a problem with the 2019.3 beta (?)

 

I don’t know what would be causing the crash but since it occurs in beta versions it is not something that we would look into unless it continues to be an issue in final release versions.
If adding references via code is working fine for you then I would say there is no need to downgrade.
We will look into the Func issue as you should be able to access it with no problems. Are you adding the necessary using statements etc?

 

Hi there,

This asset is great for its simplicity. But I've been testing out the restrictions to make sure it's safe and it seems like it's not blocking namespace restrictions.

The System.IO.* blacklist is one of the default configuration parameters. But I'm able to delete a file with System.IO.File.Delete. I have a pretty basic setup. Can you tell me why this might be happening?

Thanks!

[Attached is some screenies of the state of things in my project]

 

Hello,

I was wondering if it is possible to save the created assembly to disk, such that it can be loaded afterwards. I have tried to do this by serializing the bytes of the ScriptAssembly.RawAssembly object to a dll, and then loading them into a new Assembly object, but when I do this the system warns that the assembly is corrupted. Is there any functionality that allows this?

Edit:
On an unrelated note, is it possible to create an instance of an interface type using CreateRawInstance<T>? I know T is constrained to class, but is there any reason it couldn't be an interface?

 

Hi,
Thanks for reporting this. We have been able to reproduce the problem and it is indeed a bug. We will get an update sorted as soon as possible and hope to submit before the end of the week.

 

Hi,
Yes it is certainy possible to save the assmebly for reuse at a later date. The approach you are using should work without issue though. Are all the bytes being written and read correctly? If you pass the RawAssembly data directly to the 'Assembly.Load' method does the same error occur?

The built in way of doing this would be to disable the 'Generate In Memory' option in the Roslyn C# settings window and this will cause the assembly to be written to disk during compilation. By default the assembly will be given a unique name and will be saved in the current exectution folder however you can change the output location by assigning the following properties:

Code (CSharp):

1. domain.RoslynCompilerService.OutputName = ...
2. domain.RoslynCompilerService.OuputPath = ...

The class constraint can be removed from that method with a small change to the code. You will simply need to change the error handling return statement in the method to:

Code (CSharp):

1. return default(T)

Its intended purpose is no longer applicable as the code requiring that constraint was changed a while back so we will make this change for the next update.

 

Saving to disk seems to work as intended, thank you . I think previously I had missed that option, and was trying to serialize the in-memory assembly, not sure if that's what was causing the issue.
Also, thank you for clarifying the rationale behind the constraint, I've been able to clean up my code a little thanks to the change.

Related to my first question, is it possible to compile all the scripts in a folder into a single assembly? Similar to how unity does it with the .asmdef files?

 

It is possible to compile multiple scripts into a single assembly however you will need to determine which scripts you want to compile by searching the folder for suitable scripts manually. You can use the 'CompileAndLoadFiles' method to compile a batch of scripts. Here is a quick example:

Code (CSharp):

1. string[] files = Directory.GetFiles("C:/SomePath", "*.cs");
2.  
3. ScriptAssembly asm = domain.CompileAndLoadFiles(files);
4.  
5. foreach(ScriptType type in asm.EnumerateAllTypes())
6.     // Do something with the type

 

Exactly what I was looking for, thank you again

 

@mpeddicord

We have now fixed this bug which turned out to be related to static member references only. We will be submitting an update later today which should be live by the end of the week but if you need the update sooner just send an email to info(at)trivialinteractive.co.uk with your invoice number and we can send the update directly. Thanks again for reporting this problem and let me know if you have any more issues.

 

Roslyn C# version 1.1.6 has been submitted to the asset store and should be available for download within a few days. This version fixes a code security verification issue where static references to types would not be detected meaning that static methods and members could be accessed even if they are declared in an illegal type.

 

Hello scottyboy805!
Is that possible to fix RoslynCSharp.Compiler.dll or get it's sources?
I have an issue with RoslynCSharpCompiler.CompileFromFiles() method.
It is not disposing streams (what is probably a buggy behaviour) that are used to read source files and that's why it locks them for editing while application is running. And I can't just use RoslynCSharpCompiler.CompileFromSources() because it is not produce file names in error messages.

 

Hi,
Thanks for reporting this issue. It does look to be a bug and we will be happy to fix the issue however we are currently away from the office during the holidays so will not be able to look into this for a few days atleast. In the meantime if you want to send us your invoice number to info(at)trivialinteractive.co.uk we will be able to send you a fix for this problem as soon as it is resolved instead of waiting for the approval process. Happy holidays!

 

What would be the best way to create multiple assemblies that reference each other?

Should there be a new ScriptDomain for each Assembly? Since thats where the references are setup

I tried just changing the references before compiling, but to do that I also needed to turn off 'GenerateInMemory' otherwise I would get a error about 'path missing'.
Then after turning off 'GenerateInMemory', all the type names are wrong (it's cutting off the begining), then Unity also crashes after exiting / reentering play mode.

 

HI,
At the moment the only option for referencing other compiled assemblies is to disable 'Generate In memory' as you have discovered because the assembly will then be loaded from the filepath instead of the assembly image which means that the 'Location' property is assigned. This property is then used for referencing purposes by the compiler and without it you will see the path error as you are aware. We are currently working on an update which will also allow you to reference an assembly that was compiled in memory which should be coming quite soon.

For script domains usually you would only need to create a single domain and load all of your assemblies into it. It is not a true domain in the sense of a System.AppDomain but mostly for filtering purposes (Ie you dont see all assemblies loaded by Unity/Mono such as mscorlib etc).

The crashing behaviour may be related to a bug we recently fixed but have not yet submitted where the compiler would not close some file streams when compiling from file which Unity is not happy about if they exist in the project folder. If this issue is holding you up then send us an email to info(at)trivialinteractive.co.uk with your invoice number and we can send you a fix direct. The name issue may be related so I would say wait for the update and let me know if it persists.

 

thanks! I'll watch for a update to reference a assembly in memory.
I also experienced that file lock issue when trying to create assemblies by file paths (so I switched to reading the text files directly).

I also wanted to suggest a example script showing how to create a new sandbox app domain and then unload it - seems like it has functionality for that that isn't in any of the examples

 

If all goes well we may be able to submit the update today but it could be a few days before it is verified due to the holiday period.

For AppDomains we do not really want to provide examples of using it. The functionality is there and we have been able to load a compiled assembly into a separate domain however the amount of work and research we had to do just to achive that was enormous. Instead we would highly recommend that most users stick to the domain loaded by Unity and that only very advanced developers look into separate AppDomains in which case they will likley understand how to do it using many of the .Net resources online. If we provided examples of using separate AppDomains our support requests would likley increase quite a bit since it is quite a tricky task, especially in Unity/Mono.

 

Roslyn C# version 1.2.0 has been submitted to the asset store for review.

Important: This version contains breaking changes and may cause errors upon upgrading if you have code that uses the current assembly referencing API. Some of the changes include:

• IList<stirng> ScriptDomain.RoslynCompilerService.References and IList<Assembly> ScriptDomain.RoslynCompilerService.ReferenceAssemblies have been removed or replaced with: IList<IMetadataReferenceProvider> ScriptDomain.RoslynCompilerService.ReferenceAssemblies
• All compile methods that accept multiple source code/files will now only accept a string[] argument whereas previously a params string[] argument was used.
• All compile methods now accept an additional optional parameter 'additionalReferenceAssemblies' which default to null.

Take a look at the upgrade guide in the documentation for more info.

Update
This version fixes a bug where the compiler would sometimes fail to release file streams when using one of the compile from file methods causing Unity crashes or other issues.
It is now possible to reference compiled assemblies which exist only in memory. All compile methods now accept an additional 'IMetadataReferenceProvider' parameter which allows you to provide additional assembly references per compile request without needing to modify the compilers reference collection every time. Note that the references specified via the settings window and via a compile method call will be combined and not overwritten. Here is a quick example of how you can now reference another compiled assembly:

Code (CSharp):

1. // Compile and load the first batch of source code.
2.             // The public types in this source code will be accessible to any assemblies that reference it.
3.             ScriptAssembly assemblyA = domain.CompileAndLoadSource(sourceCodeA, ScriptSecurityMode.UseSettings);
4.  
5.             // Compile and load the second batch of source code.
6.             // Note that we pass 'assemblyA' as part of the third argument 'additionalAssemblyReferences'. This will allow the code we are compiling to access any public types defined in assemblyA.
7.             // We could also add many more reference assemblies if required by providing a bigger array of references.
8.             ScriptAssembly assemblyB = domain.CompileAndLoadSource(sourceCodeB, ScriptSecurityMode.UseSettings, new IMetadataReferenceProvider[] { assemblyA });
9.  
10.             // Call the static method 'SayHello' which will call the method 'LogToConsole' which is defined in assemblyA
11.             assemblyB.MainType.SafeCallStatic("SayHello");

You can also get reference providers to other assmblies in a variety of new ways:

Code (CSharp):

1. // Get a metadata reference from a System.Reflection.Assembly which is already loaded. Note that the 'Location' property of the assembly cannot be empty otherwise this will fail.
2.             AssemblyReference.FromAssembly(typeof(object).Assembly);
3.  
4.             // Get a metadata reference from an assembly image data array. The source array can come from anywhere as long as it is a valid assembly image.
5.             byte[] bytes = File.ReadAllBytes("C:/Assemblies/MyAssembly.dll");
6.             AssemblyReference.FromImage(bytes);
7.  
8.             // Get a metadata reference from a System.IO.Stream containing assembly image data.
9.             Stream assemblyStream = File.OpenRead("C:/Assemblies/MyAssembly.dll");
10.             AssemblyReference.FromStream(assemblyStream);
11.  
12.             // Get a metadata reference from a loaded assembly with the specified name or an assembly at the specified path. Note that the 'Location' property of the loaded assembly cannot be empty if providing only and assembly name.
13.             AssemblyReference.FromNameOrFile("mscorlib");
14.             AssemblyReference.FromNameOrFile("C:/Assemblies/MyAssembly.dll");

These methods all return an 'IMetadataReferenceProvider' object as the return value which can be passed straight to the compile methods or added via the compiler references collection.

 

After looking into the whole AppDomain issue myself - yeah, extremely hard to get working. I think it might be still worth it to include whatever example you got working - and explain the limitations / issues with it (Since right now it looks like it does easily support new AppDomains)

 

@scottyboy805 Hey, just imported Roslyn C# - Runtime Compiler - v1.2.0 to a fresh Unity 2019.3.0f build and are getting some compile errors that I can't resolve out of the box. I have put "API Compatibility Level" to .NET 4.x.

Is this version not supported yet or am I doing something wrong?

Spoiler: ErrorLog1

Spoiler: ErrorLog2

Spoiler: ErrorLog3

Spoiler: ErrorLog4

 

I have one question. Can this runtime compiler recompile the existing Monobehavior script during Runtime?

I suppose so, if not, is it possible we add it?
There is one Asset that claims that it can but I can't trust it.
https://www.assetstore.unity3d.com/en/?stay#!/content/151132

Thanks.

 

Hi, This is a known problem that we are aware of and will be adding steps to the documentation to resolve. essentially you will need ot go to the folder at 'Assets/RoslynCSharp/Plugin/' and find the assembly named 'System.ValueTuple.dll'. Then you can simply delete the asset from the project and that should fix the error you are getting. This is caused because newer Unity versions import their own version of the same assembly causing conflicts however we cannot remove the assembly from our asset because it is required for compatability with older Unity versions. At the moment there is no nice way for us to fix this definitivley.
Let me know if you are still having problems after trying those steps.

 

Hi, I am not sure what you mean by an existing monobehaviour. If you mean can it compile scripts that inherit from monobehaviour and run them normally in the Unity engine then yes this is fully supported. Let me know if you mean something different.

 

That worked perfectly fine! Thanks for the solution and for explaining the cause behind it.

 

Hi, I only saw your example where you compile codes wrapped in a string. What I mean by Monobehavior is that just a normal Monobehavior. You edit any Monobehavior and it compiles in the background without restarting it. This is what other asset claims to do.

 

Well you are able to compile source files as well as strings and you can do that in the background using one of the async methods. You can then add the compiled type to a gamobject by calling 'CreateInstance' which I assume you would want to use but then you would have 2 of the same component on the game object so I don't know what you would do then? Maybe delete the previous component from the game object and everything will work how you want? Maybe the asset you linked does something more extravagant to maintain script state or something similar.

 

Hi, I guess we are not talking about the same thing.
What I would like to do is to do runtime hot reloading for the modified assembly.
I mainly want to use this functionality for the fast development turnaround.
Did you check out the asset I mentioned? Is this something you can add to your asset?
I think you are using a similar technique already.
Thanks.

 

Yes I understand what you mean now. You can certainly recompile and load a monobehaviour during the game with Roslyn C# but I don't know what you would do after that. For hot reloading to work correctly surley you would need to maintain/restore the state of the script in the newly loaded instance and there is no built in way for Rolsyn C# to do that. I think that other asset must be doing something extra in order for it to work seamlessly.

 

Hey, I got some questions if anyone can help me understand how to tackle this!

Lets say that I've built a game, and now I want to make a mod for it so I create a new c# script in the "C/../MyGame/Mod/" directory. What I want to achieve is so that the IDE (Visual Studio) would recognize the classes I wanted to expose.

for example, before the game was built I have this class.

Code (CSharp):

1. namespace MyExposedNamespace {
2.     /// <summary>
3.     /// Description of the class.
4.     /// </summary>
5.     public class AExposedClass {
6.         string myName;
7.         int someValue;
8.         public AExposedClass(string n, int v) {
9.             myName = n;
10.             someValue = v;
11.         }
12.     }
13. }
14.  

When the game is built I dont have the project solution but I still want the modder's IDE to recognize the code that I wanted to expose so that it can show the descripion of the class etc

Code (CSharp):

1. using MyExposedNamespace;
2. public class MyModClass {
3.     AExposedClass testing = new AExposedClass("The Name", 7);
4. }
5.  

What I'm trying to do is to make it possible for the modder to type "MyExposedNamespace." to get a look in to the namespace and the available classes etc.



Ofcourse this all works when I do it in the game's project solution, but is it possible to get these features for the modder that only has access to the built game?

 

I figured it out, in case someone wanna see my conclusion: When building a game, Unity places the assembly DLL's in the "GameBuildDirectory/GameName_Data/Managed/" folder where they can then simply be referenced to in the modders own "Visual Studio .NET Standard" solution.

Comments cannot be built in to the assembly directly, you can however generate a XML Documentation file if you (In Visual Studio atleast) check the box under "Project/AssemblyName Properties/Build". Couldnt get unity to do this yet but looking into it.

 

Yes you got the right idea. If you want to get even fancier then you can automatically generate a .csproj file for your modders with all the correct references in place already kind of like the way Unity does however this is a bit more involved.
The Unity vs project is able to generate xml documenenation just fine because we use it for our scripts API's however everytime you add, remove or otherwise affect the .csproj file from inside the editor then Unity will regenerate the project file causing the 'Generate XMl Docs' property to be reset and you need to reenable it again. Bit of a pain but it is possible. Once you enable the option do a Rebuild All from inside vs and the xml file will be created.

 

Yup, that's why I asked in the first place. Are you willing to support proper hot-reloading?

 

I don't think that this is something we could support at the moment because it would require alot of research and testing to implement it properly and our schedule is full. Maybe it would be possible in the future but I make no promises.

 

Alright thanks for the reply! Can you please elaborate a bit on how I would go about to do this? I can see a box in Unity in the Build Settings window, "Create Visual Studio Solution" is that what you meant?

Alright, but then I can just generate the xml docs once just before building the game right? Then the documentation should be updated with the latest assembly right?

 

Sure, and it makes me very curious about how the other asset is doing. I hope you also have a chance to take a look if you really want to research.

Besides the hot-reloading, my other wish is to support "C# Interactive Window" like Visual Studio, aka REPL.
This is already doable with Roslyn and you will just need a good runtime editor.
Is this something you are looking into?

Thanks.

 

Yes you can just generate the documentation once every time the code base changes in the release version of your game.

 

Hopefully we will look into it at some point as I am quite intrigued as to what it might be doing.
We have a REPL asset in development however it is targeted at editor only. Ie. It is using a Unity editor window to display the interactive window. We would like to have it submitted within a month or so if things go well and for the moment we don't plan to support an in game interactive window.

 

Hey @scottyboy805, thanks so much for making this asset. It's been very helpful for my project!

I'm encountering an issue when trying to use Linq in my external scripts:

error CS0234: The type or namespace name 'Linq' does not exist in the namespace 'System' (are you missing an assembly reference?)

I added "System.Linq" to RoslynCSharpSettings' references list, but this doesn't seem to help. I have some custom assemblies for my project that I could easily add this way, but this one doesn't seem to resolve correctly. Obviously Linq isn't necessary, but it would be helpful in my project.

 

Hi, If you try adding 'System.Core' to the references list instead does eveything work OK then?

 

No, unfortunately that doesn't change anything.

Unless I'm doing something incorrectly maybe? I added "System.Core" to the references list exactly, but Linq is still not recognized.

 

Hi again,
We just tested this and it was an error on our part. You should add the reference 'System.Core.dll' (including extension) and then everything works just fine from our testing. Alternativley you could add the reference via code if you prefer like so:

Code (CSharp):

1. domain.RoslynCompilerService.ReferenceAssemblies.Add(AssemblyReference.FromAssembly(typeof(HashSet<>).Assembly));

HashSet is declared in 'System.Core' so this code will cause a reference to that assembly to be added.

 

Adding the '.dll' to the end did the trick and works best for me, thanks!

 

No problem. Let me know if you have anymore issues.

 

Roslyn C# 2.6.1 has been submitted to the asset store. This version adds documentation about plugin conflicts which can occur when adding some packages via the package manager. Upon getting a conflict error, you will now also get a warning message reffering you to the documentation to resolve the issue.

 

HI just tested out your asset. Just wanted to let you know that the example script (MazeCrawlerTemplate) is missing and semicolon after the import statement:
using RoslynCSharp.Example


Also I would add the line "return MazeDirection.Up" to the example script. I think it would be faster/easier to understand how the example is supposed to work.

 

Hi, Thanks for letting us know. We will make those changes and add them tp the next update.

 

Hi. I tested your asset a little bit more and I really like it so far. I however wonder how to debug scripts with visual studio. i am loading and compiling a MonoBehavoir at runtime, which works fine (i am loading the source from file). But I cannot break at a set breakpoint in the attached visual studio debugger. Is there an easy solution for this?

Edit: I activated the generate debug symbols in the settings. But now I get this exception during compiling: error CS8055: Cannot emit debug information for a source text without encoding.
I would dig a little more, but after some searching i guess the call to "CSharpSyntaxTree.ParseText" needs some proper encodings set. Unfortunately, i cannot access the inner of the dll. So I have to stop here...

 

Hitting breakpoints in compiled code is a bit difficult to setup as it requires external tools (PDB2MDB, Visual Studio) but can be made to work. We just tested generating symbols in a test project and everything worked OK for us and the .pdb file was created successfully. This was the case for generating assemblies in memory and as files.

In any case we have made changes to the compiler assembly so that it now specified the correct encoding so hopefully that would fix the issue. If you send us an email to info(at)trivialinteractive.co.uk or PM me on the forums I can send you the changes.

 

Any idea when the next update might be coming out? I am also getting the 'error CS8055: Cannot emit debug information for a source text without encoding.' error.