We Keep Coding

gRPC - Correct way to separate client and servers into different projects (.NET)

We are transitioning a WCF based solution over to use gRPC.
We require both the Service and Client code generation that the Grpc.Tools package provides. However, we need the Clients to target .NET Standard 2.0 for comparability reasons.
Services need to call other services, so those projects need to be able to consume both the service stubs and the client stubs.
We also don't really want the service stubs to be exposed to consumers just wanting to use the gRPC clients.
This is proving a challenging requirement to satisfy.
Trial 1:
Have two projects, both importing the same proto files, each set to generate either the Server or Client.
Problem: A consuming project can't reference both server and client project due to the generated messages having duplicate namespaces.
The C# namespace is defined in the proto file itself.
Trial 2:
Separate the proto files out into messages and services. Have a models project which only generates the messages into code.
Have the client and service projects reference the models project, and import the services proto files to have them generate the stubs they need.
Problem: gRPC generates the stubs inside of a static class, which again has the same namespace in both projects so a consumer is unable to determine which version to use.
I now have two routes I can go down.
Option A:
In both the client and server projects, create classes which inherit from the gRPC generated ones so they can be exposed onto a different namespace.
For the services, this isn't so bad. The clients however have two constructors and a instance generation method which would need to be brought over to the child class.
Option B:
Create duplicate proto files for the service definitions, one having a namespace for the service stub and the other having the namespace for the client stub.
Both options have their downsides. Option A is probably the least bad as it doesn't require two files to be manually kept in sync.
Does anyone have any alternative recommendations?
Ideally there would be a way to alter the namespace defined in the proto files somehow when using Grpc.Tools, but reading the documentation, there doesn't seem to be a way to do that.

How does the WSCF.Blue DataContract generation feature work?

I'm trying to figure out how the WSCF Blue DataContract generation feature works.
It's documented here: http://alexmg.com/post/2009/09/01/Data-contract-generation-is-now-available-in-WSCFblue.aspx
I have a set of WSDL and XSD files from which we can use the "regular" method to create web service code.
The service generated does not allow you to use data contracts at the client end, meaning we get lots of Array types instead of List types.
Or more accurately, we can't get Lists, only Arrays so this means it's not using DataContracts.
So, when generating service code on the server side I get two options.
Use the regular option, generates an abstract class from which we create a concrete Service class
Use the "Generate Data Contract" option. This creates a .cs file containing just classes representing the the Xsd types, no abstract classes for the service.
So if I then try to generate the service classes with the regular options, I now have lots of duplicate classes representing the Xsd types.
I clearly have the wrong end of the stick.
Has anybody managed to make WSCF.blue work with DataContracts instead of the XmlSerializer?

Same object in multiple webservices result in duplicate classes

We have several .Net webservices that we use a java client for. Each webservice has it's own namespace, but they all use a lot off common classes. When these are exposed as WSDLs, then generated into Java code, we get a lot of duplicates in Java of the same .Net classes.
Is there a way in .Net to define a set of WebService objects to be exported under a shared namespace (in XML)? Or can we when we use wsimport in Java to generate just one instance of each duplicate class?

From service side, one of the option could be to have specially crafted single WSDL describing all services. See this article for how to do it (applicable for asmx services).
On side note, for .NET clients, its quite simple to use wsdl tool with sharetypes options to have common types generated once and re-used among multiple service proxies. Hopefully, similar tools/options perhaps exist at java client side.

The -p option of wsimport allows you to override the namespace specified in the WSDL to a package that you specify. If you specify the same package for each WSDL you'll only end up with one instance of each class.

Is there a way to export an XSD schema from a DataContract

I'm using DataContractSerializer to serialize/deserialize my classes to/from XML. Everything works fine, but at some point I'd like to establish a standard schema for the format of these XML files independent of the actual code. That way if something breaks in the serialization process I can always go back and check what the standard schema should be. Or if I do need to modify the schema the modification is an explicit decision rather then just a later affect of modifying my code.
In addition, other people may be writing other software that may not be .NET based that would need to read from these XML files. I'd like to be able to provide them with some kind of documentation of the schema.
Is there some relationship between a DataContract and an XSD schema. Is there a way to export the DataContract attributes in classes as an XSD schema?

