VisualCop | Gendarme for other artifacts..

40 views
Skip to first unread message

Lars Corneliussen

unread,
Nov 16, 2011, 4:57:24 AM11/16/11
to gend...@googlegroups.com
Hi guys,

on twitter, Sebastian asked me to elaborate more on my ideas around VisualCop.

> lcorneliussen: @spouliot I'm thinking of creating a project "VisualCop" that reports defects over SLN/*proj-files ; or could I integrate it with gendarme?
> spouliot: @lcorneliussen I'd be interested to know more :-) can you email your ideas/code links to the gendarme google group? Thx!

Here we go.

As I'm tidying up the .NET solution for Apache NPanday (Maven + .NET, http://incubator.apache.org/npanday/) i started writing an Macro (just as a start to get to know the DevENV API) called VisualCop that validates the project+solution structure in VS.

Now I'd like to turn the Macro into a real project. But even an Addin is the wrong place, because I'd like to run rules on my build server. So I would have to parse both solution and csproj files - which is partially implemented in Mono already. I also had to create runners and reports. That is, where my Idea came from to rather join Gendarme and improve/share the infrastructure part.

Some rules I have partially implemented:

- Root Namespace should equal Project Name
- Assembly Name should equal Project Name
- Output Path should be "<configurable>"
- Active Configuration should be Debug
- Prefer project references over binary references
- Binary references should be located in "<configurable>" (configurable excludes)

More rules I'd like to implement:

- Reference Hint Paths should be relative
- Project should be located in a folder with the same name
- Solution folders should reflect binary folder structure (not always applicable, though)
- Projects should be signed (optional)
- Projects should export documentation as xml (optional)
- Projects should yield PDB-files (optional)
- ...

Currently Gendarme only handles compiled assemblies.

The question is, if it could be extended to handle sets of files (amongst them Assemblies) such that it can be extended for different rule targets, as, in this case, a set of *.sln and *.csproj/*.vbproj files.

Reporting infrastructure could stay (almost?) the same. Runners, too.

This would also enable project teams to perform rule checking on custom artifacts (for example xml configuration files) and plug it into Gendarme - which would add great value, again.

The API for rules-checking would rely on Xbuild / MSBuild, and the Solution Parser currently available in Xbuild runner. Then it would expose some linqy API (like Cecil) for very easy rule implementation.

I'd also then like to create a Gendarme-Runner for NPanday (Maven Plugin, actually).

Maybe, instead of integrating it into Gendarme Core, Gendarme could expose some kind of Plugin-Infrastructure Defects[] IGendarmePlugin.Run(filePath[]). Rule Implementors would then have to derive from a base class or implement an interface inside the plugin in order to be found.

What do you guys think about this? Good ideas, but wrong place? Or perfect fit? Or none of both? :-)

_
Lars

Leszek Ciesielski

unread,
Nov 17, 2011, 4:00:29 AM11/17/11
to gend...@googlegroups.com

Good idea! I'm kind of used to ReSharper doing some of this
(definitely not all that you are suggesting), but an Open Source tool
is always better.

Regarding parsing msbuild projects: I was doing some work with .proj
parsing recently and found
https://github.com/mono/mono/tree/master/mcs/class/Microsoft.Build
(new 4.0 API) to be easier to work with than 3.5 API that XBuild uses.
There's only parsing implemented so far, not evaluation/execution, but
that should be enough for what you have in mind. Feel free to email me
should you have any questions regarding this or would like a code
sample.

Regards,

Leszek 'skolima' Ciesielski

Lars Corneliussen

unread,
Nov 17, 2011, 7:28:16 AM11/17/11
to gend...@googlegroups.com
Hi Leszek! Or Skolima?

I'd like R# to take care of that, too :? Vote on this issue! :)
http://youtrack.jetbrains.net/issue/RSRP-254521

I found a different route we could go:

We could generate an msbuild file that imports the project, collects information and writes it to an xml (custom build task) - then, based on that we run validations. This xml would at the same time be the model, rule implementors would query against. If they need extra information to gather, they could provide an MSBuild-file that collects more information and adds it to a generic section in our model.

What do you think?

_
Lars

> --
> You received this message because you are subscribed to the Google Groups "Gendarme" group.
> To post to this group, send email to gend...@googlegroups.com.
> To unsubscribe from this group, send email to gendarme+u...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/gendarme?hl=en.
>

Reply all
Reply to author
Forward
0 new messages