I have a C# project in VS 2010 that has WCF service references and we are getting a lot of warnings for XML documentation. I could add #pragma disable warning 1591 for the reference.cs files but would like a generic solution
I have come across http://lvquoc.blogspot.com/2010/11/disable-xml-comment-warning-in-workflow.html, where Quoc explained neatly how to do it WF generated code so was wondering if we could do something similar in this case, but couldn't get the build targets for WCF.
I recently ran into this as well. When you generate your service reference make sure it is marked as internal instead of public.
The validation will no longer apply.
You can surpress them in the build tab of your project's properties by entering 1591 in "Suppress Warnings".
Related
I have some generated code that has a bunch of compiler warnings. I want to disable them in the generated file, but keep those warnings in the rest of the project so they can be fixed. I'm using Visual Studio 2019 Community Edition, with the generated files coming from Entity Framework and other NuGet packages.
I want to do this without changing the files, so I won't get the warnings back if they get regenerated. I also don't want to disable the warnings project wide, since they are normally useful warnings. I also don't want to edit the NuGet packages, since that would either require not upgrading them as newer releases are available or possibly having to make changes to the new version.
I've already done plenty of reading, but evidently posting the links is "too much", so I've removed them. Look in the edit history if you want to see them.
The file in question is a Reference.cs for a Connected Service. It has the namespace of Proxy.ProvisioningService and this one file contains a couple of dozen classes. I also have a couple of Entity Framework migration files that have the same problem in a completely different solution.
I have a GlobalSuppressions.cs file that I'd like to add the CS1591 (specifically) to, but my current entry isn't working. Other entries work for other warnings and I've tried variations of the below code to work, including trying to match the format of the other entries, but nothing is working so far. I've changed the "Build" from "Compile", removed the MessageId, changed Scope to be "module", "assembly", and "namespaceanddescendants", and I've tried a couple different ways to set the Target.
[assembly: SuppressMessage("Build", "CS1591:Missing XML comment for publicly visible type or member", Justification = "Generated code", MessageId = "CS1591", Scope = "namespaceanddescendants", Target = "Proxy.ProvisioningService")]
In one of the off-site links, it suggests that I right-click the error, go to Suppress -> In Suppression File, but that's not a listed option. Is that a clue that I can't do it in the GlobalSuppressions.cs file?
I've tried to have Visual Studio 2019 Community Edition automatically suppress the warning by the menu item Analyze -> Build And Suppress Active Issues -> For Project, but that just added a bunch of #pragma directives to the file, which would have to be replaced if the file was regenerated, which I want to avoid.
One of the linked answers suggested writing a script to add the #pragma directives on compile, but that script seems like a hack to me. I'd rather just not edit the generated code at all.
I also don't want to put it in the Project -> Properties -> Build -> Suppress Warnings section, since I want the hand written code to still throw these warnings.
Another SE/SO answer suggests using the GeneratedCodeAttribute attribute to prevent warning from generated files. Unfortunately, my file already has this and it's still throwing the warnings.
Another suggestion was to turn off warnings for these generated files:
To suppress warnings for generated code in a project
Right-click the project in Solution Explorer and then click Properties.
Choose the Code Analysis tab.
Select the Suppress results from generated code check box.
Unfortunately, this option is already selected and not suppressing the CS1591 warning.
So my actual question is:
How can I suppress warnings, specifically CS1591, from generated code files without editing them and without suppressing the warning throughout the whole project?
You said that you consider using a script to update the files to add #pragma a hack, but I can't think of another solution.
I think that you can do this easily with a MSBuild Task by adding something like this to your .csproj file:
<Target Name="DisableWarnings" BeforeTargets="CoreCompile">
<ItemGroup>
<AutoGeneratedFiles Include="**/*.Designer.cs" />
</ItemGroup>
<WriteLinesToFile File="%(AutoGeneratedFiles.FullPath)"
Condition="!$([System.IO.File]::ReadAllText(%(AutoGeneratedFiles.FullPath)).StartsWith("#pragma warning"))"
Lines="$([System.String]::Concat("#pragma warning disable 1591",$([System.IO.File]::ReadAllText(%(AutoGeneratedFiles.FullPath))),"#pragma warning restore 1591"))"
Overwrite="true"
Encoding="Unicode" />
</Target>
The SuppressMessage attribute works only for code analysis warnings. Its summary goes:
Suppresses reporting of a specific code analysis rule violation, allowing multiple suppressions on a single code artifact. Does not apply to compiler diagnostics.
If there is a file name pattern identifying the generated code, compiler warnings can be suppressed in the generated code using EditorConfig. For example, this is how I disabled the warnings for using obsolete code elements in my generated code -- I still need to suppress the warnings in manually written code using #pragma.
[*.generated.cs]
dotnet_diagnostic.CS0612.severity = none
dotnet_diagnostic.CS0618.severity = none
For a WCF connected service, the simplest solution is probably to not have the warning in the first place.
Since the CS1591 warning is about public types, you could use the dotnet-svcutil tool to generate your Reference.cs file and pass the --internal option so that the generated types are internal instead of public, thus getting rid of CS1591 altogether.
For other tools that generate code, look for a similar option to generate internal types instead of public types. For example, you would use the --assemblyVisible option with the xscgen tool.
The following warning appears in my UWP project. I have already marked examples of solutions but I am more interested in why this warning does not occur when creating another empty project on the same platform?
APPX4001: Build property AppxBundlePlatforms is not explicitly set and is
calculated based on currently building architecture. Use 'Create App
Package' wizard or edit project file to set it.
Simple workaround for APPX4001 warning see this issue.
But I am more interested in why this warning does not occur when
creating another empty project on the same platform?
I searched the related info about this warning and found this similar issue. See ...\AppxPackage\Microsoft.AppXPackage.Targets(2459,5): warning ..., so it seems that this warning is thrown by the Microsoft.AppXPackage.Targets file. Not sure why the warning sometimes doesn't show where it come from, but I think the targets file is the cause of APPX4001.
I found that file in C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\Microsoft\VisualStudio\v15.0\AppxPackage. (for vs2017 enterprise) Let's check its content which throw the warning:
So it's obvious that if the value in Condition is true, it will throw warning APPX4001. It seems that this issue have something to do with the AppxBundle. So I create a new uwp project and build it, all is ok. And then I add this line into its xx.csproj file:
<AppxBundle>Always</AppxBundle>
Then the same warning occurs:
So this warning will occur if you try to build with Appxbundle or set the AppxBundle property in project file while you didn't set the AppxBundlePlatforms property.
This is the reason why new simple project won't display this warning. And simple workaround for this warning is to set the AppxBundlePlatforms property, see the first line in my answer.
Hope all above can help resolve the puzzle why the warning comes and resolve the warning.
Let me know if I misunderstand anything :)
Perhaps this link can help.
As described in the article, I tried to package my App (just used Sideload package without signature).
The packaging process then added the
<AppxBundlePlatforms>x86|x64|arm</AppxBundlePlatforms>
entry in the .csproj file and the warning has disapeard
On Unity, where the C++ project is being generated on-the-fly (editing is pointless),
one can pass /p:AppxBundlePlatforms=x86|x64|arm as an argument to MSBuild.exe.
Using Resharper, we can right click on References for a project and select Optimize References. This shows us class libraries that are not in use or required by the compiler.
I have a class library that is only to be used as a reference (won't ever be a need to actually use the code). The dll is setup to inject itself upon start up as long as it is part of the references. In case you are curious why this would ever be done, it handles not found and errors for ASP.NET MVC projects (Nuget package page).
Is there any possible way that I can tell Resharper that this reference is either part of the required by the compiler or a part of the used references? I just want to try and prevent developers from removing my dll on accident.
You can interface Resharper with StyleCop. It allow warning in your code based on StyleCop settings.
For each warning there is a way (using the "Resharper bubble") to disable a warning :
http://tof.canardpc.com/view/49d10973-eb25-4a26-90b2-19d872083285.jpg
it's add a comment line in your code to disable alert on the warning ;
// ReSharper disable once RedundantUsingDirective
using My.Unused.Reference;
After some tests, saldy it seems Resharper doesn't care about that when you trigger the "Optimize Reference"
I am including an instance of the same source files in multiple assemblies using the Add As Link option. I specifically need to include an instance of the same source within these assemblies because it is responsible for licence validation which must occur internally to the assembly. Performing licence calls across module boundaries could introduce a security risk.
Some of the projects in my solution that include the code depend on other modules that also include it, resulting in warning CS0436:
"The type [type] in [licence.cs full path] conflicts with the imported
type [LicenceClass] in [dependency project also including licence.cs].
Using the type defined in [licence.cs full path]".
I have tried declaring a class alias, but the definitions internal to licence.cs cause the same warning. In the alias, there must be a reference to the duplicated class name which causes the same warning.
I know it is bad practice to duplicate source between assemblies, but it is intentional in this case. I would rather keep a central instance that each assembly links to rather than a dedicated instance with renamed classes to avoid the warnings.
The workaround I have is simply to ignore the warning using a #pragma. Is there a more elegant solution?
It is worth noting that another way to get such warnings is by simply setting a project in visual studio to reference itself: References -> Solution -> etc etc (how I figured this gem out is left as an exercise to the reader ...)
Visual Studio will happily comply, only to throw a wall of warnings of the type described by OP during build, which is to be expected (upon reflection) since every single class etc is getting defined twice.
The only time conflicts occur is when two dependent classes include the same class. There are two workarounds:
Disable the warning in classes that cause CS0436:
#pragma warning disable 0436
Have a separate instance of the class, uniquely named in each client project (undesirable from a maintenance point of view).
EDIT: There is also a solution: do what Mark suggests below, and mark duplicate classes internal.
I had a web application I converted from ASP.NET 3.5 to 4.5 when I moved to VS2015. I started seeing this as a warning, but the solution would still compile. There were no circular references, and cleaning the solution and deleting the bin and obj folders didn't help.
It turns out that VS2015 wasn't happy with some of my classes in the App_Code folder. The classes in here had the same namespace as the rest of the web pages in the parent folder. Once I moved these classes out of the App_Code folder and to the top level of the web application, the warnings went away.
In .NET Core you can also disable the warning in project.json:
{
"buildOptions":
{
"nowarn":
[
"CS0436"
]
}
}
I had this error but not with 2 different classes!
Each new class where in conflict with itself, so obviously I had that CS0436 Error.
After some struggling found out that it was about Mirror Asset that I was using in my multiplayer Unity project. Mirror somehow was including every new class that I make (and inherit from NetworkBehavior).
My external editor was VSCode (visual studio code, solution might also apply to visual studio).
Solution
in
Edit / Preferences / External tools / "Generate .csproj files for:"
I started testing different settings, and this worked for me:
(Not sure if the exact settings work for all, but not having the right files in project, leads to this error. like my case.)
Click Regenerate project files and restart Unity and VSCode after applying these settings (or the setting that suits your project).
I've met such a case when removed some source files temporarily and restored them back later. It happens that IDE (Rider in my case) tries to restore the classes so when they were missing it just added the reference to the resulting exe. Evidently, when I restored the files, they look as duplicate.
The reference IDE inserted looks like this and it's enough to just remove it to fix:
<Reference Include="AppName, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null">
<HintPath>bin\x86\Debug\AppName.exe</HintPath>
</Reference>
We have started a new project but also have this problem for an existing project. The problem is that when we compile with a warning level of 4 we also want to switch on
'Treat all warnings as errors'
We are unable to do this at the moment because generated files (in particular reference.cs files) are missing things like XML comments and this generates a warning, we do not want to suppress the xml comment warnings totally out of all files just for specific types of files (namely generated code).
I have thought of a way this could be achieved but am not sure if these are the best way to do this or indeed where to start :) My thinking is that we need to do something with T4 templates for the code that is generated such that it does fill in XML documentation for generated code.
Does anyone have any ideas, currently I'm at well over 2k warnings (its a big project) :(
You can selectively disable warnings with a pragma:
// Disable warning messages 4507 and 4034.
#pragma warning( disable : 4507 34 )
If you can emit such warnings (or an #include) in the generated code files, you're done.
Alternatively, you can disable them globally on the command-line for the compiler:
/wd4326 disables compiler warning C4326.
Then re-enable them (via a header file) in the files you want them for:
// Report warning 4326 as an error.
#pragma warning( error : 326 )
Finally, you can set different compile options for each source file by altering the Properties in the project file. Personally I find that a maintenance nightmare, but there are times you have no choice.
Edit: I see that your source files are C#, not C++.
Using the C# command-line:
to suppress CS0028, you could specify /nowarn:28.
Unfortunately, /warnaserror makes all warnings errors.
I've written a PowerShell script that calls svcutil and then wraps the auto-generated code with the #pragma directives to ignore the missing xml, but still allows me to regenerate as needed.
$outFile = 'generatedCode_fromSVCUTIL.cs'
svcutil '..\XML Schema\myXsd.xsd' /dataContractOnly /n:'*,MyNamespace.GeneratedCode' /language:C# /importxmltypes /out:$outFile
# -----------------------------------------------------
# Exempt this file from XML documentation requirements
Write-Host 'Wrapping ', $outFile, ' in #pragma 1591 flags'
$a = Get-Content $outFile
# Set up pragma lines for enabling and disabling the XML doc warning
$disableWarning = '#pragma warning disable 1591'
$restoreWarning = '#pragma warning restore 1591'
# wrap the generated code in the pragma tags
Set-Content $outFile –value $disableWarning, $a, $restoreWarning
Write-Host 'Done.'
In VS 2010 you can right-click on the service reference, select 'Configure Service Reference...' and change the access modifier from Public to Internal.
This may of course not be appropriate for your particular solution but the warnings are not applicable to Internal methods and you can still re-generate the service reference.
For C# you can simply place a
#pragma warning disable 1591
at the beginning of the reference.cs file. Then the warning concerning missing XML documentation will not be issued.
But you have to do this every time, the file is regenerated (i.e. when your service definition changes). I'm not aware of any way to influence the code generation (I'm not sure if they use T4 templates or where these might be located ...)
A couple of thoughts.
1) Do you have the autogenerated tag in your file header (comments at the top of the file), like this:
// <auto-generated>
// This file is auto-generated...
// </auto-generated>
This tag is important (the contents are not), as some tools will skip such files (e.g. StyleCop can be configured to ignore these files).
2) If you are autogenerating code why not autogenerate at least some XML comments? I can understand that you don't want to spend a lot of time documenting code that probably won't ever be read, but when debugging code I often find myself dropping in to some autogenerated proxy and even a simple comment can be helpful, even if it just says "autogenerated code" :)
Edit
3) You can also suppress warnings by adding the pragmas to the build options (right click on the project, choose properties, choose the Build tab). This is more convenient than adding to code. Try adding 1591;1574;1587 to the Suppress Warnings box.
4) You could go in to the Code Analysis tab in the Project Properties and uncheck "Treat Warning as Error" for specific warnings that are causing you problems.
Obviously both these are global settings, they don't just pick on the autogenerated files.