Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CS0108 in generated client code #5595

Open
dan-olsen opened this issue Jun 28, 2024 · 3 comments
Open

CS0108 in generated client code #5595

dan-olsen opened this issue Jun 28, 2024 · 3 comments
Assignees
Labels

Comments

@dan-olsen
Copy link

dan-olsen commented Jun 28, 2024

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
Copy link
Contributor

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
Copy link

acohenOT commented Nov 1, 2024

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
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants