Goedemiddag Arjen, On Tue, 2003-08-12 at 10:36, Arjen Poutsma wrote: > Goedemorgen Gert ;-), > > I agree on the target attribute: it will be dropped.
fine > 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. I'm not talking about a template project file, but an actual project file for a specific purpose. I think it's an absolute necessity to be able to exclude certain rules (I'm not talking about rule files here), and I'm sure it's not possible to supply these exlusions on the commandline. You can hardly expect an assembly to validate against all Fxcop rules, but you can identify all rules and all exceptions to these rules and store them in the FxCop project file, and except subsequent build of that assembly (or assemblies) to adhere to these rules. > > 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. Then I guess you haven't looked at the exclusions and rules information that is stored in the project file, which is quite extensive and I don't think it's a good idea to have all this information in the build file. > 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. I agree that we'll be dependent on the fxcop project file format. but we're only specifying the assemblies to analyze and the extra rule files (we shouldn't have to specify the default rule files, but we can ofcourse), so supporting multiple file formats shouldn't be that hard. There's no guarantee that the commandline options won't change too, although I agree that a commandline interface tends to be more stable. IF it's not possible to specify very specific exceptions to the rules, then I really don't think its a usable task. eg. one of the FxCop rules is that an assembly should always be strong named. Do you really want to force users of this task to always create strongly named assemblies ? > > 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. > you're not disabling rules here, but rule files which is something totally different. > I could also add the feature of providing just a .fxcop project file, > like so: > > <fxcop project="myProject.fxcop"/> > that would mean that all assemblies and custom rule files should resides in the same location that's defined in the project file. I would definitely like to avoid this, that why I talked about using fileset for the rules files and assemblies that should be analyzed. > But I don't think we can combine this with any of the attributes > described above. I agree. > > Do these changes make it more useful? I don't think so ... Really I urge you to use your task on some "production" assemblies and I'm pretty sure you won't find one that doesn't violate any of the fxcop rules, as some of these rules are just guidelines that could and in some cases actually should be ignored. Gert > > 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
