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
- Original Message -
From: Arjen Poutsma [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, August 11, 2003 6:25 PM
Subject: [nant-dev] FxCop RegSvcs Tasks
Hi,
I've created two new tasks. Before I post them to the list, I would like
to know it there's interest.
First, a wrapper Nant task for FxCop, which can be found at
http://www.gotdotnet.com/team/fxcop. This tools checks for compliance
with the .NET Design guidelines. The task basically wraps FxCopCmd.exe.
A suggestions for such a task was made almost a year ago
(http://www.mail-archive.com/[EMAIL PROTECTED]/msg00
683.html), but I don't see it in CVS, so I guess nobody ever took time
to create it.
FxCop is a major pain, btw. It requires that all reference assemblies of
the target assembly are either in the GAC or in the same directory. I
found no way to get around this.
It also requires that you specify the rules (directory) to use. Why the
folks in Redmond couldn't do a simple
AppDomain.CurrentDomain.BaseDirectory and append rules to it (since
that's its default location) is beyond me.
Enough ranting, you can use the task as follows:
fxcop target=bin\debug\SomeAssembly.dll types=MyNameSpace.*
rules=D:\Program Files\Microsoft FxCop 1.21\Rules/
This checks all types in the namespace MyNameSpace, found in found in
SomeAssembly.
fxcop target=bin\debug types=MyNameSpace.* rules=D:\Program
Files\Microsoft FxCop 1.21\Rules/
This checks all all types in the namespace MyNameSpace, found in all
assemblies in bin\debug.
fxcop rules=D:\Program Files\Microsoft FxCop 1.21\Rules
targets basedir=bin
includes name=**/*.dll /
/targets
/fxcop
Look, mommy! It's Fully FileSet-Compliant [TM]!
Two final things about this task: FxCopCmd.exe needs to be in your path,
and the default location of the rules is currently
${nant.location}\FxCop. I would prefer to use the FxCop installation
directory (eg. C:\Program Files\Microsoft FxCop 1.21\Rules), but I do
not know of any (efficient) way to find this path.
Next, the second task:
This one wraps RegSvcs.exe, The .Net tool to load and register an
assembly, or a COM+ application, or to configures services that you have
added programmatically to your class. Pretty basic stuff.
Use it with:
regsvcs assembly=MyServicedComponent.dll/
To install MyServicedComponentas a COM+ app.
regsvcs action=Uninstall assembly=MyServicedComponent.dll /
To uninstall it.
Best,
Arjen
---
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/psa0013ave/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/psa0013ave/direct;at.aspnet_072303_01/01
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
RE: [nant-dev] FxCop RegSvcs Tasks
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
RE: [nant-dev] FxCop RegSvcs Tasks
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
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/psa0013ave/direct;at.aspnet_072303_01/01 ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
RE: [nant-dev] FxCop RegSvcs Tasks
Ok, I think I get it now :-). Basically, you want a fxcop task that can be used as follows: fxcop report=myreport.fxcop/ Which only checks the assemblies defined in the project file against the rules defined in the project file. fxcop report=myreport.fxcop targets basedir=bin includes name=**/*.dll / /targets /fxcop Which checks the assemblies in the targets fileset against the rules defined in the project file. fxcop report=myreport.fxcop targets basedir=bin includes name=**/*.dll / /targets rules basedir=c:\MyRulesDir includes name=**/*.dll / /rules /fxcop Which checks the assemblies in the targets fileset against the rules defined in the project file, in addition to the ones specified in the project file. So the task should work like this: read the .fxcop project file, changes the targets block if a targets fileset was specified, adds custom rules to the rulefiles block if specified, writes this to a temporary file somewhere, and runs fxcopcmd over it. Right? Arjen --- 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/psa0013ave/direct;at.aspnet_072303_01/01 ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
