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

Sharing Data Contracts #5632

Open
mrosenthal1058 opened this issue Aug 19, 2024 · 1 comment
Open

Sharing Data Contracts #5632

mrosenthal1058 opened this issue Aug 19, 2024 · 1 comment
Assignees
Labels
tooling An issues related to any tool shipped from this repo.

Comments

@mrosenthal1058
Copy link

Describe the bug
My application has 8 Services, so I am running dotnet-svcutil on each service to generate a separate service reference for each with a unique namespace for each. The problem occurs when I consume multiple services in the same client, and reference a data contract that is shared among two or more of the consumed service. In the consuming client, I see a bunch of "'DataContractModel' is an ambiguous reference between 'WS_1_WebServiceNS.Data.DataContractModel' and 'WS_2_WebServiceNS.Data.DataContractModel'". Before conversion, I used this command: "svcutil.exe" ..\My.Service.Contracts.dll /directory:........\deployment to generate a unified wsdl and xsd for shared Data Contracts, and then "svcutil.exe" ..\deployment*.wsdl ..\deployment*.xsd /language:C# /n:http://tempuri.com/MyService/2016/05,WebServiceClient /n:http://tempuri.com/MyServiceData/2016/05,WebServiceClient.Data /o:..\My.Service.Client\MyWebSvcClientApiAuto.cs /config:..\My.Service.Client\App.config

Expected behavior
A method to either generate service references with a shared data component, or an ability to output a generated client class which avoids the namespace collisions.

Am I missing something? The only workaround I can come up with is to somehow merge the 8 wsdl documents, but using the old wsdl tool, won't generate a dotnet Core valid wsdl document.

@HongGit HongGit added the tooling An issues related to any tool shipped from this repo. label Aug 20, 2024
@mrosenthal1058
Copy link
Author

I was able to resolve this by using a Reference to the common project where the Model contracts were located. So for each dotnet-svcutil command, I passed a
-r "..\My.Services.Models\My.Services.Models.csproj", and now it works like a charm.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
tooling An issues related to any tool shipped from this repo.
Projects
None yet
Development

No branches or pull requests

3 participants