I recently migrated a .NET desktop application. Originally it was on .NET 4.6.1. I first migrated to .NET 4.8 and then to .NET core 3 and now getting a run time error when opening Form1
I have some windows forms which are located in a sub folders in the main desktop app project. The windows forms doesn't include the name of the sub folder where they are located in their namespace.
So let's say that we have a form1.cs, located under "Reports" sub folder. the type of this form is ProjectName.form1 and not ProjectName.Reports.form1.
This form has it's own resource file (form1.resx) but after migrating to .NET core, the following line from the designer file is failing
System.ComponentModel.ComponentResourceManager resources = new System.ComponentModel.ComponentResourceManager(typeof(Form1));
Exception:
Could not find the resource "ProjectName.Form1.resources" among the resources "ProjectName.Form2.resources", "ProjectName.Form3.resources", nor among the resources in any satellite assemblies for the specified culture. Perhaps the resources were embedded with an incorrect name.
The solution I made was to correct the namespace for the forms under the "Reports" sub folder, but I was not aware about this behavior change in coreclr, maybe better to document it (if not already documented).
Please note, the ComponentResourceManager class lives in this dll on my machine:
C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Ref\3.0.0-preview6-27804-01ref\netcoreapp3.0\System.ComponentModel.TypeConverter.dll
@ericstj is this known?
Although thanks to @tarekgh great new error message it seems form1 is not getting embedded at all but form2 and 3 are. @aghanem if you open the dll in ILSPY or ILDASM can you confirm this is true? What is special about form1 here?
I believe this is a duplicate of https://github.com/dotnet/corefx/issues/34190, which is actually a tooling issue that will be addressed in https://github.com/microsoft/msbuild/issues/4488. MSBuild used to crack open the source file and parse it to find the type name and namespace and it isn't doing this anymore. https://github.com/microsoft/msbuild/issues/4488 will fix that.
Most helpful comment
I believe this is a duplicate of https://github.com/dotnet/corefx/issues/34190, which is actually a tooling issue that will be addressed in https://github.com/microsoft/msbuild/issues/4488. MSBuild used to crack open the source file and parse it to find the type name and namespace and it isn't doing this anymore. https://github.com/microsoft/msbuild/issues/4488 will fix that.