Ability to generate contracts only & skip the client

[brandedoutcast]

When I do dotnet svcutil http://contoso.com/SayHello.svc, the svcutil generates a Reference.cs which contains the extracted Contracts & Models along with a SoapClient

It would be great to have something along the lines of dotnet svcutil http://contoso.com/SayHello.svc --skip-client to generate a Reference.cs without the SoapClient

The idea behind this request is to use a Generic Proxy which can act as a common client for multiple WCF endpoints rather than generating a client for each & every endpoint

[dasetser]

Thanks for the suggestion. Do you mean something like the /serviceContract switch from the desktop svcutil.exe? Is your proxy generated in a way that makes removing the client part yourself difficult? Or do you just want this feature to avoid having to do the manual step?

[brandedoutcast]

Yes 👍 exactly the /serviceContract switch from old svcutil

I want this feature to avoid the manual step because I'm trying to use a generic proxy class as client for all the WCF endpoints in my project & I would like to create a simple script for my team which would internally utilize the svcutil to generate the contracts so they can start using the generic proxy right away but imagine removing the auto generated client proxy for every endpoint each individual brings in 😩

Rather than trying to delete the proxy client from the script I would love this feature to be part of the svcutil itself so I can only generate what I need & avoid undoing something svcutil already did just because I don't need it

I would love to contribute 😍 to this feature but only if someone can point me in the right direction 👉

[StephenBonikowsky]

@rohith this is an interesting feature request.
Due to our backlog we won't be able to get to it in the 3.0 time frame.
@dasetser if you can point @rohith in the right direction this would be a nice way to involve the community.

[StephenBonikowsky]

@rohith I discussed this with @dasetser and we want to keep this on our list of things to do, we wouldn't do the work on the desktop svcutil.exe, there has been some work done on making a WCF Core version of the tool but it isn't yet ready.

Thanks for bringing it to our attention.

[dasetser]

@rohith I had a miscommunication with Stephen about this and wanted to make sure we were clear. The desktop version of svcutil.exe already has this feature, and this request is to add the same feature to the WCF core version of the tool (dotnet-svcutil.exe). We will not be able to get to this in the 3.0 timeframe, so we moved this to our backlog to investigate in the future.

Unfortunately you can't contribute to this feature yourself because dotnet-svcutil.exe is not currently open source.

[brandedoutcast]

I appreciate the info & I'm just glad to know this will be worked on. Thanks @dasetser @StephenBonikowsky

[dasetser]

@rohith For now can you try using the normal svcutil.exe to generate this? The difference between svcutil and dotnet-svcutil is that dotnet-svcutil filters out parts of the code that are not compatible with .NET Core. However, if you only want the service contract piece that's just an interface that should be the same for both frameworks. So the contract svcutil.exe generates should work for .NET Core as well.

[brandedoutcast]

@dasetser yup that's what I did, I only used the contracts

[StephenBonikowsky]

FYI moving dotnet-svcutil.exe to open source is also on our radar. #3191

[maxild]

P3 (priority 3) does that mean the --serviceContract feature will not be ported from the desktop svcutil tool in near future?

[HongGit]

@brandedoutcast for your information, dotnet-svcutil tool is now open source in this repo, under src\dotnet-svcutil. Feel free to submit a PR.