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.
When compiling MD's Main.sln using MD generates all Stetic *.cs files in gtk-gui incorrectly.
Class fields (private) are further being marked readonly which is incorrect (private should be enough) and is causing compile errors.
Once generated incorrectly, user has now corrupted code and cannot recompile to fix.
I can't reproduce. Which Mono version are you using?
Lluis, this occurs in Linux with the latest branch. Steps to reproduce:
1. Get latest branch or everything
2. Compile libgdisharp, llvm, mono, monodevelop (with debugger and web)
3. launch monodevelop
4. Open Main.sln using monodevelop you compiled (but fails just the same in MD2.4 & MD2.6)
During compilation the gtk partial source files are generated. Some (most) are generated with private readonly properties. These properties are set in a private method that is called by the forms constructor.
There are several issues:
1. The compiler is throwing a compilation error but fails to see that the readonly fields are in fact being set by the constructor (via the method that sets them which is only called only from the constructor).
2. The use of private readonly is redundant for a field that is set by code other than the field declaration.
I fixed this temporarily by calling string.Replace(" readonly ", " ");
on the text generated by the gtk service before it is formatted with the IDE/users C# format options. The actual code that generates the C# from the stetic gtk designer file is DI'ed somehow, and I have not discovered it yet.
2 other observations:
There is ZERO documentation in the code (for the most part) and ZERO documentation for the classes (what is this class responsible for?) and ZERO documentation for the Assemblies (why does this assembly exist?). By comparison with Java FOSS projects, I am very disappointed.
This was a regression in Mono, which was inserting the readonly keyword when it shouldn't. It's now fixed in Mono master.
I'm sorry you are very disappointed with my work. I'll do my best to do it better next time.
Lluis, by no means am I disappointed with your work, or the work of any other contributor the project. My disappointment is a general statement regarding the state of the project documentation on the whole. I think this is historic and can be easily rectified over time if we raise the standards and encourage adherence.
The following will greatly assist people in contributing to the project by lowering the learning barrier-to-entry.
For each assembly there should be a document that describes that assemblies reason for being.
For each class there should be a clear responsibility statement.
For each method, no matter how well named, the methods responsibility should be stated.
For each IOC/DI abstraction / factory / interface there should be a comment on where the configuration / strategy pattern comes from, or there should be some centralized documentation for this. An example of this is the extensive use of plugins, which also are used to generate the GTK code. Without compiling and executing the code it is quite hard to follow what code is actually generating the source code that contained that readonly.
My point is this - we should take a leaf from the Java FOSS folks and greatly increase our in-code documentation, because doing so makes it easier to receive contributions. I could easily have issued you a fix/patch for this issue instead of opening a bug report, but it took me for-ever to track the bug to the code generation point. I had spent too much time on it so the time left only allowed me to inject a work-around into the code instead of producing a proper fix.
Both the paid and contributing developers should be rightly proud of their work here. I just ask that we lower the barrier to entry for further contributions, especially important as the code base matures.