Tighter scoping on properties == compile error in Assert.That()?

[Chad Kittel]

Today I thought I would try out the 2.5.x series (was on 2.4.x) and
ran into an unexpected road-block.

The following line of code
Assert.That(costIncreases(0).FixedPriceType, [Is].EqualTo
(AmountType.PerCase))

is now giving me a compile error:
Error 1 'Set' accessor of property 'FixedPriceType' is not accessible.
C:\working.net2\TestSuites\UnitTests\iitCamilla.Test\dev
\CostIncreaseReportData.vb 1419 29 iitCamilla.Test

The property is defined in a separate assembly as follows:
Public Property FixedPriceType() As AmountType
Get
Return Me.mFixedPriceType
End Get
Friend Set(ByVal value As AmountType)
Me.mFixedPriceType = value
End Set
End Property

Notice that the property's setter is scoped Friend.

BTW, If I change this property to be a ReadOnly property and whack the
setter out of there, the compile error goes away or if I remove the
restricted scoping on the setter, the compile error goes away.

Also BTW, this is a .NET 2.0 assembly, compiled with the Visual Studio
2008 SP1 compiler.

Anyone know what is going on here?

[Chad Kittel]

Thought of one more thing that may or may not be of interest, but to
help complete the picture...

On May 14, 11:17 am, Chad Kittel <chad.kit...@gmail.com> wrote:
> The following line of code
> Assert.That(costIncreases(0).FixedPriceType, [Is].EqualTo
> (AmountType.PerCase))

costIncreases(0) is returning a value type (structure)

[Chad Kittel]

I opened up a bug report for this issue on SourceForge and provided a
small example to help someone repro it.

Artifact number: 2792355
https://sourceforge.net/tracker/?func=detail&aid=2792355&group_id=10749&atid=110749

[Simone Busoli]

This is pretty weird, the overload resolution is completely different from that of C#, and it tries to use the generic That method with the ref modifier, which obviously requires the property to be settable publicly.

[Chad Kittel]

Simone,

On May 18, 7:58 am, Simone Busoli <simone.bus...@gmail.com> wrote:
> This is pretty weird, the overload resolution is completely different from
> that of C#, and it tries to use the generic That method with the ref
> modifier, which obviously requires the property to be settable publicly.

Boy, I've been hoping to convince management that we should rewrite
our entire business object library in C#; here is yet another bullet-
point I get to add to my PowerPoint presentation on reasons why we
should! YaY! ;)

All kidding aside, do you have any idea if this is "fixable" in NUnit
itself and yet still be keep the new generics/overloads in existence?
I'm assuming I'm not going to be the last you hear on the issue as
2.5.x becomes more and more adopted by us crazy VB developers. We
make pretty solid usage of the reduced-scope setters.

[Simone Busoli]

Actually, it looks trickier than it seemed in the beginning. In C# you cannot pass properties to methods as an argument passed by reference, while this is what is happening here. I don't know how to fix it, not until I understand what is going on here.

[Charlie Poole]

Yeah, it's a mystery to me too. I see the bug is filed, so we'll at least

try to fix it for a point release.

Charlie

---

From: nunit-...@googlegroups.com [mailto:nunit-...@googlegroups.com] On Behalf Of Simone Busoli
Sent: Monday, May 18, 2009 2:59 PM
To: nunit-...@googlegroups.com
Subject: [nunit-discuss] Re: Tighter scoping on properties == compile error in Assert.That()?

[Simone Busoli]

I did some research, and it looks like VB indeed allows properties to
be passed by reference. Chad said that making it readonly or removing
the visibility restriction on the setter solved the problem, I wonder
if that's because the compiler would choose a different overload of
That. If that's the case then we've hit a corner case and we should
address it specifically, but if every time you pass a property in VB
the compiler chooses the overload with the ref modifier then it would
make sense to remove that overload completely maybe.

2009/5/23, Charlie Poole <cha...@nunit.com>:

> Yeah, it's a mystery to me too. I see the bug is filed, so we'll at least
> try to fix it for a point release.
>
> Charlie
>
>
> _____
>

> From: nunit-...@googlegroups.com [mailto:nunit-...@googlegroups.com]
> On Behalf Of Simone Busoli
> Sent: Monday, May 18, 2009 2:59 PM
> To: nunit-...@googlegroups.com
> Subject: [nunit-discuss] Re: Tighter scoping on properties == compile error
> in Assert.That()?
>
>
> This is pretty weird, the overload resolution is completely different from
> that of C#, and it tries to use the generic That method with the ref
> modifier, which obviously requires the property to be settable publicly.
>
> On Fri, May 15, 2009 at 18:14, Chad Kittel <chad....@gmail.com> wrote:
>
>
>
> I opened up a bug report for this issue on SourceForge and provided a
> small example to help someone repro it.
>
> Artifact number: 2792355
> https://sourceforge.net/tracker/?func=detail

