Reputation: 161773
I need to access a Java-based service which defines a portType
element in the same namespace used by one of the schema files it imports. Unfortunately, that schema includes a complexType
with the same name as the portType
!
The problem is that "Add Service Reference" uses the name of the portType
to create the name of the service contract, and creates a class
with the name of the complexType
- and it creates them in the same .NET namespace. That doesn't work!
Is there something I can do, either in the "Add Service Reference" dialog, or in the .svcmap file, to "rename" the service contract type?
A closely related question is - is there something I could do about this if the portType
and complexType
were in different namespaces (as, IMHO, they should be)?
Upvotes: 3
Views: 1795
Reputation: 1451
I think the short answer, unfortunately, is "no".
Is it even remotely possible to try to persuade the maintainers of the Java service to remove the ambiguity from their interface? If so, I'd suggest lobbying for this change as hard as possible, because the rest of your options aren't that great:
You could try using the ExcludedTypes
element in the .svcmap file to force the service reference to not generate the complexType
that conflicts with the portType
. If you actually need to use that complexType
, you would need to implement it manually, which is a bummer.
You could manually edit the Reference.cs
file to change the name of the one of the conflicting types, as others have suggested. But then everyone maintaining the code would need to remember to carry out this manual edit every time the service reference is regenerated, which is a bummer.
You could play with the NamespaceMappings
element in the .svcmap file, but it only allows you to rename an entire namespace, not individual types within that namespace, which is a bummer.
You could create a service contract interface manually (assuming that this is the type that is generated from the portType
), and then use the ServiceContractMappings
element in the .svcmap file to use that type instead of auto-generating it. But then of course you'd have to maintain that interface manually, which is a bummer. (This is probably the best option, IMO, if you are unable to persuade the service maintainers to change their service).
Upvotes: 3
Reputation: 1171
You could edit the generated classes as dustinmorris suggests. However if you ever need to update the service reference this becomes problematic as it will regenerate these classes.
Better would be to split them into 2 different namespaces as you suggest, this would work.
The best solution is probably to fix the java service if possible and give more meaningful names to the two conflicting items so the service is more understandable.
Upvotes: 1
Reputation: 3361
In Visual Studio you can select your project in the solution explorer and on the top you have a small collection of icons. From the right hover with the mouse over them and you will find one called "Show All Files". This will show hidden files, like the classes which are created by the service reference (now you should have the arrow to expand it).
You have full control over these classes. You can rename them, put them in a different namespace, etc.
Upvotes: -1