What happened to 'Value Analysis'

Hi there,

in the 4.0 EAP, what happened to the configuration screens for 'Highlighting - Value Analysis'?

I'm running the first EAP, 4.0.730.31, and I'm getting an error flagged ("Local variable XYZ might not be initialized before accessing") because it doesn't realise my own Fail() method throws an exception.

I used to be able to configure that, in (I think) Highlighting - Value Analysis. But I can't find that in the ReSharper configuration any more. Am I looking in the right place? Or is it just not there any more?

Cheers,

Geoff

35 comments
Comment actions Permalink

Hello Geoff,

It moved to annotation with attributes rathter than options. I'm going to
write blog post about it, but here is the brief:

1. Check JetBrains.Annotations.dll, you will find some attributes there:
CanBeNullAttribute, NotNullAttribute, TerminatesProgramAttribute, AssertionMethodAttribute
and AssertionConditionAttribute, InvokerParameterNameAttribute, StringFormatMethodAttribute
and more.
2. We standardized names of attributes, so that various ReSharper users can
benefit from using existing annotations, when using 3rd party libraries.
3. We analyzed standard libraries and marked them with attributes (so called
External Annotations, when dll is not touched, but annotations are stored
somewhere in xml files). These files ship with ReSharper.

So, you may want to attach corresponding attributes to your methods. You
can either reference JetBrains.Annotations.dll, or create your own attributes
in source code with the same fully-qualified names as standard (e.g., by
decompiling our dll). You may also wish to rename your own Nullable/NotNull
attributes, if you have any and move them to corresponding namespace, so
that you have your source code updated.

In the future, we are going to extend annotations to cover more cases and
more analysis.

Sincerely,
Ilya Ryzhenkov

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


GT> Hi there,
GT>
GT> in the 4.0 EAP, what happened to the configuration screens for
GT> 'Highlighting - Value Analysis'?
GT>
GT> I'm running the first EAP, 4.0.730.31, and I'm getting an error
GT> flagged ("Local variable XYZ might not be initialized before
GT> accessing") because it doesn't realise my own Fail() method throws
GT> an exception.
GT>
GT> I used to be able to configure that, in (I think) Highlighting -
GT> Value Analysis. But I can't find that in the ReSharper
GT> configuration any more. Am I looking in the right place? Or is it
GT> just not there any more?
GT>
GT> Cheers,
GT>
GT> Geoff
GT>


0
Comment actions Permalink

Ilya,

Do the new attributes explain something I saw this morning:

This:

Path.Combine(Path.GetTempPath(), filename)

gets a blue squiggle under "Path.GetTempPath()" with the tooltip 'Possible null assignment to entity marked with 'NotNull' attribute. (With 732)

I don't actually think that Path.GetTempPath() has a possible null return - it's not documented as such - so is there perhaps an attribute missing in your XMLized version of the system libraries?

Thanks,

Will

0
Comment actions Permalink

Hello Geoff,

It moved to annotation with attributes rathter than
options.


That's a shame. I'm really not comfortable with the idea of linking to a JetBrains assembly (or any other development tool's assembly) in released, production code unless I really, really have to.

I'm not especially comfortable with the other option either - polluting my code with attributes implemented in a JetBrains.Annotations namespace. (This could be especially confusing if only some developers have ReSharper...) I've done that for now though, and now that I've got it working I'll paste in the attribute code below to save others some effort.

Will there be any way we can add our own 'External Annotations'? That would be exactly what I want - the code itself doesn't have to change to take advantage of ReSharper, and the external annotations could be imported/exported/shared the way existing settings are. And although a UI would be nice, I'd be comfortable enough editing an XML file to accomplish this.

For anyone else who is giving this a go, here's my annotation attributes file (you need to use the JetBrains.Annotations namespace):

0
Comment actions Permalink

Hello Geoff,

You can create your own external annotations by placing specially formed xml side-by-side with your assemblies. Their name should be like this: NameOfAssemblyWithoutExtension.ExternalAnnotations.xml
Examples you can find in installation folder: "C:\Program Files\JetBrains\ReSharper\v4.0\vs9.0\Bin\ExternalAnnotations"

Also you can put them to the installation folder with standard annotations. You also can edit SolutionName.4.0.resharper file and add node:
path-to-folder-where-to-look-for-other-external-annotations This can be easily team-shared and have the same structure as supplied with ReSharper. PS: I've attached original source file, but note that it can change in the future. Sincerely, Ilya Ryzhenkov JetBrains, Inc http://www.jetbrains.com "Develop with pleasure!" >> Hello Geoff, >> >> It moved to annotation with attributes rathter than options. >> GT> That's a shame. I'm really not comfortable with the idea of linking GT> to a JetBrains assembly (or any other development tool's assembly) GT> in released, production code unless I really, really have to. GT> GT> I'm not especially comfortable with the other option either - GT> polluting my code with attributes implemented in a GT> JetBrains.Annotations namespace. (This could be especially GT> confusing if only some developers have ReSharper...) I've done that GT> for now though, and now that I've got it working I'll paste in the GT> attribute code below to save others some effort. GT> GT> Will there be any way we can add our own 'External Annotations'? GT> That would be exactly what I want - the code itself doesn't have to GT> change to take advantage of ReSharper, and the external annotations GT> could be imported/exported/shared the way existing settings are. GT> And although a UI would be nice, I'd be comfortable enough editing GT> an XML file to accomplish this. GT> GT> For anyone else who is giving this a go, here's my annotation GT> attributes file (you need to use the JetBrains.Annotations GT> namespace): GT> GT>]]> using System; GT> namespace JetBrains.Annotations GT> { GT> public enum AssertionConditionType GT> { GT> IS_TRUE, GT> IS_FALSE, GT> IS_NULL, GT> IS_NOT_NULL GT> } GT> [AttributeUsage (AttributeTargets.Parameter, AllowMultiple = GT> false, Inherited = true)] GT> public class AssertionConditionAttribute : Attribute GT> { GT> public AssertionConditionAttribute (AssertionConditionType GT> conditionType) GT> { GT> ConditionType = conditionType; GT> } GT> public AssertionConditionType ConditionType GT> { GT> get; GT> private set; GT> } GT> } GT> [AttributeUsage (AttributeTargets.Method, AllowMultiple = false, GT> Inherited = true)] GT> public class AssertionMethodAttribute : Attribute GT> { GT> } GT> [AttributeUsage (AttributeTargets.Delegate | GT> AttributeTargets.Parameter | AttributeTargets.Field | GT> AttributeTargets.Property | AttributeTargets.Method, AllowMultiple = GT> false, Inherited = true)] GT> public class CanBeNullAttribute : Attribute GT> { GT> } GT> [AttributeUsage (AttributeTargets.Interface | GT> AttributeTargets.Struct | AttributeTargets.Class, AllowMultiple = GT> false, Inherited = true)] GT> public class CannotApplyEqualityOperatorAttribute : Attribute GT> { GT> } GT> [AttributeUsage (AttributeTargets.Parameter, AllowMultiple = GT> false, Inherited = true)] GT> public class InvokerParameterNameAttribute : Attribute GT> { GT> } GT> [AttributeUsage (AttributeTargets.Delegate | GT> AttributeTargets.Parameter | AttributeTargets.Field | GT> AttributeTargets.Property | AttributeTargets.Method, AllowMultiple = GT> false, Inherited = true)] GT> public class NotNullAttribute : Attribute GT> { GT> } GT> [AttributeUsage (AttributeTargets.Method | GT> AttributeTargets.Constructor, AllowMultiple = false, Inherited = GT> true)] GT> public class StringFormatMethodAttribute : Attribute GT> { GT> public StringFormatMethodAttribute (string GT> formatParameterName) GT> { GT> FormatParameterName = formatParameterName; GT> } GT> public string FormatParameterName GT> { GT> get; GT> private set; GT> } GT> } GT> [AttributeUsage (AttributeTargets.Method, AllowMultiple = false, GT> Inherited = true)] GT> public class TerminatesProgramAttribute : Attribute GT> { GT> } GT> } GT> ]]>
GT>
begin 777 Annotations.cs
M[[N_=7-I;F<@4WES=&5M.PT*#0IN86UE<W!A8V4@2F5T0G)A:6YS+D%N;F]T
M871I;VYS#0I[#0H@("\OR`\<W5M;6%R>3X-"B`@R\O($EN9&EC871E<R!T
M:&%T(&UA<FME9"!M971H;V0@8G5I;&1S('-T<FEN9R!B>2!F;W)M870@<&%T
M=&5R;B!A;F0@&]P=&EO;F%L2!A<F=U;65N=',N(`T*("`O+R\@4&%R86UE
M=&5R"!W:&EC:"!C;VYT86EN<R!F;W)M870@<W1R:6YG"!S:&]U;&0@8F4@
M9VEV96X@:6X@8V]N]]>3X-"B`@6T%T=')I8G5T955S86=E
M*$%T=')I8G5T951A<F=E=',N0V]N<W1R=6-T;W(@?"!!='1R:6)U=&5487)G
M971SDUE=&AO9"P@06QL;W=-=6QT:7!L92`](&9A;'-E"!);FAE<FET960@
M/2!T<G5E*5T-"B`@<'5B;&EC(&-L87-S(%-T<FEN9T9O<FUA=$UE=&AO9$%T
M=')I8G5T92`Z($%T=')I8G5T90T*("![#0H@("`@<')I=F%T92!R96%D;VYL
M>2!S=')I;F<@;7E&;W)M871087)A;65T97).86UE.PT*#0H@("`@<'5B;&EC
M(%-T<FEN9T9O<FUA=$UE=&AO9$%T=')I8G5T92AS=')I;F<@9F]R;6%T4&%R
M86UE=&5R3F%M92D-"B`@("![#0H@("`@("!M>49O<FUA=%!A<F%M971E<DYA
M;64@/2!F;W)M871087)A;65T97).86UE.PT("`@('T-"@T("`@('!U8FQI
M8R!S=')I;F<@1F]R;6%T4&%R86UE=&5R3F%M90T*("`@('L-"B`@("`@(&=E
M="![(')E='5R;B!M>49O<FUA=%!A<F%M971E<DYA;64[('T-"B`@("!]#0H@
M('T-"@T*("`OR\@/'-U;6UA<GD^#0H@("\OR!);F1I8V%T97,@=&AA="!T
M:&4@9G5N8W1I;VX@87)G=6UE;G0@<VAO=6QD(&)E('-T<FEN9R!L:71E<F%L
M(&%N9"!M871C:"!O;F4@(&]F('1H92!P87)A;65T97)S(&]F('1H92!C86QL
M97(@9G5N8W1I;VXN#0H@("\O+R!&;W(@97AA;7!L92P@/'-E92!C<F5F/2)!
M<F=U;65N=$YU;&Q%>&-E<'1I;VXBSX@:&%S('-U8V@@<&%R86UE=&5R@T*
M("`O+R\@/"]S=6UM87)Y/@T*("!;071T<FEB=71E57-A9V4H071T<FEB=71E
M5&%R9V5T<RY087)A;65T97(L($%L;&]W375L=&EP;&4@/2!F86QS92P@26YH
M97)I=&5D(#T@=')U92E=#0H@('!U8FQI8R!C;&%S<R!);G9O:V5R4&%R86UE
M=&5R3F%M94%T=')I8G5T92`Z($%T=')I8G5T90T("![#0H@('T-"@T("`O
MR\@/'-U;6UA<GD^#0H@("\OR!);F1I8V%T97,@=&AA="!T:&4@;6%R:V5D
M(&UE=&AO9"!I<R!A<W-E<G1I;VX@;65T:&]D"!IF4N(&ET(&AA;'1S(&-O
M;G1R;VP@9FQO=R!I9B!O;F4@;V8@=&AE(&-O;F1I=&EO;G,@:7,@<V%T:7-F
M:65DB`-"B`@R\O(%1O('-E="!T:&4@8V]N9&ET:6]N+"!M87)K(&]N92!O
M9B!T:&4@<&%R86UE=&5R<R!W:71H(#QS964@8W)E9CTB07-S97)T:6]N0V]N
M9&ET:6]N071T<FEB=71E(B\^(&%T=')I8G5T90T*("`O+R\@/"]S=6UM87)Y
M/@T*("`O+R\@/'-E96%L<V\@8W)E9CTB07-S97)T:6]N0V]N9&ET:6]N071T
M<FEB=71E(B\^#0H@(%M!='1R:6)U=&55<V%G92A!='1R:6)U=&5487)G971S
MDUE=&AO9"P@06QL;W=-=6QT:7!L92`](&9A;'-E"!);FAE<FET960@/2!T
M<G5E*5T-"B`@<'5B;&EC(&-L87-S($%S<V5R=&EO;DUE=&AO9$%T=')I8G5T
M92`Z($%T=')I8G5T90T("![#0H@('T-"@T("`O+R\@/'-U;6UA<GD^#0H@
M("\O+R!);F1I8V%T97,@=&AE(&-O;F1I=&EO;B!P87)A;65T97(@;V8@=&AE
M(&%S<V5R=&EO;B!M971H;V0N(`T*("`O+R\@5&AE(&UE=&AO9"!I='-E;&8@
M<VAO=6QD(&)E(&UA<FME9"!B>2`\<V5E(&-R968](D%S<V5R=&EO;DUE=&AO
M9$%T=')I8G5T92(O/B!A='1R:6)U=&4N#0H@("\O+R!4:&4@;6%N9&%T;W)Y
M(&%R9W5M96YT(&]F('1H92!A='1R:6)U=&4@:7,@=&AE(&%S<V5R=&EO;B!T
M>7!E@T*("`OR\@/"]S=6UM87)Y/@T*("`O+R\@/'-E96%L<V\@8W)E9CTB
M07-S97)T:6]N0V]N9&ET:6]N5'EP92(O/@T*("!;071T<FEB=71E57-A9V4H
M071T<FEB=71E5&%R9V5T<RY087)A;65T97(L($%L;&]W375L=&EP;&4@/2!F
M86QS92P@26YH97)I=&5D(#T@=')U92E=#0H@('!U8FQI8R!C;&%S<R!!<W-E
M<G1I;VY#;VYD:71I;VY!='1R:6)U=&4@.B!!='1R:6)U=&4-"B`@>PT*("`@
M('!R:79A=&4@<F5A9&]N;'D@07-S97)T:6]N0V]N9&ET:6]N5'EP92!M>4-O
M;F1I=&EO;E1Y<&4[#0H-"B`@("!P=6)L:6,@07-S97)T:6]N0V]N9&ET:6]N
M071T<FEB=71E*$%S<V5R=&EO;D-O;F1I=&EO;E1Y<&4@8V]N9&ET:6]N5'EP
M92D-"B`@("![#0H@("`@("!M>4-O;F1I=&EO;E1Y<&4@/2!C;VYD:71I;VY4
M>7!E.PT("`@('T-"@T("`@('!U8FQI8R!!<W-E<G1I;VY#;VYD:71I;VY4
M>7!E($-O;F1I=&EO;E1Y<&4-"B`@("![#0H@("`@("!G970@>R!R971U<FX@
M;7E#;VYD:71I;VY4>7!E.R!]#0H@("`@?0T*("!]#0H-"B`@+R\O(#QS=6UM
M87)Y/@T*("`OR\@4W!E8VEF:65S(&%S<V5R=&EO;B!T>7!EB!)9B!T:&4@
M87-S97)T:6]N(&UE=&AO9"!A<F=U;65N="!S871I<VEF97,@=&AE(&-O;F1I
M=&EO;BP@=&AE;B!T:&4@97AE8W5T:6]N(&-O;G1I;G5E<RX@#0H@("\O+R!/
M=&AE<G=I<V4L(&5X96-U=&EO;B!I<R!A<W-U;65D('1O(&)E(&AA;'1E9`T*
M("`O+R\@/"]S=6UM87)Y/@T*("!P=6)L:6,@96YU;2!!<W-E<G1I;VY#;VYD
M:71I;VY4>7!E#0H@('L-"B`@("`OR\@/'-U;6UA<GD^#0H@("`@R\O($EN
M9&EC871E<R!T:&%T('1H92!M87)K960@<&%R86UE=&5R('-H;W5L9"!B92!E
M=F%L=6%T960@=&\@=')U90T*("`@("\OR`\W-U;6UA<GD^#0H@("`@25-?
M5%)512`](#`L#0H-"B`@("`OR\@/'-U;6UA<GD^#0H@("`@R\O($EN9&EC
M871E<R!T:&%T('1H92!M87)K960@<&%R86UE=&5R('-H;W5L9"!B92!E=F%L
M=6%T960@=&\@9F%L<V4-"B`@("`O+R\@/"]S=6UM87)Y/@T*("`@($E37T9!
M3%-%(#T@,2P-"@T*("`@("\OR`\<W5M;6%R>3X-"B`@("`OR\@26YD:6-A
M=&5S('1H870@=&AE(&UA<FME9"!P87)A;65T97(@<VAO=6QD(&)E(&5V86QU
M871E9"!T;R!N=6QL('9A;'5E#0H@("`@+R\O(#PO<W5M;6%R>3X-"B`@("!)
M4U].54Q,(#T@,BP-"@T*("`@("\OR`\<W5M;6%R>3X-"B`@("`OR\@26YD
M:6-A=&5S('1H870@=&AE(&UA<FME9"!P87)A;65T97(@<VAO=6QD(&)E(&5V
M86QU871E9"!T;R!N;W0@;G5L;"!V86QU90T*("`@("\OR`\W-U;6UA<GD^
M#0H@("`@25-?3D]47TY53$P@/2`S`T*("!]#0H-"B`@R\O(#QS=6UM87)Y
M/@T*("`O+R\@26YD:6-A=&5S('1H870@=&AE(&UA<FME9"!M971H;V0@=6YC
M;VYD:71I;VYA;&QY('1E<FUI;F%T97,@8V]N=')O;"!F;&]W(&5X96-U=&EO
M;@T("`O+R\@/"]S=6UM87)Y/@T("!;071T<FEB=71E57-A9V4H071T<FEB
M=71E5&%R9V5T<RY-971H;V0L($%L;&]W375L=&EP;&4@/2!F86QS92P@26YH
M97)I=&5D(#T@=')U92E=#0H@('!U8FQI8R!C;&%S<R!497)M:6YA=&5S4')O
M9W)A;4%T=')I8G5T92`Z($%T=')I8G5T90T("![#0H@('T-"@T("`O+R\@
M/'-U;6UA<GD^#0H@("\O+R!);F1I8V%T97,@=&AA="!T:&4@=F%L=64@;V8@
M;6%R:V5D(&5L96UE;G0@8V]U;&0@8F4@/&,^;G5L;#PO8SX@<V]M971I;65S
M"!S;R!T:&4@8VAE8VL@9F]R(#QC/FYU;&P\V,^(&ES(&YE8V5S<V%R>2!B
M969O<F4@:71S('5S86=E#0H@("\OR`\W-U;6UA<GD^#0H@(%M!='1R:6)U
M=&55<V%G92A!='1R:6)U=&5487)G971S+DUE=&AO9"!\($%T=')I8G5T951A
M<F=E=',N4&%R86UE=&5R('P@071T<FEB=71E5&%R9V5T<RY0<F]P97)T>2!\
M($%T=')I8G5T951A<F=E=',N1&5L96=A=&4@?"!!='1R:6)U=&5487)G971S
MD9I96QD"!!;&QO=TUU;'1I<&QE(#T@9F%L<V4L($EN:&5R:71E9"`]('1R
M=64I70T*("!P=6)L:6,@8VQA<W,@0V%N0F5.=6QL071T<FEB=71E(#H@071T
M<FEB=71E#0H@('L-"B`@?0T*#0H@("\OR`\<W5M;6%R>3X-"B`@R\O($EN
M9&EC871E<R!T:&%T('1H92!V86QU92!O9B!M87)K960@96QE;65N="!C;W5L
M9"!N979E<B!B92`\8SYN=6QL/"]C/@T("`O+R\@/"]S=6UM87)Y/@T("!;
M071T]]>PT("!]#0H-"B`@+R\O(#QS=6UM87)Y/@T("`O
M+R\@26YD:6-A=&5S('1H870@=&AE('9A;'5E(&]F(&UA<FME9"!T>7!E("AO
M<B!I=',@9&5R:79A=&EV97,I(&-A;FYO="!B92!C;VUP87)E9"!U<VEN9R`G
M/3TG(&]R("<A/2<@;W!E<F%T;W)S@T*("`OR\@5&AE<F4@:7,@;VYL>2!E
M>&-E<'1I;VX@=&\@8V]M<&%R92!W:71H(#QC/FYU;&P\+V,^+"!I="!I<R!P
M97)M:71T960-"B`@+R\O(#PO<W5M;6%R>3X-"B`@6T%T=')I8G5T955S86=E
M*$%T=')I8G5T951A<F=E=',N26YT97)F86-E('P@071T<FEB=71E5&%R9V5T
M<RY#;&%S<R!\($%T=')I8G5T951A<F=E=',N4W1R=6-T+"!!;&QO=TUU;'1I
M<&QE(#T@9F%L<V4L($EN:&5R:71E9"`]('1R=64I70T*("!P=6)L:6,@8VQA
M<W,@0V%N;F]T07!P;'E%<75A;&ET>4]P97)A=&]R071T<FEB=71E(#H@071T
3<FEB=71E#0H@('L-"B`@?0T*?6ET
`
end

0
Comment actions Permalink

Hi there,

Great solution! I'm much happier sharing an XML file than changing the code.

Unfortunately I can't get it to work. I got the attribute annotations working straight away, but the XML for the external annotations isn't working for me.

I took a copy of the NUnit XML file and altered it for my methods. But it just doesn't seem to be picked up by ReSharper - either when it's in the bin directory (alongside the assembly) or when it's in the folder specified in the .resharper file.

There's no mention of any problems with it in the log - there's no mention of it at all, in fact.

Any ideas?

Geoff

P.S. the file you attached last time seems to be garbled.

0
Comment actions Permalink

Hello Geoff,

You may have to reopen solution for external annotations to be reloaded.

Sincerely,
Ilya Ryzhenkov

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


GT> Hi there,
GT>
GT> Great solution! I'm much happier sharing an XML file than changing
GT> the code.
GT>
GT> Unfortunately I can't get it to work. I got the attribute
GT> annotations working straight away, but the XML for the external
GT> annotations isn't working for me.
GT>
GT> I took a copy of the NUnit XML file and altered it for my methods.
GT> But it just doesn't seem to be picked up by ReSharper - either when
GT> it's in the bin directory (alongside the assembly) or when it's in
GT> the folder specified in the .resharper file.
GT>
GT> There's no mention of any problems with it in the log - there's no
GT> mention of it at all, in fact.
GT>
GT> Any ideas?
GT>
GT> Geoff
GT>
GT> P.S. the file you attached last time seems to be garbled.
GT>


0
Comment actions Permalink

You may have to reopen solution for external
annotations to be reloaded.


Heh - yeah, I've restarted VS a bunch of times, as well as switching solutions, to see if that would make any difference, but it hasn't.

Geoff

0
Comment actions Permalink

Please try the following:

In the path specified in the ".resharper" file create the subdirectory with
the name of your assembly (Without ".dll" of course), and place your XML
into that subdir. Restart VS.
Will this help?

--
Eugene Pasynkov
Developer
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"
"Geoff Taylor" <no_replay@jetbrains.com> wrote in message
news:16577160.1203525917378.JavaMail.itn@is.intellij.net...

Hi there,

>

Great solution! I'm much happier sharing an XML file than changing the
code.

>

Unfortunately I can't get it to work. I got the attribute annotations
working straight away, but the XML for the external annotations isn't
working for me.

>

I took a copy of the NUnit XML file and altered it for my methods. But it
just doesn't seem to be picked up by ReSharper - either when it's in the
bin directory (alongside the assembly) or when it's in the folder
specified in the .resharper file.

>

There's no mention of any problems with it in the log - there's no mention
of it at all, in fact.

>

Any ideas?

>

Geoff

>

P.S. the file you attached last time seems to be garbled.



0
Comment actions Permalink

Please try the following:

In the path specified in the ".resharper" file create
the subdirectory with
the name of your assembly (Without ".dll" of course),
and place your XML
into that subdir. Restart VS.


Hi there,

I should have thought of that. Sorry for not having tried that already.

It didn't work. I tried it with the file named .xml as well as ]]>.ExternalAnnotations.xml, and neither worked.

Any more ideas?

Cheers,

Geoff

0
Comment actions Permalink

Hmmm... very stange.

Stupid question: have you modified the assembly name in the XML file
contents? May be you send the portions the XML file to me to make sure there
are no problems there.....

--
Eugene Pasynkov
Developer
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"
"Geoff Taylor" <no_replay@jetbrains.com> wrote in message
news:685967.1203531341050.JavaMail.itn@is.intellij.net...
>> Please try the following:
>>
>> In the path specified in the ".resharper" file create
>> the subdirectory with
>> the name of your assembly (Without ".dll" of course),
>> and place your XML
>> into that subdir. Restart VS.
>

Hi there,

>

I should have thought of that. Sorry for not having tried that already.

>

It didn't work. I tried it with the file named <AssemblyName>.xml as well
as <AssemblyName>.ExternalAnnotations.xml, and neither worked.

>

Any more ideas?

>

Cheers,

>

Geoff



0
Comment actions Permalink

Stupid question: have you modified the assembly name
in the XML file
contents? May be you send the portions the XML file
to me to make sure there
are no problems there.....


I hope I haven't made a stupid mistake like that...!

I can't find an email address for you, so I've emailed the XML file (and some other details) to support@jetbrains.com with a note for them to forward it on to you. (It should have arrived in their inbox by now.)

Many thanks,

Geoff

0
Comment actions Permalink

And one more note: the external annotation mechanism (using XML files) works
ONLY if you reference the DLL and do not have such project in your solution,
i.e. pure binary usage.

If you would like to use regular source project, and use XML file for value
analysis attributes, such approach won't work right now :(

--
Eugene Pasynkov
Developer
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"
"Geoff Taylor" <no_replay@jetbrains.com> wrote in message
news:21467909.1203590316437.JavaMail.itn@is.intellij.net...
>> Stupid question: have you modified the assembly name
>> in the XML file
>> contents? May be you send the portions the XML file
>> to me to make sure there
>> are no problems there.....
>

I hope I haven't made a stupid mistake like that...!

>

I can't find an email address for you, so I've emailed the XML file (and
some other details) to support@jetbrains.com with a note for them to
forward it on to you. (It should have arrived in their inbox by now.)

>

Many thanks,

>

Geoff



0
Comment actions Permalink

And one more note: the external annotation mechanism
(using XML files) works
ONLY if you reference the DLL and do not have such
project in your solution,
i.e. pure binary usage.


Aha. That's the source of my problem. The external annotations were to be applied to the currently-loaded project.

If you would like to use regular source project, and
use XML file for value
analysis attributes, such approach won't work right
now :(


That's a shame - I really thought we were on to something! Is it ever likely to work? The attribute annotation method works with the currently-loaded project, so is this limitation of external annotations just for the current state of the EAP, or is it likely to continue to be a limitation in the full 4.0 release?

Many thanks (and kudos for what's been a remarkably stable EAP for me),

Geoff

0
Comment actions Permalink

That's a shame - I really thought we were on to something! Is it ever
likely to work? The attribute annotation method works with the
currently-loaded project, so is this limitation of external annotations
just for the current state of the EAP, or is it likely to continue to be a
limitation in the full 4.0 release?


Right now this is limitation how external annotations are implemented.

We can't use XML file along with the sources because it would be nearlly
impossible (or, better, will cost tons of efforts) to syncronize changes in
source code due to refactorings with that external XML file.

Why you wouldn't like creating the source file for these attributes and use
them as regular attributes? Because of the "JetBrains" in the naming, or
somethig else?

--
Eugene Pasynkov
Developer
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"


0
Comment actions Permalink

We can't use XML file along with the sources because
it would be nearlly
impossible (or, better, will cost tons of efforts) to
syncronize changes in
source code due to refactorings with that external
XML file.


Really? I'm not sure I see how it's different from the annotation attributes in that regard. (And if I change the names or signatures of any of those methods, I'm perfectly happy for it to be my responsibility to change the external annotations file, and for the annotations not to work until I do.)

Why you wouldn't like creating the source file for
these attributes and use
them as regular attributes? Because of the
"JetBrains" in the naming, or
somethig else?


I'm just not comfortable with either:
1) Adding yet another external dependency in my released code, or
2) Polluting my code with attributes from a development tool's namespace, and worse - having to put some of that development tool's code in my own assembly.

Both those approaches seem unrealistic for released code, from my point of view. I really think this kind of thing should work like NUnit or similar aids to development - they're used by (some) developers, but they place no requirements on deployment or on the released code itself. With NUnit you can have separate assemblies that link to your production code, that contains your unit tests, but the production code itself remains pure.

I firmly believe you shouldn't have to change your released/production code to take advantage of a development tool.

Many thanks,

Geoff

0
Comment actions Permalink

Thank you. I've understood your point of view.
We have to think how could we support your scenario, since it looks like
rather common

--
Eugene Pasynkov
Developer
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"
"Geoff Taylor" <no_replay@jetbrains.com> wrote in message
news:18314657.1203599229313.JavaMail.itn@is.intellij.net...
>> We can't use XML file along with the sources because
>> it would be nearlly
>> impossible (or, better, will cost tons of efforts) to
>> syncronize changes in
>> source code due to refactorings with that external
>> XML file.
>

Really? I'm not sure I see how it's different from the annotation
attributes in that regard. (And if I change the names or signatures of any
of those methods, I'm perfectly happy for it to be my responsibility to
change the external annotations file, and for the annotations not to work
until I do.)

>
>> Why you wouldn't like creating the source file for
>> these attributes and use
>> them as regular attributes? Because of the
>> "JetBrains" in the naming, or
>> somethig else?
>

I'm just not comfortable with either:
1) Adding yet another external dependency in my released code, or
2) Polluting my code with attributes from a development tool's namespace,
and worse - having to put some of that development tool's code in my own
assembly.

>

Both those approaches seem unrealistic for released code, from my point of
view. I really think this kind of thing should work like NUnit or similar
aids to development - they're used by (some) developers, but they place no
requirements on deployment or on the released code itself. With NUnit you
can have separate assemblies that link to your production code, that
contains your unit tests, but the production code itself remains pure.

>

I firmly believe you shouldn't have to change your released/production
code to take advantage of a development tool.

>

Many thanks,

>

Geoff



0
Comment actions Permalink

Thank you. I've understood your point of view.
We have to think how could we support your scenario,
since it looks like
rather common


Thanks for that - keep up the good work!

Geoff

0
Comment actions Permalink

Was anything ever done about this? I'm still not comfortable with either:
1) Adding yet another external dependency in my released code, or
2) Polluting my code with attributes from a development tool's namespace, and worse - having to put some of that development tool's code in my own assembly.

I still think this kind of thing should work like NUnit or similar aids to development - they're used by (some) developers, but they place no requirements on deployment or on the released code itself. With NUnit you can have separate assemblies that link to your production code, that contains your unit tests, but the production code itself remains pure.

The MS classes are annotated using XML files - is it possible to use this mechanism in the 4.0 release to annotate project assemblies?

Many thanks,

Geoff

0
Comment actions Permalink

Hello Geoff,

You can use Value Analysis without including a 3-party assembly or using
a special namespace.

Here is what we have done:

1) We created all the attributes ourselves - with the correct names, but
in our own namespace. You can get the source code for the attributes from
the Options / Code Annotations page. This uses the JetBrains namespace, but
you are free to change it.

2) The Code Annotation engine must be made aware of these new attribute.
For some reason the Code Annotations page is not very editable (or I have
not figured out how to use it). But you can edit the ".4.0.resharper" file to add your namespace. You can do a text search in *.resharper files for "". Our file looks like this: JetBrains.Annotations Sitecore Sitecore ]]>

3) In the Code Annotation page, your namespace should now appear and you
can use your own attributes to mark up your code.

I think this architecture was chosen as it would allow the Value Analysis
engine to react to multiple attributes - local attributes in your own code,
attributes in markup'ed .Net Framework, and attributes in 3-party modules.

But I also really wish that such a fantastic feature was a little more easy
to setup.

Best regards
--Jakob

Was anything ever done about this? I'm still not comfortable with
either:

1) Adding yet another external dependency in my released code, or

2) Polluting my code with attributes from a development tool's
namespace, and worse - having to put some of that development tool's
code in my own assembly.

I still think this kind of thing should work like NUnit or similar
aids to development - they're used by (some) developers, but they
place no requirements on deployment or on the released code itself.
With NUnit you can have separate assemblies that link to your
production code, that contains your unit tests, but the production
code itself remains pure.

The MS classes are annotated using XML files - is it possible to use
this mechanism in the 4.0 release to annotate project assemblies?

Many thanks,

Geoff



0
Comment actions Permalink

Hello Jakob,

Code Annotations option page should pick up namespaces with attributes automatically.
If it doesn't, it is probably a bug.
The intednded workflow would be like this:
1. Copy source code for attributes from the options page
2. Insert into your project, rename namespaces as needed
3. Open options once more and namespace should have been detected, so that
you only enable it.

Sincerely,
Ilya Ryzhenkov

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


JC> Hello Geoff,
JC>
JC> You can use Value Analysis without including a 3-party assembly or
JC> using a special namespace.
JC>
JC> Here is what we have done:
JC>
JC> 1) We created all the attributes ourselves - with the correct names,
JC> but in our own namespace. You can get the source code for the
JC> attributes from the Options / Code Annotations page. This uses the
JC> JetBrains namespace, but you are free to change it.
JC>
JC> 2) The Code Annotation engine must be made aware of these new
JC> attribute. For some reason the Code Annotations page is not very
JC> editable (or I have not figured out how to use it). But you can edit
JC> the ".4.0.resharper" file to add your namespace. You JC> can do a text search in *.resharper files for "". JC> JC> Our file looks like this: JC> JC> JC> JC> JetBrains.Annotations JC> Sitecore JC> Sitecore JC> JC> JC> 3) In the Code Annotation page, your namespace should now appear and JC> you can use your own attributes to mark up your code. JC> JC> I think this architecture was chosen as it would allow the Value JC> Analysis engine to react to multiple attributes - local attributes JC> in your own code, attributes in markup'ed .Net Framework, and JC> attributes in 3-party modules. JC> JC> But I also really wish that such a fantastic feature was a little JC> more easy to setup. JC> JC> Best regards JC> --Jakob >> Was anything ever done about this? I'm still not comfortable with >> either: >> >> 1) Adding yet another external dependency in my released code, or >> >> 2) Polluting my code with attributes from a development tool's >> namespace, and worse - having to put some of that development tool's >> code in my own assembly. >> >> I still think this kind of thing should work like NUnit or similar >> aids to development - they're used by (some) developers, but they >> place no requirements on deployment or on the released code itself. >> With NUnit you can have separate assemblies that link to your >> production code, that contains your unit tests, but the production >> code itself remains pure. >> >> The MS classes are annotated using XML files - is it possible to use >> this mechanism in the 4.0 release to annotate project assemblies? >> >> Many thanks, >> >> Geoff >>]]>


0
Comment actions Permalink

Hello Ilya,

Ahh - that's cool - very JetBrains-like.

Thank you.

--Jakob

Hello Jakob,

Code Annotations option page should pick up namespaces with attributes
automatically.
If it doesn't, it is probably a bug.
The intednded workflow would be like this:
1. Copy source code for attributes from the options page
2. Insert into your project, rename namespaces as needed
3. Open options once more and namespace should have been detected, so
that
you only enable it.
Sincerely,
Ilya Ryzhenkov
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"

JC>> Hello Geoff,
JC>>
JC>> You can use Value Analysis without including a 3-party assembly or
JC>> using a special namespace.
JC>>
JC>> Here is what we have done:
JC>>
JC>> 1) We created all the attributes ourselves - with the correct
JC>> names, but in our own namespace. You can get the source code for
JC>> the attributes from the Options / Code Annotations page. This uses
JC>> the JetBrains namespace, but you are free to change it.
JC>>
JC>> 2) The Code Annotation engine must be made aware of these new
JC>> attribute. For some reason the Code Annotations page is not very
JC>> editable (or I have not figured out how to use it). But you can
JC>> edit the ".4.0.resharper" file to add your JC>> namespace. You can do a text search in *.resharper files for JC>> "". JC>> JC>> Our file looks like this: JC>> JC>> JC>> JC>> JetBrains.Annotations JC>> Sitecore JC>> Sitecore JC>> JC>> JC>> 3) In the Code Annotation page, your namespace should now appear JC>> and JC>> you can use your own attributes to mark up your code. JC>> I think this architecture was chosen as it would allow the Value JC>> Analysis engine to react to multiple attributes - local attributes JC>> in your own code, attributes in markup'ed .Net Framework, and JC>> attributes in 3-party modules. JC>> JC>> But I also really wish that such a fantastic feature was a little JC>> more easy to setup. JC>> JC>> Best regards JC>> --Jakob >>> Was anything ever done about this? I'm still not comfortable with >>> either: >>> >>> 1) Adding yet another external dependency in my released code, or >>> >>> 2) Polluting my code with attributes from a development tool's >>> namespace, and worse - having to put some of that development tool's >>> code in my own assembly. >>> >>> I still think this kind of thing should work like NUnit or similar >>> aids to development - they're used by (some) developers, but they >>> place no requirements on deployment or on the released code itself. >>> With NUnit you can have separate assemblies that link to your >>> production code, that contains your unit tests, but the production >>> code itself remains pure. >>> >>> The MS classes are annotated using XML files - is it possible to use >>> this mechanism in the 4.0 release to annotate project assemblies? >>> >>> Many thanks, >>> >>> Geoff >>>]]>


0
Comment actions Permalink

Hi,

Thanks for that. I'm just not comfortable adding code to my project just to support ReSharper. Adding a new reference to a product is a big deal, and so is adding new code that's not relevant to the majority of developers on the team.

Basically, I want to tell ReSharper which methods are Assertion, Failure or string format methods. I don't want to put new code in my product to do it - I just want to configure Resharper. It's not relevant to my product, so why would I want to add this to a deployed DLL?

It seems like a big step backwards from version 3, where it was possible to configure ReSharper for such things. Having to configure ReSharper to work with my project is OK. Having to change my project/product for ReSharper is another thing entirely - and a very bad thing in my opinion.

I'm sorry I stopped complaining about this back in February when they said "We have to think how could we support your scenario", because it looks like they just dropped it completely.

Geoff

0
Comment actions Permalink

I too would have preferred a way to tell ReSharper which attributes have which aspects, rather than having to use RS defined attribute names. It helps that we can put the attributes in any namespace, but since the sample code from JB for these attributes is a little sloppy, which is disappointing.

However, I don't mind that attibutes need to be use, just that RS locks us into specific names and sloppy code.

0
Comment actions Permalink

Hello,

From R#3 we learned that keeping annotations external to the source code
is a mostly uncomfortable thing — in creating, sharing, and maintaining them.
Another uncomfortable thing is a requirement for a DLL reference or commitment
to some predefined namespace, like "JetBrains.Annotations", as it will eventually
show up in namespace imports in each and every file.

Finally, we worked out a solution that is less uncomfortable. You do not
need to reference a DLL, you are free in choosing a namespace, you are free
to keep attributes from production code with conditionals on them, and the
annotations are per-solution, which is as it should be. The only uncomfortable
thing left to do is introduce the attributes once. After that, everything
gets comfortable again.


Serge Baltic
JetBrains, Inc — http://www.jetbrains.com
“Develop with pleasure!”


0
Comment actions Permalink

I disagree very strongly with the notion that it's better to have to change my code to work with a given tool than configure that tool to work with my code.

Geoff

0
Comment actions Permalink

I have to agree with Geoff here.

Only a few developers use Resharper, while many do not. We all work on the
same code.

There should be a way for me to specify LOCALLY to my system only, such
things, so that it doesn't affect any other developer who chooses a
different development environment.


"Serge Baltic" <baltic@intellij.net> wrote in message
news:dc0986bff54558ca9ad5ce3aae3f@news.intellij.net...

Hello,

>

From R#3 we learned that keeping annotations external to the source code
is a mostly uncomfortable thing — in creating, sharing, and maintaining
them. Another uncomfortable thing is a requirement for a DLL reference or
commitment to some predefined namespace, like "JetBrains.Annotations", as
it will eventually show up in namespace imports in each and every file.

>

Finally, we worked out a solution that is less uncomfortable. You do not
need to reference a DLL, you are free in choosing a namespace, you are
free to keep attributes from production code with conditionals on them,
and the annotations are per-solution, which is as it should be. The only
uncomfortable thing left to do is introduce the attributes once. After
that, everything gets comfortable again.

>


Serge Baltic
JetBrains, Inc — http://www.jetbrains.com
“Develop with pleasure!”

>


0
Comment actions Permalink

But the kind of annotations in question are really designed at tightening the API, so they really should be applied (i.e. visible) to all consumers of the code. This includes visibility via documentation (intellisense, Sandcastle, ...) as well as compile/run-time

Since these attributes are essentially ignored outside of RS (or custom test code that understands them), I don't see your point, or any benefit to a mechanism that does not embed these annotations for reuse by all.

0
Comment actions Permalink

Hello,

I disagree very strongly with the notion that it's better to have to
change my code to work with a given tool than configure that tool to
work with my code.


Well, I can't quite recall making a notion about one being better than the
other. I just said that we rendered the least uncomfortable solution, and
described it briefly.

Why, it's not the Tool that makes your method an assertion one, and it's
not the Tool that prohibits assigning Null to a certain entity. It's a property
of the code itself rather than the Tool, just by its nature. It does not
mean that we should pollute the code, of course. But it means that this data
must be shared along with the code and that it must evolve with the code.

To the latter requirements, attributes are a natural solution. They are stored
with the code, they're persistent through any reasonable refactorings and
code transformations. Even those that are performed without the Tool, most
notably.

We'd like to see our code cleaner too, no problem. But not before we have
something to replace the attributes with. That "something" must be tolerant
to external changes to the code, must follow source code control merge of
the code, must avoid conflicts on checkin/update, should be available to
external tools like documentation generators and FxCop validators. Not an
easy thing to do. Not implemented yet. Thus — no alternative yet. Suggestions
are welcome.


Serge Baltic
JetBrains, Inc — http://www.jetbrains.com
“Develop with pleasure!”


0
Comment actions Permalink

Hello,

I have to agree with Geoff here.

Only a few developers use Resharper, while many do not. We all work
on the same code.

There should be a way for me to specify LOCALLY to my system only,
such things, so that it doesn't affect any other developer who chooses
a different development environment.


R# is useful, but not necessary to benefit from the nullity annotations.
From the other side, what about other developers affecting what you specify
locally? Say a class with null-annotated members is renamed or moved. We
do not have a technology yet for the externally-specified attributes to catch
up with the change, which is one of the main reasons for using embedded source
code annotations. Should such a technology be available, it would be a major
point in favor of the externally-stored annotations.

We know of the disadvantages. But we do not have the answer yet.


Serge Baltic
JetBrains, Inc — http://www.jetbrains.com
“Develop with pleasure!”


0
Comment actions Permalink

Why, it's not the Tool that makes your method an assertion one, and it's
not the Tool that prohibits assigning Null to a certain entity. It's a property
of the code itself rather than the Tool, just by its nature. It does not
mean that we should pollute the code, of course. But it means that this data
must be shared along with the code and that it must evolve with the code.


I think that overcomplicates the situation. It's really much simpler than that for me (and maybe for others):

1. Some folks on the team use ReSharper.
2. These folks all have a shared configuration for the solution that specifies how Resharper should work on that solution.
3. This works for all of ReSharper except for the value analysis. To get that to work, I must change the core project code to introduce attributes that provide no benefits to the customer or company - only for the few developers on the team that use ReSharper.

As it stands, I just can't use the value analysis attributes. It would fail code review because it's unnecessary for the project and it only benefits one or two developers who have paid their own good money for ReSharper.

I'm not against the use of attributes - they do provide benefits. I'm against that being the only solution - I'm against it being required. It still seems like a step backwards from version 3.0, where I could have the benefits of value analysis without polluting my code.

The truth is that there are few classes that are used for assertions or string formatting (at least in the projects I've seen), and they're rarely refactored. If I had to manually change the (shared) configuration each time they were refactored, that would be acceptable because at least it would make using the value analysis possible.

Geoff

0

Please sign in to leave a comment.