> <https://sourceforge.net/tracker/?func=detail&aid=2792355&group_id=10749&ati
> d=110749> &aid=2792355&group_id=10749&atid=110749
>
>
>
>
>
>
>
>
>
> >
>

--
Inviato dal mio dispositivo mobile

[Charlie Poole]

We could use a different method (instead of That) to represent
the use of a reference argument, although I dislike proliferating
methods for doing essentially the same thing.

Any other ideas?

Charlie

[charliepoole]

As a test, I completely eliminated the ref overloads and the error
remains. Weird stuff.

On May 23, 10:55 pm, Simone Busoli <simone.bus...@gmail.com> wrote:
> I did some research, and it looks like VB indeed allows properties to
> be passed by reference. Chad said that making it readonly or removing
> the visibility restriction on the setter solved the problem, I wonder
> if that's because the compiler would choose a different overload of
> That. If that's the case then we've hit a corner case and we should
> address it specifically, but if every time you pass a property in VB
> the compiler chooses the overload with the ref modifier then it would
> make sense to remove that overload completely maybe.
>

> 2009/5/23, Charlie Poole <char...@nunit.com>:

>
>
>
> > Yeah, it's a mystery to me too. I see the bug is filed, so we'll at least
> > try to fix it for a point release.
>
> > Charlie
>
> >   _____
>
> > From: nunit-...@googlegroups.com [mailto:nunit-...@googlegroups.com]
> > On Behalf Of Simone Busoli
> > Sent: Monday, May 18, 2009 2:59 PM
> > To: nunit-...@googlegroups.com
> > Subject: [nunit-discuss] Re: Tighter scoping on properties == compile error
> > in Assert.That()?
>
> > This is pretty weird, the overload resolution is completely different from
> > that of C#, and it tries to use the generic That method with the ref
> > modifier, which obviously requires the property to be settable publicly.
>

> > On Fri, May 15, 2009 at 18:14, Chad Kittel <chad.kit...@gmail.com> wrote:
>
> > I opened up a bug report for this issue on SourceForge and provided a
> > small example to help someone repro it.
>
> > Artifact number: 2792355
> >https://sourceforge.net/tracker/?func=detail

> > <https://sourceforge.net/tracker/?func=detail&aid=2792355&group_id=107...

[Chad Kittel]

This defect on SourceForge has been made "private" or something as I
get the following message when trying to view it...
ERROR
Artifact: This Artifact Has Been Made Private. Only Group Members Can
View Private ArtifactTypes.

Are there any updates on this issue or any reason this issue was
removed from the bug tracker?
2.5.2 experiences the same issue, meaning we are still suck in 2.4.x
land. A few colleagues of mine at another VB.Net shop are
experiencing the same issue, holding them back from upgrading as well.

--
_
(\o/) Chad 'v3rt1g0' Kittel <chad....@gmail.com>
/_\ Beaver Dam, WI (USA) [4 8 15 16 23 42]
"This is who we are." // http://twitter.com/ckittel

[Chad Kittel]

On Wed, Aug 19, 2009 at 11:25 AM, Chad Kittel<chad....@gmail.com> wrote:
> This defect on SourceForge has been made "private" or something as I
> get the following message when trying to view it...
> ERROR
> Artifact: This Artifact Has Been Made Private. Only Group Members Can
> View Private ArtifactTypes.

I meant to include the fact that I checked out LP's bug list first to
see if it was just migrated over as it is a 2.5.x bug and not a 2.4.x
one.

[Charlie Poole]

Hi Chad,

The SF bug list was made private to prevent new bugs from
being filed while the bug list is being migrated to Launchpad.

It turns out this may is not as simple as I had thought, so
we may have to do something else - like simply retype the
3.0 bugs. I'll post more on that issue today.

Regarding the bug itself, there is nothing new. The 2.5.2
release was done only to mark the end of our use of CVS
for the source and included those things that were ready
at the time.

I'll try to check this out further. Unfortunately, few folks
want to work on NUnit bugs from a VB perspective, so VB-only
bugs get short shrift. If someone is interested, please
let me know.

Charlie