It is a subjective issue. On every new project we (myself and some colleagues I know) start, we set warnings to compile errors by default. We end up with a clean code base, easy solution. (Plus, we also enable FxCop, StyleCop issues as errors, very low cost if you do it from the beginning).
Every warning has some impact on quality, maintainability, performance, security etc. There is no easy recommendation of "fix all" or "ignore all". The primary reason that these are warnings and not errors or not reported is primarily because a decision is not easy to make in all situations.
In the code base that has already been developed, it is usually a slow process. This is what I would do:
- I would typically evaluate the impact of a warning.
- If it's a performance warning in a piece of code that is not going to be hit too often, I'll ignore.
- But if I am using a method that is obsolete, it may have a security impact, or eventually, the underlying class library might eventually break me.
- Then I would typically evaluate the cost.
- If it's an "unused variable", I'll fix it. If it's a thousand unused variables, I'll ignore with an understanding that it'll take me a few hours to fix those, and the impact is on code readability and perhaps maintenance.
- Other warnings can be expensive, e.g. using an obsolete method, and changing that usage requires a serious code rewrite.
- Based on the above two metrics (which really feeds into a cost/benefit analysis), I'll fix what makes sense immediately.
- For the rest, the rule would typically be to fix the warnings when someone touches the code base, i.e. when the code is touched, one cannot say "I can leave it in a crappy state because I found it so." :-)
This works in most cases. What works for you will depend on your experience. For every warning, you can do an evaluation, and if you need others' opinions, post on stackoverflow probably to get recommendations. I am sure many issues have already been discussed there.