Nerpa plugin, NRP-2006-01-18

Sorry, package was wrong - it was from previous internal build. If you have
MassFixTest.cs file in source\Netix.Nerpa.Test\ subfolder, please redownload
the package.

http://users.netix.ru/orangy/nerpa/

Sincerely,
Ilya Ryzhenkov

Hi Ilya,


I was trying to modify your plugin to enable the generic checking of
FxCop rules (but stranded with lack of time and documentation of FxCop),
do you think it would it be possible (not asking u to do it, just an
opinion) to adapt your plugin to enable such a feature, and allow people
to add their own resolving classes/methods (automatically add COMVisible
attribute, etc etc), for each FxCop rule?

Combined with Resharper being able to batch-resolve each possible
warning in a complete project, that would make a nice tool don't you think?

Wiebe

Ilya Ryzhenkov wrote:

Sorry, package was wrong - it was from previous internal build. If you
have MassFixTest.cs file in source\Netix.Nerpa.Test\ subfolder, please
redownload the package.

http://users.netix.ru/orangy/nerpa/

Sincerely,
Ilya Ryzhenkov

Hello Wiebe,

I afraid it's not possible to use FxCop rule libraries. First, they operate
on compiled assembly and thus does not have to deal with incomplete code.
Second, they use completely different API which would be hard yet even possible
to adopt for Resharper. Third, they don't contain code for correcting problems,
which is the most important thing in Resharper context. And the last - there
are a lot of false positives which requires mechanism for excluding warnings.

I think we'd better wait until JetBrains setup workplace for plugins and
then reimplement most important rules along with quickfixes. For example,
I don't think that assembly-level attributes checks are important rules.
If they even were implemented, you'd almost never see it - how often do you
open AssemblyInfo.cs file? If you browse FxCop rules, you will see that most
of them are not suitable for Resharper.

On exclusions: I realise, that tool like Nerpa should have some method for
ignoring suggestions. I'm working on it.

Sincerely,
Ilya Ryzhenkov

WT> Hi Ilya,
WT>
WT> I was trying to modify your plugin to enable the generic checking of
WT> FxCop rules (but stranded with lack of time and documentation of
WT> FxCop), do you think it would it be possible (not asking u to do it,
WT> just an opinion) to adapt your plugin to enable such a feature, and
WT> allow people to add their own resolving classes/methods
WT> (automatically add COMVisible attribute, etc etc), for each FxCop
WT> rule?
WT>
WT> Combined with Resharper being able to batch-resolve each possible
WT> warning in a complete project, that would make a nice tool don't you
WT> think?
WT>
WT> Wiebe
WT>
WT> Ilya Ryzhenkov wrote:
WT>
>> Sorry, package was wrong - it was from previous internal build. If
>> you have MassFixTest.cs file in source\Netix.Nerpa.Test\ subfolder,
>> please redownload the package.
>>
>> http://users.netix.ru/orangy/nerpa/
>>
>> Sincerely,
>> Ilya Ryzhenkov

Hi Ilya,

> I afraid it's not possible to use FxCop rule libraries. First, they
> operate on compiled assembly and thus does not have to deal with
> incomplete code.

I've thought of that by saving the FXCop output to a temporary file, and
parsing that in the background. I think it includes source code
information from the PDB file as well.

That would mean the rules would only apply if the code has been compiled
at least once and remained unchanged afterwards.

> And the last - there are a lot of false positives
> which requires mechanism for excluding warnings.

True, but if you use the standard FXCop project files to output the
results, you can use FXCop to ignore/include rules.

But anyway, thanks for your input, there is indeed a need to write a
quickfix for each FXCop rule, but most of them shouldn't be that
difficult with the R# API.

Like you said, I thought it will be the most difficult adapting the
FXCop API to the R# API.

The assembly attribute was only an example (though I do access the
AssemblyInfo.cs a lot, version changes, permissions etc ;), I do think
FXCop has loads of other useful rules, like unused internal
classes/methods, spell-checking methods/variables.

