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.

Sign up for GitHub

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

Jump to bottom

.NET code ambiguous, does not build #650

Closed
RomainMuller opened this issue Jul 25, 2019 · 1 comment · Fixed by #651
Closed

.NET code ambiguous, does not build #650

RomainMuller opened this issue Jul 25, 2019 · 1 comment · Fixed by #651
Labels
bug This issue is a bug. language/dotnet Related to .NET bindings (C#, F#, ...)

Comments

@RomainMuller
Copy link
Contributor

We had to revert a commit in aws/aws-cdk#3435 because two different classes named HealthCheck were used in the same module. One was local to the module, the other from a dependency.

Since the class names were not fully qualified on declaration sites, the dotnet compiler always resolved to the local class, causing incorrect interface implementations. I suspect this is fixed in the new code generator (yet to be released), but keeping this issue for now as a beacon.
@RomainMuller RomainMuller added bug This issue is a bug. language/dotnet Related to .NET bindings (C#, F#, ...) labels Jul 25, 2019
@RomainMuller RomainMuller mentioned this issue Jul 25, 2019
Merged
RomainMuller added a commit to aws/aws-cdk that referenced this issue Jul 25, 2019
@RomainMuller
Revert "feat(autoscaling): health check configuration (#3390)" (#3435)
6b763b7 
The PR #3390 added AddCapacityOptions properties that return `@aws-cdk/aws-autoscaling.HealthCheck`, and `@aws-cdk/aws-ecs.HealthCheck` also exists. This caused the .NET code generation to emit ambiguous code that does not compile. Reverting as to enable a release.

Related: aws/jsii#650
@RomainMuller RomainMuller mentioned this issue Jul 25, 2019
Merged
@assyadh
Copy link
Contributor

assyadh commented Jul 25, 2019 •
edited
Loading

Yes this is fixed by the new generator which uses fully qualified type names only.

RomainMuller added a commit that referenced this issue Jul 26, 2019
@RomainMuller
fix(dotnet): use fully-qualified type names
67fb1a8 
Stop generating `using` statements for types referenced in a particular
file, so as to avoid running into cases where a given type (leaf) name
corresponds to a locally defined type as well as a dependent type, which
breaks compilation as `dotnet` will resolve to the local type with
higher priority than the  `using` type.

Fixes #650
@RomainMuller RomainMuller mentioned this issue Jul 26, 2019
Merged
RomainMuller added a commit that referenced this issue Jul 30, 2019
@RomainMuller
fix(dotnet): use fully-qualified type names (#651)
d32e2cd 
Stop generating `using` statements for types referenced in a particular
file, so as to avoid running into cases where a given type (leaf) name
corresponds to a locally defined type as well as a dependent type, which
breaks compilation as `dotnet` will resolve to the local type with
higher priority than the  `using` type.

Fixes #650
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug This issue is a bug. language/dotnet Related to .NET bindings (C#, F#, ...)
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

fix(dotnet): use fully-qualified type names aws/jsii
2 participants
@RomainMuller @assyadh