A diagnostic for Xamarin
In the last post we left of with Roslyn installed, with
Xamarin.iOS.dll copied to our machine and a bare analyzer project created. In this post I will show how to write a first Monotouch analyzer.
A iOS/Monotouch problem to analyse
As Adam points out in his blog, a UIView should not size itself, but only its children views and controls. So the following code should generate a warning:
For an explanation see Adams Blog: "Violation 1".
Create a test case
First we create a test case in our project. The Microsoft template propses to insert the testcode in a string. In my opinion it is much easier to add the code as a normal file, exclude it from compilation and load it as string into the unit test. That would look as following:
Notice the change in the Build action to "Content" and "Copy if newer". It brings the file to the Output dir, so it is loadable rom the Unit test. The real benefit is the working Roslyn code window in the lower area. It shows the syntax tree for the current statement - an
IdentifierName in a
Make this code snippet Roslyn compileable
If we try to run an analyzer on this code fragment, Roslyn would complain, because it can not resolve
UIKit. The assembly is missing. To fix this we have to add a reference to
Xamarin.iOS.dll. This can be done in the
The unit test for this code should now run and default implementation will complain about the lowercase identifiers.
The real analyzer
The task is now to write an analyzer, which finds "
Frame" statements and checks them if they belong directly to the current UIView type.
First we wire up the method
SimpleAssignmentExpression in the
Initialize method. Remember the Roslyn code window? That should be the nearest point for further investigations.
Next we make a syntax check for "
Frame" on the descendant nodes. If we find a "
Frame" we check if there is anything but a "
base" or "
this" statement in the left part of the assignement. If that would be the case, the assignement would be to a "
Frame" of a child view (which is perfectly fine).
Now we start a semantic analysis. With the property symbol from the AST we simple run up the tree to find the enclosing type (class) of the current statement. If this type has "
UIView" as its base class we have a violation of our rule! Why? We now know that its s direct assignement to the property "
Frame" of the current class and thats the class is a "
That's it! We now can detect defaults to our rule. The code to detect syntactical or semantical situations seems pretty easy when you read it. But honestly it can be darn hard to write. The Roslyn syntax windows is a great help and some practice doesn't hurt either. Bit it's great fun!