Sometimes the reports involve something simple that we can just fix, and other times the reports require a lot of effort to understand a workflow that substantially deviates from our "comfort zone". I love reading about other workflows and the successes and challenges users have in them.
Yet the explanation was simple: the time it took the creators to make the game was time taken away from them practicing playing it.Įvery day I work with several tools and workflows to solve problems, yet I know that I'm only exercising a minute, almost insignificant, fraction of the use cases these tools are built to handle. Back when I worked in the game industry, it always amazed me how much better the players were at the games than the creators of the game who "know everything about it". This is a fascinating and common problem which is definitely not unique to this team or even to this company. Seriously, the people that make these decisions do not develop for UWP. I'm only pointing it out because it is a possible solution which happens to be immediately available. ? Note that I'm not trying to say this is the long-term solution you want.
#Resharper 9 blocking method stubs code
Since StyleCop Analyzers is a set of Roslyn analyzers, it will not report warnings in generated code and supports global suppressions.CS1591 applies only to exposed elements, but StyleCop Analyzers has several additional places where documentation can be marked as required. The documentation requirements are more configurable.
There are two big differences you would see from switching from relying on CS1591 to relying on a separate analyzer: StyleCop Analyzers has several rules related to documentation, several of which closely resemble behavior normally seen from CS1591. One interesting possibility does involve turning off this warning. I couldn't find an issue for this, so if it's something you'd like to see changed I would encourage you to file a separate issue specifically for it (at minimum you'd have an answer about why it currently behaves that way).Īnd obviously we don't want to turn the warning off for a whole project It bit me too while investigating this issue. The global suppressions file can be used to suppress warnings reported by analyzers, but not ones reported by the compiler. To my knowledge, you can't suppress CS1591 in the global suppressions file And obviously we don't want to turn the warning off for a whole project - Just because MS isn't documenting their code anymore, doesn't mean we don't want to document ours! :( To my knowledge, you can't suppress CS1591 in the global suppressions file - the VS 2015 tooling definitely won't give you the option anyway it will only suppress with a #pragma directive for CS warnings. It's seriously an annoying proposition. At the worst case, it's just another way to mark code as generated, and just another thing that the tools will have to check for. as soon as the other MS teams start adding the #pragma). :(Īdding a new pragma and telling us to use that, in the BEST case, means, that if you implement it today, our pain will go away in about 5 years (or later i.e. It does us no good to tell us to add a #pragma warning disable 1591 or any other #pragma directive for that matter, since we're obviously powerless to edit the generated code. I highly recommend supporting the GeneratedCodeAttribute, and, because it's what most libraries and code generation tools use today. If we end up adding a lengthy discussion to this issue it will get too long/intertwined for future users to find helpful. ? If the problem appears as part of a specific project, the best way to call my attention to it is with a mention ( in an issue in that repository. NuGet package content, generated code during build, etc.)? If you know the name/version of the NuGet package and/or the build tool responsible for generating the file, that helps too.
What is the source of the file where the warning appears (e.g.What specific warnings are you seeing that you would like to avoid?.What kind of project are you working in?.
#Resharper 9 blocking method stubs free
While I don't have a "one size fits all" answer, if you get stuck on a particular case please feel free to call my attention to it and I can help you work through it so it's no longer a problem. I've dealt with a great deal of different situations related to this as part of my work on StyleCop Analyzers.