resharper-unity icon indicating copy to clipboard operation
resharper-unity copied to clipboard

Can't use sln.DotSettings properly (team layer settings)

Open capyvara opened this issue 6 years ago • 10 comments

Since Unity generated solution is based of on the project directory name, putting a versioned .sln.DotSettings file at root isn't guaranteed that users will have the same solution file name.

This may be related to #568 since the only way to set a naming rule is at .DotSettings file (.editorconfig naming aren't picked by Rider)

My workaround was to version a .DotSettings and after solution generation by unity, create a symbolic link with the correct name pointing to it, Rider seems to pick it up nicely.

using System;
using System.IO;
using System.Diagnostics;
using JetBrains.Rider.Unity.Editor;
using UnityEngine;
using UnityEditor;
using Debug = UnityEngine.Debug;

public class SolutionPostProcess : AssetPostprocessor
{
    public override int GetPostprocessOrder()
    {
        return 20;
    }

    static readonly string DotSettingsFilename = ".DotSettings";

    public static void OnGeneratedCSProjectFiles()
    {
        if (!PluginEntryPoint.Enabled) { return; }
        if (!File.Exists(DotSettingsFilename)) { return; }

        // TODO: Windows support (mklink)
        if (Application.platform != RuntimePlatform.OSXEditor) { return; }

        try
        {
            var projectDirectory = Path.GetDirectoryName(Application.dataPath);

            var projectName = Path.GetFileName(projectDirectory);
            var slnFile = Path.GetFullPath(projectName + ".sln");
            var slnDotSettingsFile = slnFile + DotSettingsFilename;
            if (!File.Exists(slnFile)) { return; }
            if (File.Exists(slnDotSettingsFile)) { return; }

            var ret = RunCommandLine("ln", "-s " + DotSettingsFilename + " " + slnDotSettingsFile);
            if (ret != 0) { Debug.LogWarning("Failed to link .DotSettings"); }
        }
        catch (Exception e)
        {
            Debug.LogException(e);
        }
    }

    static int RunCommandLine(string command, string args)
    {
        var startInfo = new ProcessStartInfo(command, args);
        using (var process = Process.Start(startInfo))
        {
            if (process == null) { return -1; }

            process.WaitForExit();
            return process.ExitCode;
        }
    }
}

I'm not sure if there's a better way to handle team-shared (thus versioned) code settings.

capyvara avatar Jun 12 '18 13:06 capyvara

Ah, good spot. Rider does require the .dotSettings file to match the solution file before it's automatically loaded. But we can also add the .dotSettings file programmatically, if we can correctly identify it. I wonder if it's enough to:

  • Let Rider load existing .sln.dotSettings file that matches current folder.
  • If another .sln.dotSettings file exists, and there isn't a corresponding .sln file, then automatically load this file as though it were the solution level file.

The only other alternative would be to rename the generated .sln file. Does Unity's project name only ever come from the directory name, or is it saved in ProjectSettings or Library?

citizenmatt avatar Jun 12 '18 14:06 citizenmatt

I think renaming the generated .sln file isn't feasible, since there may be a lot of post processor code that tries to infer the .sln name from directory name for processing, as far as I know there's no known api to get the project name.

What I like about creating a .DotSettings file is:

  • The naming is similar to the other directory based approaches (such as .gitignore, .editorconfig, etc)
  • Removes the ambiguity, there can't be more than one .DotSettings file, however there may be multiple *.sln.DotSettings and won't be clear which one you should pick.

Of couse if there's a existing .sln.dotSettings file that matches current folder this should have priority.

capyvara avatar Jun 12 '18 14:06 capyvara

This also affects the .idea folder, as the contents are stored per-solution, i.e. .idea/.idea.<project>/...

citizenmatt avatar Jun 21 '18 15:06 citizenmatt

Please also vote this issue https://youtrack.jetbrains.com/issue/RSRP-472240

van800 avatar Feb 20 '19 09:02 van800

Any updates on this feature? Does it have its own ticket on youtrack? .editorconfig is nice, but very limited in features.

develmi avatar Dec 11 '19 09:12 develmi

Same https://youtrack.jetbrains.com/issue/RIDER-44228

van800 avatar May 09 '20 12:05 van800

@develmi , @capyvara is this still actual as Rider now could read/export naming settings from editorconfig?

krasnotsvetov avatar May 09 '20 12:05 krasnotsvetov

I found editorconfig couldn't be used to enforce layout. So this is still something we need, in order to support source control workflows where the solution name changes. Right now looking at a solution similar to original post https://github.com/JetBrains/resharper-unity/issues/591#issue-331599994

edwardrowe avatar Nov 09 '20 16:11 edwardrowe

I am encountering this exact issue. I want to keep my teams coding styles consistent to avoid spending review time dealing with stilly code style issues. I created a dotsettings file with our custom layout inside and have now realized that I will never be able to enforce this since the generated unity solution must match the name of the dotsettings file.

I absolutely love the idea of removing the solution naming and just having a .DotSettings file similar to git and other services that will be recognized by rider. I don't want to rely on my developers to hand configure anything I need to be able to enforce this automatically and be compatible with the fact that they can pull the code into any folder with any name and that dictates the name of the unity assembly that is generated

ZackWaveXR avatar Jan 29 '21 02:01 ZackWaveXR

+++

However, rider plugin undefined symbol for PluginEntryPoint Any updated code and windows support? Can you share it you have?

btw

Fix RIDER-51958. Callbacks OnGeneratedCSProjectFiles would not work, but show a Warning instead.

alkanyunus avatar Sep 19 '22 13:09 alkanyunus