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 -- You received this message because you are subscribed to the Google Groups "Gendarme" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/gendarme?hl=en.