Yes, you can use XsdDataContractExporter.
An example is provided in the MSDN article Exporting Schemas from Classes.

Svcutil.exe can "export metadata for compiled data contracts".
There is relationship between DataContract and XSD:
The DataContractSerializer maps CLR types to XSD when metadata is exported from a Windows Communication Foundation (WCF) service using a metadata endpoint or the ServiceModel Metadata Utility Tool (Svcutil.exe). For more information, see Data Contract Serializer.
The DataContractSerializer also maps XSD to CLR types when Svcutil.exe is used to access Web Services Description Language (WSDL) or XSD documents and generate data contracts for services or clients.
You can get the XSD(s) at run-time as well, even in your browser, by setting up a MEX endpoint.
The WSDL by default will contain references to XSD(s) that can be accessed through the endpoint as well.

You might be able to generate schema files from DataContracts using the svcutil.exe tool that comes with Visual Studio.
svcutil myAssembly.dll
- Generate metadata documents for Service Contracts and associated types in an assembly
svcutil myServiceHost.exe /serviceName:myServiceName
- Generate metadata documents for a service, and all associated Service Contracts and data types in an assembly
svcutil myServiceHost.exe /dconly
- Generate metadata documents for data types in an assembly
I believe I messed with this at one point in the past, and may or may not have gotten it to work. Another easy way to generate schemas is to stand up a WCF service that uses your data contracts, and access the WSDL. The WSDL will import all the xsds for the DataContracts.

/sharedtypes equivalent for svcutil.exe?

Building an app that is relying on a 3rd party provider who has a very verbose set of SOAP services (we're talking 50+ WSDL files). Each individual WSDL however has numerous shared type declarations. When generating client code with wsdl.exe, there used to be a /sharedtypes flag that would merge duplicate entries if a type was found several times.
When I attempt to generate my client code, I bomb on these overlapping types that the 3rd party includes in all their WSDL files.
svcutil /t:code /importxmltypes [mypath]/*.wsdl
Results in error messages alluding to the type collisions. For example, a couple samples of the error messages below:
Error: There was an error verifying some XML Schemas generated during export:
The simpleType 'http://common.soap.3rdparty.com:CurrencyNotation' has already been
declared.
Error: There was an error verifying some XML Schemas generated during export:
The complexType 'http://common.soap.3rdparty.com:NumberFormat' has already been
declared.
I do not have control over the output of the WSDLs. I do not want to have to edit the WSDLs by hand for fear of an error that breaks in a fashion at runtime that would be highly difficult to track back to our editing of the WSDL files. Not to mention that there are 50 some WSDL files that range from 200-1200 lines of XML. (Remind me again why we thought SOAP was the great salvation to us all back in the late 90s?)

Try specifying all the WSDLs in one command:
svcutil http://example.com/service1?wsdl http://example.com/service2?wsdl ...
This should automatically take care of duplicate types. Another option is to take a look at the /reference command switch:
/reference:<file path> - Add the specified assembly to the set of
assemblies used for resolving type
references. If you are exporting or
validating a service that uses 3rd-party
extensions (Behaviors, Bindings and
BindingElements) registered in config use
this option to locate extension assemblies
that are not in the GAC. (Short Form: /r)
This means that if you already have some types defined in some assembly you may include this assembly and svcutil will exclude types from it to avoid duplicates:
svcutil /reference:someassembly.dll http://example.com/service?wsdl

I was having similar problems. By defining different CLR namespaces for the different xml namespaces (using the /namespace argument of svcutil) i was able to get it working.
/namespace:http://www.opengis.net/gml,OpenGIS.GML

I have been using wsdl.exe to get round this because I work with some SOAP webservices which define the same data transfer objects at different endpoints. So I use wsdl.exe because it has the sharetypes switch. I'm not a WPF developer so I don't really care that the output does not implement IWhatever for WPF, but the classes generated are all partial so you can do some work to implement interfaces you care about in a separate file.