dotnet / wcf

This repo contains the client-oriented WCF libraries that enable applications built on .NET Core to communicate with WCF services.
MIT License
1.72k stars 558 forks source link

CS0108 in generated client code #5595

Open dan-olsen opened 5 months ago

dan-olsen commented 5 months ago

Describe the bug While generating a client from a WSDL with dotnet-svcutil (version 2.1.0) we are seeing a CS0108 error.

error CS0108: 'OurServiceNameClient.CloseAsync()' hides inherited member 'ClientBase.CloseAsync()'. Use the new keyword if hiding was intended.

This is in a project that targets netstandard2.0 and net8.0.

Additional context This issue was previously marked fixed in 2.1.0 see #4891

imcarolwang commented 4 months ago

By default, the tool conditionally generates CloseAsync() based on the project's target framework version and the corresponding predefined WCF package versions added to the project. If the referenced WCF package version is updated either before or after the code generation, CloseAsync() may not compile as intended like the error in issue.

Specifically, if the project references a WCF package version equal to or greater than 4.10, CloseAsync() will not be generated. Otherwise, the tool will generate CloseAsync(), and the project should compile without issues.

If this situation does not match your experience, it could indicate other issues related to handling of the project's multi-framework-targets.

Could you please share the .csproj configuration, including the version of the WCF package referenced by the project when you encountered the problem?

Thank you.

acohenOT commented 3 weeks ago

csproj before adding WCF reference

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFrameworks>netstandard2.0;net8.0</TargetFrameworks>
    <PlatformTarget>x64</PlatformTarget>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Newtonsoft.Json" />
  </ItemGroup>

</Project>

After adding WCF reference

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFrameworks>netstandard2.0;net8.0</TargetFrameworks>
    <PlatformTarget>x64</PlatformTarget>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Newtonsoft.Json" />
    <PackageReference Include="System.ServiceModel.Duplex" />
    <PackageReference Include="System.ServiceModel.Http" />
    <PackageReference Include="System.ServiceModel.NetTcp" />
    <PackageReference Include="System.ServiceModel.Security" />
  </ItemGroup>

</Project>

Since I'm using Directory.Packages.props, it adds these automatically

    <PackageVersion Include="System.ServiceModel.Duplex" Version="4.4.*" />
    <PackageVersion Include="System.ServiceModel.Http" Version="4.4.*" />
    <PackageVersion Include="System.ServiceModel.NetTcp" Version="4.4.*" />
    <PackageVersion Include="System.ServiceModel.Security" Version="4.4.*" />

Compilation fails with * in Directory.Packages.props, so I change it to 4.4.4 and now it works with no warning.

Now, I want to use version 4.10.3, so I manually update my Directory.Packages.props to this version. Then, I get warning CS0108. Even if I delete and regenerate the WCF reference, it reverts the packages in Directory.Packages.props back to 4.4.*.

It seems there is no way to generate the correct proxy code when multi-targeting and using Directory.Packages.props.

imcarolwang commented 3 weeks ago

Thanks, @acohenOT, for the information. The CS0108 warning likely stems from the premature generation of the CloseAsync() method, which PR #5652 aims to resolve. As a workaround, you might consider wrapping theCloseAsync(...)method with#if !NET6_0_OR_GREATERand #endif.

Regarding the outdated WCF package version referenced in your multi-targeting project (netstandard2.0 and net8.0), another PR is addressing this issue. As a workaround, you can manually update Directory.Packages.props to the desired version, 4.10.3, as you did after code generation.