Feature Request Expose .sln and .csproj generation

Unity automatically generates .sln and .csproj files for the code files inside the project.
This is OK if you're just using the editor, but limits the ability to interoperate and use external tools to process your code.

On top of that, since Unity auto-generates and updates those files, it is generally not recommended to check in those files into source control.

Consider an example - SonarQube is a static analysis tool. It has support for scanning .NET code, and has nothing to do with Unity. In order to run a scan, one must first build and process a .sln file.

To achieve this, currently, I must launch Unity and call some editor method that refreshes the .sln files, then close the editor and continue with the process.

While this works, it forces me to have Unity installed on every machine that could run this scan.
There are other countless examples for such .NET tools that rely on a .sln or .csproj file.

It would be great if the process of building the .sln and .csproj files was somehow exposed (as some 3rd party tool, DLL or any other option) that is not directly dependent on Unity (the editor) installed on the target machine.

Is this something that was ever considered?
Is it in your plans? How difficult would it be to achieve this ?

 

I wanted to show you this button ... but then I realized, that's another nice feature you only get when using Rider.


But it may actually suffice to have the Rider Editor package installed, switch to Rider, click the button, then change back to Visual Studio. Wait, what, why am I saying this? I mean, really, the next step is to go to the JetBrains website and purchase Rider for you and your team.

Anyway, you could look into batch mode, it could do the trick if you want to automate this process with a simple batch file: https://docs.unity3d.com/Manual/EditorCommandLineArguments.html

 

I just looked up in source code for "Regenerate project files".
Looks like the Rider package has a class for this which you could leverage and adapt to your needs.

Code (CSharp):

1. namespace Packages.Rider.Editor.ProjectGeneration
2. {
3.            internal class ProjectGeneration : IGenerator

Essentially this is a csproj/sln generator from template snippets.

But you'd only need to extract that class from the Rider package and call its "Sync" method to generate the project files.

 

My suggestion was to extract the project generation logic from Unity into a standalone tool.

I don't want to use batchmode as it means i gotta have Unity installed, as mentioned in my original post.

As far as i know, Rider's generation is built upon the built-in project generation provided by Unity, so it cannot be used on its own

 

Right, I missed that. Would be difficult though to generate projects with a tool that's not running within Unity itself. You'd have to manually scan all the files, asmdefs and all that.

And what for? The benefit of not having to install Unity on a system is just not enough IMO. Even for automated builds you need to have Unity installed anyway. And that's usually also the machine you'd be running such automated tools as well, right?

 

this would be great! we also added Sonarqube to our engineering process and I was really sad when I found out it didn't work without the csproj. And of course we don't want to track that in git

 

you basically have to launch Unity to get it syncing the project and solution files, then quit it and run whatever you need with those files now in place.

It's a hassle and i would rather do it externally and not from inside Unity.

 

I have a working workflow where i launch Unity, sync the .sln and .csproj files on our build machine, then quit Unity and run an MSBuild based flow to build the .sln and then use that to scan our codebase using SonarQube.

I understand what you're saying about not being identical to the compilation that Unity uses in the editor and when packaging the player, but for these purposes it works for us in this case.

Judging by your answer that the full transition to this workflow will take time - do you think that building our own logic for creating .sln + .csproj files might be far fetched? how complicated can it get ?

I assume we can map the files inside Assets and decide whether they belong to any special folders (Editor and the likes), check .asmefs and then create files per assembly with references to the matching script files.

 

YEP! sign me up

 

Did you get a chance to check this out?

 

Any updates @HaraldNielsen ?

 

Also interested in this. Any updates?

 

Is there any update on this @HaraldNielsen ?