Code files simplification suggestion

hi guys,

After I cloned CoreWCF and opened the solution using Visual Studio, I see some linked files repeated everywhere:

Why are the projects organized like this? I know the magic is in the Directory.Build.targets file, but it is not quite easy to reason by directly looking at the csproj, because the linked files weren’t there.

These “Common” files I think should be just included as part of CoreWCF.Primitives project, because it is used by both CoreWCF.Http and CoreWCF.NetTcp.

It is also easier for me to maintain. If my feedback is accepted, I’d like to submit PR to include those files in “Common” into CoreWCF.Primitives project.

cc @tibor19

[mconnew]

@eriawan, are you still interested in working on this?

[mconnew]

The ASP.NET Core team tried to do the internal namespace thing too. The problem is having it public still results in people using it which then stops you from modifying internal implementations. My preference is to reduce the amount of internal stuff as much as possible and just make things public where applicable. A great example is the EnvelopeVersion and AddressingVersion classes. There’s a bunch of useful internal properties which are used all through the code base to inform various components about strings needing to be used in the SOAP messages. For example there’s AddressingVersion.Anonymous which is used to set the To SOAP header for when using anonymous addressing for the reply (such as when using HTTP reply where the response message is naturally tied to the request so no need to address the message).

Some of the stuff in the code might be a bit confusing for why I did it a particular way. There’s a bit of history, this code base started off as a hacked up prototype. The intention of how the code would work with everything else changed multiple times. Eg should it be System.ServiceModel namespace, should we build on top of the client libraries which carry a lot of the primitives classes, should it consume ASP.NET Core or should ASP.NET Core consume this. This code morphed a few times with different ways it could be released. So there’s still some left over patterns based on past assumptions which are now irrelevant. Don’t be shy about suggesting improvements. For instance, making the AddressingVersion and EnvelopVersion api’s public to remove some helpers I think I wrote to make them usable in other packages. My main heuristic is whether the api is the same shape as on .NET Framework and it’s unlikely to change and neither is it’s behavior.

The main candidates for putting into a Private package are things like metrics and ETW eventing as well as common helpers. Things which aren’t related to actually sending messages back and forth, but are part of the infrastructure for how CoreWCF gets things done, but also aren’t things which an external extensibility would use. For example, a 3rd party transport should have it’s own ETW provider.