Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
Mono organizations on
GitHub to continue tracking issues. Bugzilla will remain
available for reference in read-only mode. We will continue to work
on open Bugzilla bugs, copy them to the new locations
as needed for follow-up, and add the new items under Related
Our sincere thanks to everyone who has contributed on this bug
tracker over the years. Thanks also for your understanding as we
make these adjustments and improvements for the future.
Please create a new report on
Developer Community or GitHub with
your current version information, steps to reproduce, and relevant error
messages or log files if you are hitting an issue that looks similar to
this resolved bug and you do not yet see a matching new report.
Xamarin Studio 6.0.2 with mono 4.4.2 was used. This problem does not occur on Windows.
1) With a class as follows:
public class MyClass
public void Foo ()
int a = 0;
a += 1;
throw new ApplicationException ();
2) Build the code.
3) See warning about unreachable code in Errors window.
4) Right click the Console line where the orange line occurs and select Fix - Options for unreachable code - Suppress with #pragma
5) Build the project.
The build warnings about unreachable code are gone.
The build warnings still occur. If you change the #pragma lines from:
#pragma warning disable CS0162 // Unreachable code detected
#pragma warning restore CS0162 // Unreachable code detected
#pragma warning disable 0162 // Unreachable code detected
#pragma warning restore 0162 // Unreachable code detected
Then the warnings disappear after building the project.
Whilst this is a C# compiler problem on Mono, reported in bug #43471, just wondering if the code generation for the #pragma can be changed to remove the optional CS part from the codes. This would prevent the build warnings from being displayed. Although I suspect that Roslyn is generating these pragmas so it might not be possible.
Yes we're relying on roslyn infrastructure there - however we could change that (reuse source) but we would need to maintain that.
Another thing is that RE0162 != CS0162 so the prefix is not really redundant and makes sense now.