I have my own custom profile for Organise Members, but I'm struggling with one aspect of it. One style rule we have is that if a class has any other classes defined within it, then these should be declared above the parent class's methods. To facilitate this I've got two entries at the end of my profile, below the items I want explicitly placed above them (eg, fields, event declarations, etc). The first is a group by with "Kind" set to "Class". There is no sort on it, so that the class order remains as it was manually configured. Below that I have another group by, this time with "Kind" set to "Member". The intention was that the last two groups in my source file would be any child classes, followed by any members , however the child classes get moved to the bottom. Sort of
I have a test class I'm playing with as I write this, and I think I've just narrowed down the behaviour. My child classes are always in a region block. If I have a single class in a region above my methods, it remains there. If I add a second class to the region then the region containing the two classes is moved to the bottom of the source file. If I put each class in its own region then they both remain at the top of the file. This only seems to be an issue in a VB project, in C# it works fine
Here's a simple class that exhibits the problem:[VB.NET]
Public Class Atest #Region "test" Class one Property Test As String End Class Class two Property Test As String End Class #End Region Public Sub New() End Sub End Class
Running organise members on this should leave it untouched, but instead it moves the region below the constructor. Remove the region declarations and it behaves correctly. Remove one of the child classes and it behaves correctly.
I've attached my settings that include the rules
Show all comments