Gendarme - status report 9

0 views
Skip to first unread message

lukasz.knop

unread,
Aug 17, 2007, 6:03:26 PM8/17/07
to mono-soc-2007
I have managed to bring the gui runner to a usable state:
- the rules can be selected dynamically
- all violations are displayed in a listview

The code is at
http://mono-soc-2007.googlecode.com/svn/trunk/lukasz/gui.runner/

There are a lot of things that need to be improved:
- selection of individual rules (perhaps in a treeview) to include in
the test
- checking multiple assemblies in a single pass
- "project" feature - saving all settings in a single file for later
reuse
- progress bar during rule checks
- refactor code to comply with standards
* perhaps there are other more important features to include?

There is not much time left before the soc program ends therefore I
will have to prioritize this list so I would welcome any comments. I
will continue working on it after that but I would like to have the
runner in a stable state at the end of SoC.

I also had a problem with retrieving additional information from the
rule violation instance:

foreach (Violation v in runner.Violations)
{
RuleInformation ri = RuleInformationManager.GetRuleInformation
(v.Rule);
[....]

When trying to read the properties of ri like ri.Name, ri.Uri,
ri.Problem, ri.Solution I got empty strings. This opens another issue
- how exactly are .xml.in files that define these properties included
in the rules dll file?

Lukasz

Sebastien

unread,
Aug 20, 2007, 8:39:02 AM8/20/07
to mono-soc-2007
On Aug 17, 6:03 pm, "lukasz.knop" <lukasz.k...@gmail.com> wrote:
> I have managed to bring the gui runner to a usable state:
> - the rules can be selected dynamically
> - all violations are displayed in a listview
>
> The code is athttp://mono-soc-2007.googlecode.com/svn/trunk/lukasz/gui.runner/

Nice :)

> There are a lot of things that need to be improved:
> - selection of individual rules (perhaps in a treeview) to include in
> the test
> - checking multiple assemblies in a single pass
> - "project" feature - saving all settings in a single file for later
> reuse
> - progress bar during rule checks
> - refactor code to comply with standards

IMO your list is already well ordered.

> * perhaps there are other more important features to include?

More? yes, more important? maybe not (but just by a bit). We'll soon
need an "ignore" feature so people won't get the same results over an
over again for something they can't (or wont) fix.

> There is not much time left before the soc program ends therefore I
> will have to prioritize this list so I would welcome any comments.

The order is fine with me. Of course you can refactor/fix style when
adding/modifying code.

> I will continue working on it after that but I would like to have the
> runner in a stable state at the end of SoC.

That would be great :)

> I also had a problem with retrieving additional information from the
> rule violation instance:
>
> foreach (Violation v in runner.Violations)
> {
> RuleInformation ri = RuleInformationManager.GetRuleInformation
> (v.Rule);
> [....]
>
> When trying to read the properties of ri like ri.Name, ri.Uri,
> ri.Problem, ri.Solution I got empty strings. This opens another issue
> - how exactly are .xml.in files that define these properties included
> in the rules dll file?

*.xml.in files are processed (in our case it's mostly to replace
string variables) during the ./configure stage and results in a .xml
files. The files needs to be located with the .dll (of the same name)
to work properly. This mechanism may change in future versions of
Gendarme... once we start localizing resources.

Sebastien

Reply all
Reply to author
Forward
0 new messages