Configure Web Service Reference - Reuse types in referenced assemblies - Still broken

[PhilPJL]

Create a web service reference with a shared assembly. If the DTO has a DataContract that specifies a namespace the type isn't reused.

This bug was supposed to have been fixed. It appears to be fixed if the DataContract doesn't have a namespace.

Say we have the shared type

[DataContract]
public class CompositeType

This is reused.

But if we have

[DataContract(Namespace = "nowhere.com")]
public class CompositeType2

it isn't.

See the attached sample app. WCFTest.zip

Expected behavior I expect shared types to be reused whether they have an explicit namespace or not.

Screenshots

Additional context VS 16.3.0 Preview 1.0

[StephenBonikowsky]

Thanks for reporting this @PhilPJL @dasetser can you take a look when you have time please.

[StephenBonikowsky]

Needs to be fixed but lower priority.

[PhilPJL]

@StephenBonikowsky This isn't low priority for us. We have 20 WCF services which all use shared types across our code base. If we want to move to .NET Core (which we do because we're now developing for Xamarin/Android) this is a big problem. Obviously we can get rid of WCF and switch to WebApi or Grpc but really shouldn't have to.

If you do get around to fixing this don't forget it's possible for a WCF service to consume two (or more classes) with the same name disambiguated by namespace, e.g

namespace Company.Project1.Types { [DataContract(namespace="namespace1)] public class AThing {} }

namespace Company.Project2.Types { [DataContract(namespace="namespace2)] public class AThing {} }

[StephenBonikowsky]

Thanks for the additional context @PhilPJL we will discuss this further.

[PhilPJL]

@StephenBonikowsky: When if ever will this be fixed?

[StephenBonikowsky]

@dasetser We need to add this issue into our planning for 3.1 Servicing/5.0 release. Going to add it to 3.1.1 for right now to make sure we don't miss it.

[Thraka]

@StephenBonikowsky @dasetser Please make sure you update the docs to either indicate the current problem (as in something isn't working as expected) and to update it when it's fixed.

Content: https://github.com/dotnet/docs/blob/master/docs/core/additional-tools/wcf-web-service-reference-guide.md Bug: dotnet/docs#16024

[PsMaster]

We're using 3rd party services which we have no control of, they provide about 40 services which use common types but each service has different namespaces. When I add the references none of the types are reused, no matter where the common assemblies are placed (same or reference project). Tried adding DataContract attributes with or without namespaces, it just doesn't work. A huge blocker since we can't properly integrate to third party services. The only option at this point would be to use 40 different namespaces and map between all types, which is just crazy in terms of development time, performance and maintenance...

[StephenBonikowsky]

@dasetser The wcf-web-service-reference-guide mentions looking at the Release notes for "Known Issues".

Currently the Release notes doesn't mention any known issues, can we add a section in there with this issue?

[mishael-o]

Has there been any traction or work around on this, as we are currently stuck when migrating our existing project to .net core.

[StephenBonikowsky]

We are working on the last couple of fixes for the dotnet-svcutil 2.0.3 release which is expected to be completed soon. This issue is planned for the following release dotnet-svcutil 2.0.4.

[conckrish]

We have 12 WCF service which are using shared namespaces. Any workaround for this issue? Thanks

[PhilPJL]

@dasetser

I've managed to fix this bug locally, but I'm not 100% confident my solution is correct since I had to turn off assembly signing.

Steps:

1. Download latest source
2. Turn off assembly signing in the dotnet-svcutil-lib project or it won't build for me (no .snk)
3. I need to apply the fix mentioned here https://github.com/dotnet/wcf/issues/4308 so I can debug using NoBootstrap (-nb)
4. Comment out the contents of "...\wcf\src\dotnet-svcutil\lib\src\FrameworkFork\System.Runtime.Serialization\System\Runtime\Serialization\DataContractAttribute.cs" and DataMemberAttribute.cs

The problem I found when debugging is that TryGetDCAttribute fails to find the DataContractAttribute. Then all referenced types get the default namespace "http://schemas.datacontract.org/2004/07/" which causes the issue with reuse.

        internal static bool TryGetDCAttribute(Type type, out DataContractAttribute dataContractAttribute)
        {
            dataContractAttribute = null;

            // Problem: GetCustomAttributes returns empty collection
            object[] dataContractAttributes = type.GetTypeInfo().GetCustomAttributes(Globals.TypeOfDataContractAttribute, false).ToArray();
            if (dataContractAttributes != null && dataContractAttributes.Length > 0)

Below, with my fix, the test type 'CompositeTypeWithNamespace' gets the correct namespace and Reference.cs is generated correctly.

I'm not 100% sure this is a valid fix because I've had to turn of assembly signing, which may be the reason GetCustomAttributes never returns anything.

test.zip

[SamJongenelen]

Any update on the progress @imcarolwang ?

[pekkah]

Any update on this? Causing major headache in government projects where Soap is the new thing.

[PhilPJL]

Hey it's priority 1. Must be fixed soon.

Wait, it's been priority 1 for a year. Hmmm. Stopped holding breath a long time ago.

[StephenBonikowsky]

@mconnew @HongGit

[haldiggs]

We have 12 WCF service which are using shared namespaces. Any workaround for this issue? Thanks

I am in the same boat. I need the contracts that have namespaces to be reused. Not a low priority. Production needs to be production and use correct namespaces.

[PhilPJL]

[haldiggs]

I had really hoped that. Net 5.0 would have heralded the fix for this issue. Having duplicate objects generated all over the place creates its own little personal hell and sync issue.

We work with banks and other Financial entities that don't just jump up and change their code every year because we have a new version. This issue really need some attention. Of course the workaround is to simply delete all the references that the generator generates. It's not pretty and you better hope the next guy understands what you did

[pekkah]

As an workaround we use AutoMapper to map between the same types in different namespaces. Our mapping profile automatically creates maps between same named types in given namespaces. This works but as the object graphs are complicated it adds a large performance penalty to the code. Maintenance is also tedious.

[lisyandi]

Any solution for this issue?

[brewfreedom]

This is pathetic. I swore this also used to work. A decade ago or so. Can we get a commitment to see this fixed by 2030?

[imcarolwang]

This is fixed in the latest release of the tool, download it from nuget.org to get the fix.