Skip to content

Conversation

@rainersigwald
Copy link
Member

Code generated by Resources.tt->Resources.cs assumes a resource naming convention that isn't compatible with the DependentUpon convention, so disable it for this project.

wtgodbe and others added 6 commits September 24, 2019 13:12
Code generated by Resources.tt->Resources.cs assumes a resource naming convention that isn't compatible with the DependentUpon convention, so disable it for this project.
@wtgodbe
Copy link
Member

wtgodbe commented Sep 27, 2019

Still seeing the test failures:

System.Resources.MissingManifestResourceException : Could not find the resource "System.Data.Entity.Properties.Resources.resources" among the resources "System.Data.Entity.Resources.Strings.resources", "System.Data.Resources.AnnotationSchema.xsd", "System.Data.Resources.CodeGenerationSchema.xsd", "System.Data.Resources.CSDLSchema_1.xsd", "System.Data.Resources.CSDLSchema_1_1.xsd", "System.Data.Resources.CSDLSchema_2.xsd", "System.Data.Resources.CSDLSchema_3.xsd", "System.Data.Resources.EntityStoreSchemaGenerator.xsd", "System.Data.Resources.SSDLSchema.xsd", "System.Data.Resources.SSDLSchema_2.xsd", ... embedded in the assembly "EntityFramework", nor among the resources in any satellite assemblies for the specified culture. Perhaps the resources were embedded with an incorrect name.

<AssemblyVersion>6.0.0.0</AssemblyVersion>
<DefineConstants>$(DefineConstants);INTERNALS_INVISIBLE</DefineConstants>

<!-- Properties\Resources.tt expects a path that does not match the class in Properties\Resources.cs -->
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it worth changing the code to use the conventional name?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a great question I leave up to the maintainers. It didn't seem trivial, but I don't know the history of the Resources.tt approach or the details of its implementation.

@rainersigwald
Copy link
Member Author

So it looks like I fixed almost all the errors, but there's two instances of this:

Actual string does not match the message defined in resources.
Expected:'Spatial readers can only be produced from readers of type SqlDataReader. A reader of type Castle.Proxies.DbDataReaderProxy was provided.',
Actual:'The provider did not return a 'DbSpatialServices' instance. In order to use the 'DbGeography' or 'DbGeometry' spatial types the EF provider being used must support spatial types and all prerequisites for the provider must be installed. See http://go.microsoft.com/fwlink/?LinkId=287183 for details.'
Expected: True
Actual: False

@wtgodbe do you think that's resource-related?

@rainersigwald
Copy link
Member Author

@ajcvickers, do you know (or know who might know) what might be up with that remaining error? Is it likely to be related to resource naming?

@ajcvickers
Copy link
Contributor

@bricelam @rainersigwald @dougbu This was happening while I was on vacation; sorry for missing it. Does this change need to go in for the 3.1 release train?

@dougbu
Copy link
Contributor

dougbu commented Nov 5, 2019

I believe @wtgodbe incorporated this proposal in #1291. @rainersigwald / @wtgodbe do we need this PR for something else?

@ajcvickers
Copy link
Contributor

This PR has been closed because EF6 is no longer being actively developed. We are instead focusing on stability of the codebase, which means we will only make changes to address security issues. See the repo README for more information.

@ajcvickers ajcvickers closed this Apr 25, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants