You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This tool has been very helpful in migrating a Asp.Net WebAPI2 solution to the newer sdk project format targeting net461 and still using EF6. This is a stepping stone towards moving to ASP.NET Core, EF Core etc.
This particular project had a large number of existing EF6 migrations, and they were all failing to be found in the ResourceManager because of the way they were previously declared (under the builtin package manager tooling). In the old csproj format they were embedded resources "dependant upon" the parent .cs file. This seems to mean that they live in a different location within the resource file, and I found that I had to edit every single previous Designer file to change the ResourceManager to be in line with what this tool does for new migrations
EG:
old csproj existing migrations private readonly ResourceManager Resources = new ResourceManager(typeof(AddSettings));
to
new migrations created by this tool private readonly ResourceManager Resources = new ResourceManager("My.Namespace.Providers.SqlServer.Migrations.201603020819490_AddSettings", typeof(AddSettings).Assembly);
By making these edits on all of the "old" migrations (50+ migrations!) to alter the ResourceManager definition, I was able to get my solution working (after the update to sdk proj format etc) and was also able to add new migrations using this tool.
However, "for science" I was interested if there was a way to avoid having to change all the previous migrations, and I did find a solution:
By explicitly defining the resx (and sql files in the cases where they existed) as embedded resources in the new sdk format csproj file, and marking them "dependent upon" the parent .cs class file - this allowed the old migrations to "work" without modification (ie, the ResourceManager when declared with only the type of the migration class was able to find the resources.
However, due to having to specify the resx files <EmbeddedResource> entry (in order to use the DependantUpon attribute), this caused the csproj project to fail as it was trying to include the resx files by default, as well as the explicit entries. This can be disabled by setting the EnableDefaultEmbeddedResourceItems project attribute to false. Setting this to false enabled me to get the project "working" without having to edit ALL of the previous migration files to change namespaces and so on.
TLDR
When using this new tool to make new migrations going forward, when the csproj has EnableDefaultEmbeddedResourceItems set to false, the resx file generated as part of the migration, needs to be EXPLICITLY defined as an EmbeddedResource, because the csproj is no longer doing that implicitly. (Note that the DependentUpon attribute is not needed in these cases, since the newly generated migraiton contain the full name space string in the ResourceManager declaration).
It would be a nice option for this tool to handle adding the embedded resource into the csproj, if that csproj has EnableDefaultEmbeddedResourceItems set to false. The workaround is of course, to edit the csproj by hand, each time a new migration is added with this tool.
I found that I had to edit every single previous Designer file to change the ResourceManager to be in line with what this tool does for new migrations
Technically, this isn't necessary, and what's causing a problem is the different method by which the new project system resolves resources. This tool simply changes the way it works with resources to make it easier for the developer.
By explicitly define the resx (and sql files in the cases where they existed) as embedded resources in the csproj file
Indeed. Although, last time I tried it (and that was when I first started working on this), I faced lots of issues.
Thanks for the investigation and the report. This is a valid request, I might try to do something about it, but I have little free time right now. So contributions are welcome. Otherwise, I will get around to handling it later when I get some time after validating this.
Hi 👋,
This tool has been very helpful in migrating a Asp.Net WebAPI2 solution to the newer sdk project format targeting net461 and still using EF6. This is a stepping stone towards moving to ASP.NET Core, EF Core etc.
This particular project had a large number of existing EF6 migrations, and they were all failing to be found in the
ResourceManager
because of the way they were previously declared (under the builtin package manager tooling). In the old csproj format they were embedded resources "dependant upon" the parent .cs file. This seems to mean that they live in a different location within the resource file, and I found that I had to edit every single previous Designer file to change theResourceManager
to be in line with what this tool does for new migrationsEG:
old csproj existing migrations
private readonly ResourceManager Resources = new ResourceManager(typeof(AddSettings));
to
new migrations created by this tool
private readonly ResourceManager Resources = new ResourceManager("My.Namespace.Providers.SqlServer.Migrations.201603020819490_AddSettings", typeof(AddSettings).Assembly);
By making these edits on all of the "old" migrations (50+ migrations!) to alter the
ResourceManager
definition, I was able to get my solution working (after the update to sdk proj format etc) and was also able to add new migrations using this tool.However, "for science" I was interested if there was a way to avoid having to change all the previous migrations, and I did find a solution:
By explicitly defining the resx (and sql files in the cases where they existed) as embedded resources in the new sdk format csproj file, and marking them "dependent upon" the parent .cs class file - this allowed the old migrations to "work" without modification (ie, the
ResourceManager
when declared with only the type of the migration class was able to find the resources.However, due to having to specify the resx files
<EmbeddedResource>
entry (in order to use theDependantUpon
attribute), this caused the csproj project to fail as it was trying to include the resx files by default, as well as the explicit entries. This can be disabled by setting theEnableDefaultEmbeddedResourceItems
project attribute to false. Setting this to false enabled me to get the project "working" without having to edit ALL of the previous migration files to change namespaces and so on.TLDR
When using this new tool to make new migrations going forward, when the csproj has
EnableDefaultEmbeddedResourceItems
set to false, the resx file generated as part of the migration, needs to be EXPLICITLY defined as anEmbeddedResource
, because the csproj is no longer doing that implicitly. (Note that theDependentUpon
attribute is not needed in these cases, since the newly generated migraiton contain the full name space string in theResourceManager
declaration).It would be a nice option for this tool to handle adding the embedded resource into the csproj, if that csproj has
EnableDefaultEmbeddedResourceItems
set to false. The workaround is of course, to edit the csproj by hand, each time a new migration is added with this tool.The text was updated successfully, but these errors were encountered: