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

Compiled Models: Entity Type Namespaces #30945

Closed
jamezamm opened this issue May 22, 2023 · 8 comments
Closed

Compiled Models: Entity Type Namespaces #30945

jamezamm opened this issue May 22, 2023 · 8 comments

Comments

@jamezamm
Copy link

jamezamm commented May 22, 2023

I have a scenario where two entity types are named the same but under different namespaces: Schema.UnitMove & SchemaLite.UnitMove.

Even tough in the compiled model, the class name of the compiled entity type is resolved to UnitMoveEntityType & UnitMove0EntityType, the project still gives me compile time errors as the reference to the classes do not include the namespace.

Actual result - Without type qualifier
var gkey = runtimeEntityType.AddProperty(
"Gkey",
typeof(long),
propertyInfo: typeof(UnitMove).GetProperty("Gkey", BindingFlags.Public | BindingFlags.Instance | BindingFlags.DeclaredOnly),
fieldInfo: typeof(UnitMove).GetField("<Gkey>k__BackingField", BindingFlags.NonPublic | BindingFlags.Instance | BindingFlags.DeclaredOnly),
valueGenerated: ValueGenerated.OnAdd,
afterSaveBehavior: PropertySaveBehavior.Throw);

Expected result - With type qualifier:
var gkey = runtimeEntityType.AddProperty(
"Gkey",
typeof(long),
propertyInfo: typeof(Schema.UnitMove).GetProperty("Gkey", BindingFlags.Public | BindingFlags.Instance | BindingFlags.DeclaredOnly),
fieldInfo: typeof(Schema.UnitMove).GetField("<Gkey>k__BackingField", BindingFlags.NonPublic | BindingFlags.Instance | BindingFlags.DeclaredOnly),
valueGenerated: ValueGenerated.OnAdd,
afterSaveBehavior: PropertySaveBehavior.Throw);

@ajcvickers
Copy link
Member

Likely covered by #27203

@jamezamm
Copy link
Author

jamezamm commented May 23, 2023

Setting aside the mentioned workaround, is this issue planned to be properly resolved?

@jamezamm
Copy link
Author

The workaround mentioned here no longer works since CSharpHelper is an internal API, thus cannot be accessed.

@roji
Copy link
Member

roji commented May 23, 2023

CSharpHelper has always been a "public internal" API; that means it's public and you can use it, but it's defined in an Internal namespace. This means that it may change across releases, but if you're OK with that there shouldn't be any problem using that.

Note that we have an analyzer that reports a warning when you do this, to prevent accidental usage. But you can suppress that warning.

@jamezamm
Copy link
Author

The below still gives a compile time error "The type or namespace 'CSharpHelper' does not exist in the namespace 'Microsoft.EntityFrameworkCore.Design.Internal'". What am I doing wrong? CSharpHelper Github

#pragma warning disable EF1001 // Internal EF Core API usage.
internal class CSharpHelperWithQualifiedNames : Microsoft.EntityFrameworkCore.Design.Internal.CSharpHelper
#pragma warning restore EF1001 // Internal EF Core API usage.

@ajcvickers
Copy link
Member

@jamezamm Make sure to fully reference the Design package, without excluding any assets. For example:

<PackageReference Include="Microsoft.EntityFrameworkCore.Design" Version="7.0.5" />

@jamezamm
Copy link
Author

@ajcvickers Thanks it worked.

Does this workaround affect anything else, apart compiled models?

@ajcvickers
Copy link
Member

@jamezamm Possibly. Let us know if it changes either migrations or scaffolding for you.

@ajcvickers ajcvickers closed this as not planned Won't fix, can't repro, duplicate, stale May 31, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants