I'm migrating one of our Visual Studio solutions to .Net Core 5. It has two projects: a WinForms application (legacy) in Visual Basic and a class library in C#.

I've noticed that the .config file generated for the WinForms application has a different name from the previous version: it used to be {WinForms application name}.exe.config and now it's {WinForms application name}.dll.config.

I haven't been able to find documentation on this name change.

What I'm worried about is our version update process. On each new version of our software, we supply the .exe and .dll files to our IT operations people and they set them up for use. If there have been changes in the .config file, we supply it as well with a note telling them which nodes to add, remove or update.

Now, I don't know if the executable will work well with a config file with the old name format. So I've experimented. First, I change the value of a key the .dll.config file and launch the .exe directly. Quite normally, the changes are taken into account. Then I rename the .dll.config file to .exe.config again, and relaunch the .exe. This time, the application uses the initial value, even when I change the .exe.config file again.

I've also tried to rename the config file manually: building the solution simply (and predictably) creates a new .dll.config file.

1. Is there documentation about this somewhere?
2. Is there a way to undo this name change so our IT operations people don't have to wonder about it? (They're quite busy enough already.)

CodePudding user response：

The reason for this change is related to my answer there: Is the file format of a Library only a DLL file?

The .exe file of a .NET core app is only a stub loader. The actual code is in the .dll file. Note that for the application project, you now have both an application.dll and an application.exe. I'm rarely manipulating the config files, so I'm not exactly sure about the entries there, but if it works with .dll.config, then use that. You do have to tell your IT about the change anyway, as there might be other breaking changes as well (they might also need to install the new framework, etc.).

Do make sure your C# library and application are not using the same name. This was working previously with .NET framework, but will be a problem with .NET Core.