Suppress Xml warning for ServiceReference .cs file

Question

Working with MVC4 and VS2012, I am using a Service Reference, which auto generates a Reference.cs file. When I build, I get dozens of warnings as errors that read

'Missing XML comment for publicly visible type or member...'

I have found a similar answer here, which references a workaround found in this blog, which suggests adding the following fix into the CSProj file:

<Target Name="XamlGeneratedCodeWarningRemoved" AfterTargets="XamlMarkupCompilePass1">
    <Exec Command="for %%f in (@(XamlGeneratedCodeFiles)) do echo #pragma warning disable > %%f.temp" />
    <Exec Command="for %%f in (@(XamlGeneratedCodeFiles)) do type %%f >> %%f.temp" />
    <Exec Command="for %%f in (@(XamlGeneratedCodeFiles)) do copy /y %%f.temp %%f" />
    <Message Text="XamlGeneratedCodeWarningRemoved: @(XamlGeneratedCodeFiles)" />
  </Target>

But this doesn't seem to work with the Reference.cs file, probably because it is targeting Xaml? Could anyone tell me how I can fix this to work with Reference.cs file or suggest another way to get around this problem?

I can't just add a pragma disable into the auto generated code or disable Xml comments.

Ritualism

Answer 1

Updating the pre-generated .cs files on the fly will cause all sorts of issues with Visual Studio, since it will use the in-memory copy of the files. And it will be very irritating due to the Source Control integration making the files read-only and requiring the files to be checked in after every build.

You can also make your Service Client internal by tweaking it's properties. Depending on your settings, the documentation generation will not complain about any method that isn't externally visible. This might still trigger StyleCop, Code Analysis or Resharper warnings though...

So what I usually do is, I stick the Service References in their own Visual Studio project, make the generated code Public and turn off documentation generation for the whole project. This also has the advantage that your service reference will use the same bindings regardless of the project you include it in.

Moses

nice idea Jesse, will give this a try. But surely there's a better way of solving this than moving the service reference to its own project? I don't know much about CSProj files or MSBuild but after reading through your linked page I wonder if the prebuild could be targeted using a similar example as in my question? – Ritualism

Yes, it could, but with the source control integration going nuts as a result. Every build would result in a number of pending changes. You could make your code intelligent so that it won't re-update the files though, that should work. I prefer this though, much easier to configure and easier to understand for all project members involved. – Moses

Thanks for your answer. I may have to ask another question, but just wonder how you would get around StyleCop warnings with the same generatd code? As I have that to look forward to when I solve this problem! – Ritualism

nevermind, I've just realised your approach would solve the Stylecop issue also (duh). Will test and mark as accepted if this works – Ritualism

It solves the issues with most of the tools that check syntax, coding practices, documentation etc. It's exactly why I like it. To properly remove these issues, you need to manually create custom classes and put the right [DataContract] attributes on them, basically building the whole service client by hand. Too much work in my opinion. – Moses

In my case, I found it easiest to just turn off that specific warning for the whole project: Project properties -> Build > "Errors and warnings" (section), Suppress Warnings (textbox), add 1591 (comma separated list) – Egan

Answer 2

I also found that I can set the Service Reference as Internal on creation, which gets around the Xml summary problem.

Although this still leaves me with the problem of suppressing StyleCop errors for the generated code, but I will create a new question for this.

Ritualism

Footnote: This might not work, because the events generated are marked as public even if the service reference is internal. – Vignette