Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Renaming a .cs file does not edit the .csproj file #12917

Closed
zedutch opened this issue Nov 14, 2017 · 17 comments · Fixed by #37116
Closed

Renaming a .cs file does not edit the .csproj file #12917

zedutch opened this issue Nov 14, 2017 · 17 comments · Fixed by #37116

Comments

@zedutch
Copy link
Contributor

zedutch commented Nov 14, 2017

Operating system or device, Godot version, GPU Model and driver (if graphics related):
Windows 8.1 - custom Godot build (2cdfef5)

Issue description:
When you rename a .cs file from within the editor, the .csproj file doesn't get changed. This makes it so you have to open the mono project file manually to change the filename there too before you can run your Godot project again.

Steps to reproduce:

  1. Create a new project
  2. Add a C# file
  3. Change that file's name to something else
@akien-mga
Copy link
Member

Related to #12917.

@zedutch
Copy link
Contributor Author

zedutch commented Nov 14, 2017

@akien-mga Of course it's related, it's the same issue :P

@Zylann
Copy link
Contributor

Zylann commented Nov 14, 2017

I remember an issue exists but I cannot find it, I had commented on it about the fact that using an IDE was usually recommended with C# (because IDEs will rename file and update csproj accordingly as well as preserving all build options)

@leonkrause
Copy link
Contributor

This is the related issue: #12415

@reduz
Copy link
Member

reduz commented Dec 5, 2017

@neikeq

@NathanWarden
Copy link
Contributor

NathanWarden commented Mar 29, 2018

My opinion is still that we just have a fixed solution and project naming scheme like GodotProject.sln/csproj. More things need to be renamed when a project needs to be renamed than just the files. Also the assembly output needs to be renamed. It seems much more straight forward to just have a static name for the main solution and project file.

I'm not stuck on this idea, but if the renaming bug isn't moving forward (and I also have no time/motivation to take a stab at it) then I think the easiest thing is to just have a static solution and project naming scheme.

@DanteMarshal
Copy link

@NathanWarden Please no static solutions (Project is less problematic !). Unity does the same, And it doesn't let you work on any additional projects in the solution.

@Zylann I think your solution (Always using an IDE for C#) is better, because there are lots of IDEs for C# out there, why reinvent the wheel inside the engine ? The only problem here is that if the script file is renamed from the IDE, then the Engine loses the file and therefore makes its content (The C# codes) a built-in resource on the node it was attached to.
I think we need a way to either :

  1. Track file path changes (including move and rename) from IDE and apply them in Engine (That I think is not possible without plugins for the IDE)
  2. Make the engine change the path to that specific files in .csproj project config file, And hope that it works on the IDE. (Both MonoDevelop and VS refresh the project as soon as you switch to the IDE, So unless people are willing to use Notepad++ to write C#, I think it would works perfectly)

@Nufflee
Copy link
Contributor

Nufflee commented Jul 18, 2018

I can try working on this, I'll try to make it not regenerate or overwrite the .csproj file.

@Scellow
Copy link

Scellow commented Jul 20, 2018

Why not move to the new .csproj format

So we don't have to have to deal with that kind of issue

Mono can build projects that uses the new .csproj format

@Nufflee
Copy link
Contributor

Nufflee commented Jul 20, 2018

He's probably talking about this and it seems like a really good solution! I'll open an issue for this.

@Scellow
Copy link

Scellow commented Jul 20, 2018

@Nufflee the new .csproj format treat the solution as a folder, it includes all the .cs inside the project folder for building, so you don't have to edit the .csproj file manually if you add/remove a file for example

I don't know how the mono integration works, but this should work

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net462</TargetFramework>
  </PropertyGroup>
</Project>

@Nufflee
Copy link
Contributor

Nufflee commented Jul 20, 2018

@Scellow opened an issue here.

@Svetomechc
Copy link

Yeah, why not just use new .csproj format? This issue would automatically be gone then.

@aaronfranke
Copy link
Member

aaronfranke commented Nov 20, 2019

This issue might disappear if we switch to the new csproj format, but as far as I know this is only available in .NET Core, which we don't use. Perhaps if we switch to .NET 5 in the future?

In any case, not going to be done for 3.2, and I assume won't be done for 4.0 either. Perhaps 4.1?

@nonunknown
Copy link
Contributor

nonunknown commented Mar 12, 2020

using godot 3.2.1 and this error still happends ->
remove

aimed for godot 4? @aaronfranke

godot plz fix!

maybe a workaround would be a batch script that reads for file system changes and then updates the .csproj file.

@Calinou
Copy link
Member

Calinou commented Mar 12, 2020

I think the plan is to move to the new .csproj format by the time Godot 4.0 is released, so this should hopefully be fixed.

maybe a workaround would be a batch script that reads for file system changes and then updates the .csproj file.

If there's a standalone tool for making changes to a .csproj file safely, you could plug it into watchexec to achieve this. You'd have to run it in the background when working on your project though.

@neikeq
Copy link
Contributor

neikeq commented Mar 12, 2020

Although this won't be a problem with project SDKs in 4.0, this still needs to be addressed for 3.2.

The callbacks for files being renamed/moved/removed in the Godot file system dock have been there for quite some time. I feel bad because they were added to my request, but I never got to use them to fix this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment