Looking awesome... I can see it being used when searching for areas to add test coverage to, or teaching new programmers unit tests.
Silly question: why didn't you implement this as a custom set of FxCop rules?
Peli: Because I want it to be a simple tool to run, inspect and extend. and FxCop is none of those things.
Where did ClrTest.Reflection came from?
Nice.
One thing that it needs is a set of default excludes.
Right now it is reporting errors on static calls to string.Concat and GC.SuppressFinalizers, for insta.ce
Roy,
I also wonder why you did not base it on FxCop.
Why I can buy "not easy to extend" statement regarding FxCop, how's FxCop complicated to run and inspect?
And even with "not easy to extend", there is ready build integration etc. with FxCop.
J
I have played around with FxCop but I found it hard to use and write against. event test (google fxcopunit)
worst thing: most people don't bother using it at all.
Do you use it?
Does anyone who's reading this comment?
How is this tool different from NDepend?
The tool complains when your assembly depends on another assembly unless I put the assemblies that my assembly depends on (such as log4net) in the depender folder. I guess I could put them in Path as well. Any other way that I am missing?
Tanmay: for now putting them in the path or in the same folder is the workaround.
Three words - reinventing the wheel...
David M. Kean:
Three words: YOu are wrong.
FxCop and others only do rules that are "bad"
Depender will also show you "good" places to inject. it's not just "warnings" but also shows places that you can use already.
I'd love to see something that does the same though!
Roy,
Please ignore the negative comments.
The tool looks excellent and I'm looking forward to playing with it.