Thanks for your input (and useful tool, great example for R# API as well)

Wiebe

Ilya Ryzhenkov wrote:

Hello Wiebe,

I afraid it's not possible to use FxCop rule libraries. First, they
operate on compiled assembly and thus does not have to deal with
incomplete code. Second, they use completely different API which would
be hard yet even possible to adopt for Resharper. Third, they don't
contain code for correcting problems, which is the most important thing
in Resharper context. And the last - there are a lot of false positives
which requires mechanism for excluding warnings.

I think we'd better wait until JetBrains setup workplace for plugins and
then reimplement most important rules along with quickfixes. For
example, I don't think that assembly-level attributes checks are
important rules. If they even were implemented, you'd almost never see
it - how often do you open AssemblyInfo.cs file? If you browse FxCop
rules, you will see that most of them are not suitable for Resharper.

On exclusions: I realise, that tool like Nerpa should have some method
for ignoring suggestions. I'm working on it.

Sincerely,
Ilya Ryzhenkov

WT> Hi Ilya,
WT> WT> I was trying to modify your plugin to enable the generic
checking of
WT> FxCop rules (but stranded with lack of time and documentation of
WT> FxCop), do you think it would it be possible (not asking u to do it,
WT> just an opinion) to adapt your plugin to enable such a feature, and
WT> allow people to add their own resolving classes/methods
WT> (automatically add COMVisible attribute, etc etc), for each FxCop
WT> rule?
WT> WT> Combined with Resharper being able to batch-resolve each possible
WT> warning in a complete project, that would make a nice tool don't you
WT> think?
WT> WT> Wiebe
WT> WT> Ilya Ryzhenkov wrote:
WT>

>>> Sorry, package was wrong - it was from previous internal build. If
>>> you have MassFixTest.cs file in source\Netix.Nerpa.Test\ subfolder,
>>> please redownload the package.
>>>
>>> http://users.netix.ru/orangy/nerpa/
>>>
>>> Sincerely,
>>> Ilya Ryzhenkov

After 2.0, I'll implement the most useful warnings from FxCop in our highlighting.

But I will be unable to use FxCop rules directly :( Instead, most valueable of them will be hardcoded

Hello Eugene,

How are you going to implement exclusion lists? FxCop warnings are different
from Resharper warnings in the level of assurance. FxCop's can be excluded,
because they may have only 90% or even 50% accuracy. Resharper's warnings
(at least now) are always true. This is what stops me from implementing even
more FxCop-like suggestions in NERPA.

EP> After 2.0, I'll implement the most useful warnings from FxCop in our
EP> highlighting.
EP>
EP> But I will be unable to use FxCop rules directly :( Instead, most
EP> valueable of them will be hardcoded
EP>
Sincerely,
Ilya Ryzhenkov

I'm not saying about all FxCop rulez, but the most valuable of them, for
example:

"type that own disposable field should be disposable"
"mark member as static"
etc.

--
Eugene Pasynkov
Developer
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"
"Ilya Ryzhenkov" <orangy@netix.ru> wrote in message
news:5992f43b10f8bb8c7f156d500e77f@news.jetbrains.com...

Hello Eugene,

>

How are you going to implement exclusion lists? FxCop warnings are
different from Resharper warnings in the level of assurance. FxCop's can
be excluded, because they may have only 90% or even 50% accuracy.
Resharper's warnings (at least now) are always true. This is what stops me
from implementing even more FxCop-like suggestions in NERPA.

>

EP> After 2.0, I'll implement the most useful warnings from FxCop in our
EP> highlighting.
EP> EP> But I will be unable to use FxCop rules directly :( Instead, most
EP> valueable of them will be hardcoded
EP> Sincerely,
Ilya Ryzhenkov

>

Hello Eugene,

this rule (already implemented in NERPA as far as I know) can certainly
generate a lot of false positives, so Ilya's question remains actual.

Regards,
Dmitry Shaporenkov
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"

I'm not saying about all FxCop rulez, but the most valuable of them,
for example:

"type that own disposable field should be disposable"

Hello Dmitry,

Yes, this rule is implemented and it sometimes
a) generates false positives (i.e. shows suggestion when all is fine), when
you create instance of disposable type and store it in the field, but transfer
ownage to different entity for disposal, e.g. some kind of cache
b) generates false negatives (i.e. does not show suggestion, when there is
a problem), when instance of disposable type is not created within a type
and stored in field when received via parameter to some call, but semantic
is that ownage is transferred. Example would be IO streams, that are filters
in .NET. In this case it is even more complex to correctly determine ownage,
because it can be dependand on another (boolean) parameter.

FxCop stores exclusions about triggered rules and maps it to assembly. I
should say it does not map always correctly, because already excluded warnings
can appear again. But FxCop at least has compiled assembly, which doesn't
change its structure a lot during minor code editions. In Resharper complete
tree for code file is rebuilt and there is no guarantee it will be the same
all the time and, as far as I understand, it is not persisted other then
in caches, which are not directly accessible for plugin developer. I can,
of course, be mistaken here, but I don't see any other way to exclude false
suggestions then embed special comments near the suggestion target.

DS> Hello Eugene,
DS>
DS> this rule (already implemented in NERPA as far as I know) can
DS> certainly generate a lot of false positives, so Ilya's question
DS> remains actual.
DS>
DS> Regards,
DS> Dmitry Shaporenkov
DS> JetBrains, Inc
DS> http://www.jetbrains.com
DS> "Develop with pleasure!"
>> I'm not saying about all FxCop rulez, but the most valuable of them,
>> for example:
>>
>> "type that own disposable field should be disposable"
>>
Sincerely,
Ilya Ryzhenkov

Hello Ilya,

you're right - the PSI source tree is built on demand, may be built only
partially (down to level of members but not to
their bodies with intention to speed-up parsing and save memory) and is not
persisted. So there's no actually any way
to store the exclusion information in the source tree.

One solution is to add special comments / regions / attributes near
the suggestion target as you mentioned. Another solution would be to store
(and persist) this information separately and bind it to the
suggestion target using range markers (check IRangeMarker in R# API for this)
or element pointers (IElementPointer). Range markers are pointers to text
that update their positions when text changes. Element pointers provide similar
functionality but point to PSI elements, so t's easier to recover IDeclaredElements
from them. Neither mechanism, however, has a persistency support. So you
could for instance persist exclusions as (file, TextRange) pairs, and use
range markers or element pointers to refer to suggestion targets at run time.
Of course, the idea needs more thoughts, but I believe it can be implemented
in one form or another without spoiling the source
code with extra text only aimed to support exclusions.

Regards,
Dmitry Shaporenkov
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"

In Resharper complete tree for code file is rebuilt and
there is no guarantee it will be the same all the time and, as far as
I understand, it is not persisted other then in caches, which are not
directly accessible for plugin developer. I can, of course, be
mistaken here, but I don't see any other way to exclude false
suggestions then embed special comments near the suggestion target.