Since v10.0.652802 several types are not included

[ronaldcreutz-vw]

Describe the bug
I'm using the svcutil tool to generate the proxy classed based on a wsdl file on linux (ubuntu).
I references the libraries in my dotnet 8 project:
System.ServiceModel.Http and System.ServiceModel.Primitives, both in version 8.1.2. All working properly.

After I changed the version of that references libraries to 10.0.652802, I got the compilation errors. Because a lot of types in the generated file (by svcutil) are not included anymore. The version of the dotnet 8 - i didn't change.

To Reproduce
Steps to reproduce the behavior:

1. Take a wsdl and generate client classes with svcutil
2. Take a look in generated class (in my case the name is Reference.cs
3. A lot of types are missing, e.g. The type or namespace name 'MessageContractAttributeAttribute' does not exist in the namespace 'System.ServiceModel', The type or namespace name 'MessageContractAttribute' does not exist in the namespace 'System.ServiceModel', The type or namespace name 'MessageHeaderAttributeAttribute' does not exist in the namespace 'System.ServiceModel' and many more

Expected behavior
I tryed to reference additional libraries, but this do not solve the problem. Because I used the current version of svcutil tool, I expect that all classes are known.

Screenshots
If applicable, add screenshots to help explain your problem.

Additional context
Add any other context about the problem here.

[jzabroski]

Can someone from Microsoft or the .NET Foundation supporting WCF please comment? It seems like the right move is to delist this package. - The release notes for WCF are extremely thin: https://github.com/dotnet/wcf/releases/tag/v10.0.0-rtm - The really weird part is that when you look at the release notes for "what's changed" via commit log, the last commit in the commit log prior to publish failed to build in Arcade. v8.1.2-rtm...v10.0.0-rtm - I am not saying this is the root cause, but there are a number of hints that suggest this was not packaged correctly. I also asked Matt Mitchell on the DevBlogs site about this, as I honestly don't even understand why there were 99+ commits for 2 features, although I think it probably had something to do with reworking the .NET Core infrastructure for CI processes.

[mmitche]

@mconnew to investigate

The WCF component is in a layer on top of .NET as it is related to the product construction process from the blog post, so I don't know a lot about its specifics. However, it seems odd that the svcutil is generating references to types that don't exist in the newer WCF packages. I think I would have expected a new svcutil to be shipped with the 10.0 release. I'm also a little confused about the versioning that came out. I would have expected 10.0.0?

That said, I don't think this is a result of infra changes related to Unified Build.

[m0sa]

The 10.0.0 release packages don't work with anything targeting net9 or below. It only works when targeting net10 TFMs.

[jzabroski]

@m0sa Maybe, but the packaging suggests otherwise and claims to support a very wide range of frameworks.

[m0sa]

This is what I see, most simple repro is in linqpad, referencing the v10.0 package and switching between target runtimes:

I do see the same issue in real-world projects, after dependabot updates, too...

[mmitche]

@jzabroski Yeah, I would expect that if netstandard is supported, that all functionality that svcutil generates would be supported on netstandard. I'm wondering whether svcutil just didn't get an appropriate release.

[jzabroski]

Yes, the main branch seems to imply the code exists.

wcf/src/System.ServiceModel.Primitives/src/netstandard.cs

Lines 870 to 876 in 319e64f

	public sealed partial class MessageContractAttribute : System.Attribute
	{
	public MessageContractAttribute() { }
	public bool IsWrapped { get { return default; } set { } }
	public string WrapperName { get { return default; } set { } }
	public string WrapperNamespace { get { return default; } set { } }
	}

I do not understand enough about what the System.ServiceModel.Primitves.csproj is trying to achieve to comment much further.

[Patrick-3000]

Maybe I am wrong, but in my opinion the package suggests on Nuget that it supports e.g. .NET 8:

[Montago]

related issue: #5869

[mconnew]

The reason for supporting netstandard2.0 is because the package has type forwarding facades for .NET Framework so that you can compile a library against netstandard2.0 using the WCF Client packages and that library will work on .NET Framework and .NET 10.0. For a while we dropped this and only declared net6.0 and recommended to multi target a library to .NET Framework and .NET instead of targeting netstandard2.0. We got some push back for that, and we ended up creating a problem for PowerShell for a related change. PowerShell 7.x allows you to use modules compiled for PowerShell 5.1 (which runs on .NET Framework). Some of these modules ship with Windows Server (there's one for managing Active Directory for example). Starting with one of the later WCF Client 8.x releases, I added back the support for .NET Framework and added back the netstandard2.0 contracts too.
I'll break down the list of declared supported TFM's (the dark blue ones at the top) to explain what it means. I'll be doing it out of order from what's displayed from NuGet.org as it's easier to explain this way.

.NET 10.0

We ship an implementation which works on .NET 10.0 and later.

.NET Standard 2.0

This has reference assemblies with a set of API's which are available in both .NET Framework and in the .NET 10.0 implementation. This API surface is smaller than what's available in .NET 10.0 or .NET Framework separately. The implementation assemblies just throw and contain no implementation. This is because every platform not built on .NET that supports netstandard2.0 ships with its own implementation of WCF in-box. For example, the older Xamarin platform (pre-maui) ship with an implementation of WCF based on mono. .NET Native ships its own copies of the libraries in-box too. And of course, .NET Framework has its own implementation. The only platforms which don't are one's based on .NET, which we ship in the NuGet packages. So we don't need to ship an implementation for netstandard2.0, which is why they throw. We could have excluded the runtime assemblies, but then if you compiled a library against netstandard2.0, and then tried to consume it in a net8.0 app, you would have got an exception about a missing assembly which is a lot more confusing.

.NET Core 2.0

This is here as we include an empty reference assembly folder in the package for .NET Core 2.0. This is so that if you attempt to use the WCF 10.0 packages on an older .NET runtime such as .NET 8.0, you won't be able to compile your app. If this wasn't there, apps targeting .NET 8.0 would pick up the netstandard2.0 reference assemblies and compile without error. The search order for looking for reference assemblies causes the netcoreapp2.0 ref folder to be chosen before the netstandard2.0 ref folder for all tfm's from netcoreapp2.0 through to net9.0. Without this, a project targeting an older tfm would pick up the netstandard2.0 reference assemblies at compile time, then at runtime it would pick up the netstandard2.0 runtime assemblies which are just dummy implementations which throw. This decision was made to cause early failure. It's worse to have a false sense of the package working for older versions and doing a bunch of development and then only finding out at runtime that it doesn't work. Having a folder preventing compilation for all tfm's from .NET Core 2.0 to net9.0 is what causes the longer list of supported tfm's in the lighter blue shade.

.NET Framework 4.6.2

This is here to support compiling and running on .NET Framework 4.6.2+, and does it in two different ways, whether you are compiling or running. For compilation, no reference assemblies are provided. It simply adds references to your project for several .NET Framework assemblies such as System.ServiceModel.dll and your app will compile directly against those assemblies. If you are using a library compiled against netstandard2.0 in an app targeting .NET Framework, the package provides type forwarding facades redirecting all the types that the library is expecting to find in the NuGet package assemblies to the .NET Framework implementation.

As you can hopefully see, this confusion is caused by needing to support compiling a library against netstandard2.0 which can be used on .NET Framework and .NET while only carrying a runtime implementation for .NET as .NET Framework has its own implementation.

We could improve things by including a targets file for netcoreapp2.0 which causes a build error with an error message saying to use the appropriate package version for the tfm you're using. Many of the .NET runtime packages are doing a similar thing. The difference is that they do ship an implementation that only needs netstandard2.0, but the build targets file creates a warning saying it's untested.

The WCF Client way of handling this is to use the newest release that is supported on all intended TFM's. .NET 8.0 is the oldest supported .NET release, so if you aren't sure where your code will be used (e.g. it's in a library), then use WCF Client 8.1.2. If you need to support older out of support runtimes, then use the older out of support WCF Client version which goes with it.

@jzabroski, the failed build you saw was on the public Azure Devops project. Around the time of building the packages, there was a problem with the Helix build system where some test queue's weren't picking up work. That's not where this build comes from. We have a separate internal Azure Devops project which is a lot more isolated to ensure a more secure build environment (e.g. PR's can't be built and run through it), and that's what's used for the NuGet releases. This is the history for that build:

I've included the prior similarly failed build in the screenshot, and you can see that I ran it again after the build system problem was resolved.

I hope this explanation helps clear things up. Please let me know if you need anything further clarified.

[jzabroski]

Thank you... I certainly didn't want to have you explain all that.

I didn't think to look in the netcore2.0 folder when browsing the unzipped package. Although I should have thought to look in there, I had not seen this particular idiom before elsewhere.

It does seem like there needs to be a better story around netstandard2.0, but that should not necessarily be your job to solve.

[mconnew]

@ronaldcreutz-vw, is my explanation sufficient? Are you okay with closing this issue?

[jzabroski]

I would recommend closing it and PIN an issue describing the support model, which is essentially block quoting your reply above via "Reference in new issue".

[ronaldcreutz-vw]

@mconnew
Maybe a better notice in the release notice would be helpful for next time, that this version only support dotnet 10 (if understood it correctly). Thanks a lot for clarification.
From my point of view you can close this issue.

[jzabroski]

can you add a build.targets file so that if the fallbacktargetframework is netcore2.0, it uses the Error task? Ideally this happens right before Build task.