The biggest issue is exclusions. In a complex application, I guarentee that you'll have some FxCop violations that are false positives. Even Microsoft reminded us recently that FxCop is not omniscient and developers shouldn't be blindly fixing everything that FxCop complains about.
When you use the GUI and do some exclusions (right click on a violation), the fact that you have excluded this violation is stored in the project file so that next time you run FxCop, you don't get harrassed about it. The other issue is just disabled rules. It's pretty common to want to use a rules assembly, but turn off a couple specific rules from that assembly. These are also stored in the project file. -----Original Message----- From: Arjen Poutsma [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 12, 2003 3:37 AM To: Gert Driesen; [EMAIL PROTECTED] Subject: RE: [nant-dev] FxCop & RegSvcs Tasks Goedemorgen Gert ;-), I agree on the target attribute: it will be dropped. I'm not quite sure I understand what you mean regarding the FxCop task, though. Would you like the to use a template FxCop project, and modify it with the contents of the targets and rules filesets? I don't think that's a good solution, because it forces you to create a FxCop project, and I don't want to do that. However, I justed looked at the xml format of a .fxcop file, and it doesn't look that hard to build. In fact, it's so simple that I don't see the advantage of using a template file at all. Creating a (temporary) .fxcop project file does give the advantage of not having to specify the rules, though, since you use the default RuleFiles node, which contains GlobalizationRules.dll, ComRules.dll, UsageRules.dll, DesignRules.dll, PerformanceRules.dll, SecurityRules.dll and NamingRules.dll. The disadvantage of this approach is that you'r much more dependant on the file format. If the folks in Redmond suddenly decide to change the format, we're screwed. We could also add some attributes, which allow you to disable these seven default rules. Using it will then look something like this: <fxcop> <targets basedir="bin"> <includes name="**/*.dll" /> </targets> </fxcop> Which will use all seven default rules. <fxcop globalization="false" com="false"> <targets basedir="bin"> <includes name="**/*.dll" /> </targets> </fxcop> Which disables the GlobalizationRules.dll and ComRules.dll. You get the idea. <fxcop> <targets basedir="bin"> <includes name="**/*.dll" /> </targets> <rules basedir="c:\MyRulesDir"> <includes name="**/*.dll" /> </rules> </fxcop> Which uses the rules found in c:\myrulesdir in addition to the seven defaults. <fxcop usedefaultrules="false"> <targets basedir="bin"> <includes name="**/*.dll" /> </targets> <rules basedir="c:\MyRulesDir"> <includes name="**/*.dll" /> </rules> </fxcop> Which uses the rules found in c:\myrulesdir in addition to the seven defaults. I could also add the feature of providing just a .fxcop project file, like so: <fxcop project="myProject.fxcop"/> But I don't think we can combine this with any of the attributes described above. Do these changes make it more useful? Best, Arjen > -----Original Message----- > From: Gert Driesen [mailto:[EMAIL PROTECTED] > Sent: Monday, August 11, 2003 9:42 PM > To: Arjen Poutsma; [EMAIL PROTECTED] > Subject: Re: [nant-dev] FxCop & RegSvcs Tasks > > > Hi Arjen, > > Good to see someone finally took the time to implement these > tasks, great work > > However, I'm not sure the FxCop task is very useful as you've > implemented it, but I could be wrong ofcourse ... I think we > could actually start from an existing FxCop project file as > it doesn't make sense to apply all rules to an assembly, and > consider it a failure when it doesn't pass all those rules. > I had thought about implementing the FxCop task as a task > that supports a fileset for the targets (like you did) and a > fileset for (custom) rule files, and have it just generate > the Targets and RuleFiles nodes in a copy of the specified > FxCop project file. That way you have the power of the fxcop > project without having any "hard coded" paths in the FxCop > project. We could also support the types option, but I don't > think its really necessary if we require a FxCop project file > anyway. If we support the types option then we could support > it using a nested types build element. I think we can also > remove the target attribute and only support the fileset. > > For the regsvcs task I would prefer to always explicitly > specify the action, even for the "install"/"create" action. > > Ofcourse these are all just personal suggestions/remarks, and > by no means I want to sound ungrateful for the work you've done. > > Keep up the good work ! > > Gert ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01 /01 _______________________________________________ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 _______________________________________________ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
