CS0617: read-write attribute properties

[Jens Thiel]

Hi,

is there a reason for C# to require attribute arguments (properties) to be
read-write while VB and C++ are happy with only a setter?

Simplified Example:

public sealed class FooAttribute : Attribute
{
private string s;
public string Data { set { s = value; } };
}
[Foo(Data="bar")] won't work in C#, but in VB.NET and C++.

Jens.

--
http://ManagedXLL.net/ | http://jens-thiel.de/ | http://QuantLib.net/
Replace MSDN with my first name when replying to my email address!

[Nicholas Paldino [.NET/C# MVP]]

Jens,

I believe it's an attempt on the part of the designers of the language
to enforce good design (the thinking being when would you write a value and
not be able to read it?).

Hope this helps.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"Jens Thiel" <MS**@Thiel.de> wrote in message
news:uX**************@tk2msftngp13.phx.gbl...

Hi,

is there a reason for C# to require attribute arguments (properties) to be
read-write while VB and C++ are happy with only a setter?

Simplified Example:

public sealed class FooAttribute : Attribute
{
private string s;
public string Data { set { s = value; } };
}
[Foo(Data="bar")] won't work in C#, but in VB.NET and C++.

Jens.

--
http://ManagedXLL.net/ | http://jens-thiel.de/ | http://QuantLib.net/
Replace MSDN with my first name when replying to my email address!

[Jens Thiel]

Well,

isn't it my part to decide how I retrieve something from an attribute? In
this case, it's an int[] array, which was also the original design until it
turned out that the current VB.NET can't handle array attribute properties.

I think that this is an unnecessary design restriction, and both the VB and
C++ teams didn't follow this. Do you know a way to suggest this to the
"language designers"?

Jens.

--
http://ManagedXLL.net/ | http://jens-thiel.de/ | http://QuantLib.net/
Replace MSDN with my first name when replying to my email address!
"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard.caspershouse.com> wrote in
message news:Oj**************@TK2MSFTNGP10.phx.gbl...

Jens,

I believe it's an attempt on the part of the designers of the language
to enforce good design (the thinking being when would you write a value and not be able to read it?).

Hope this helps.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"Jens Thiel" <MS**@Thiel.de> wrote in message
news:uX**************@tk2msftngp13.phx.gbl...

Hi,

is there a reason for C# to require attribute arguments (properties) to be read-write while VB and C++ are happy with only a setter?

Simplified Example:

public sealed class FooAttribute : Attribute
{
private string s;
public string Data { set { s = value; } };
}
[Foo(Data="bar")] won't work in C#, but in VB.NET and C++.

Jens.

--
http://ManagedXLL.net/ | http://jens-thiel.de/ | http://QuantLib.net/ Replace MSDN with my first name when replying to my email address!

[Andy Gaskell]

http://msdn.microsoft.com/vcsharp/te...k/default.aspx

Have you considered using the constructor of the attribute to pass in your
array?

"Jens Thiel" <MS**@Thiel.de> wrote in message
news:OP**************@TK2MSFTNGP09.phx.gbl...

Well,

isn't it my part to decide how I retrieve something from an attribute? In
this case, it's an int[] array, which was also the original design until it turned out that the current VB.NET can't handle array attribute properties.
I think that this is an unnecessary design restriction, and both the VB and C++ teams didn't follow this. Do you know a way to suggest this to the
"language designers"?

Jens.

--
http://ManagedXLL.net/ | http://jens-thiel.de/ | http://QuantLib.net/
Replace MSDN with my first name when replying to my email address!
"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard.caspershouse.com> wrote in message news:Oj**************@TK2MSFTNGP10.phx.gbl...

Jens,

I believe it's an attempt on the part of the designers of the language

to enforce good design (the thinking being when would you write a value and

not be able to read it?).

Hope this helps.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"Jens Thiel" <MS**@Thiel.de> wrote in message
news:uX**************@tk2msftngp13.phx.gbl...

Hi,

is there a reason for C# to require attribute arguments (properties)

to be read-write while VB and C++ are happy with only a setter?

Simplified Example:

public sealed class FooAttribute : Attribute
{
private string s;
public string Data { set { s = value; } };
}
[Foo(Data="bar")] won't work in C#, but in VB.NET and C++.

Jens.

--
http://ManagedXLL.net/ | http://jens-thiel.de/ | http://QuantLib.net/ Replace MSDN with my first name when replying to my email address!

[Andy Gaskell]

Oh, and you might want to checkout this video before sending feedback :)
(he's the guy you'll be emailing)

http://channel9.msdn.com/ShowPost.aspx?PostID=6186

"Andy Gaskell" <pubb AT hotmail DOT com> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl...

http://msdn.microsoft.com/vcsharp/te...k/default.aspx

Have you considered using the constructor of the attribute to pass in your
array?

"Jens Thiel" <MS**@Thiel.de> wrote in message
news:OP**************@TK2MSFTNGP09.phx.gbl...

Well,

isn't it my part to decide how I retrieve something from an attribute? In

this case, it's an int[] array, which was also the original design until

it

turned out that the current VB.NET can't handle array attribute

properties.

I think that this is an unnecessary design restriction, and both the VB

and

C++ teams didn't follow this. Do you know a way to suggest this to the
"language designers"?

Jens.

--
http://ManagedXLL.net/ | http://jens-thiel.de/ | http://QuantLib.net/ Replace MSDN with my first name when replying to my email address!
"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard.caspershouse.com> wrote

in

message news:Oj**************@TK2MSFTNGP10.phx.gbl...

Jens,

I believe it's an attempt on the part of the designers of the language to enforce good design (the thinking being when would you write a

value and

not be able to read it?).

Hope this helps.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"Jens Thiel" <MS**@Thiel.de> wrote in message
news:uX**************@tk2msftngp13.phx.gbl...
> Hi,
>
> is there a reason for C# to require attribute arguments (properties)

to

be

> read-write while VB and C++ are happy with only a setter?
>
> Simplified Example:
>
> public sealed class FooAttribute : Attribute
> {
> private string s;
> public string Data { set { s = value; } };
> }
>
>
> [Foo(Data="bar")] won't work in C#, but in VB.NET and C++.
>
> Jens.
>
> --
> http://ManagedXLL.net/ | http://jens-thiel.de/ |

http://QuantLib.net/

> Replace MSDN with my first name when replying to my email address!
>
>

[Jens Thiel]

"Andy Gaskell" <pubb AT hotmail DOT com> wrote

http://msdn.microsoft.com/vcsharp/te...k/default.aspx

Have you considered using the constructor of the attribute to pass in your
array?

Yes, but I didn't check if this works with VB.NET. I need two of these
properties, min and max array lengths in multiple dimensions, both of them
optional. I now use a string "slices x rows x columns" (which is splitted
and parsed internally) and provide a dummy getter for C#.

Will check out the ask.... link and the video tomorrow. Thanks.

Jens.

--
http://ManagedXLL.net/
Replace MSDN with my first name when replying to my email address!

[Jeffrey Tan[MSFT]]

Hi Andy,

Based on my understanding, you want to pass int array into attribute.

As I tried, this can be done in C#, but it seems that it will result in
error in VB.net. I will spend some time on this issue to find the reason
for you.

Thanks for your understanding.

Best regards,
Jeffrey Tan
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.

[Jens Thiel]

""Jeffrey Tan[MSFT]"" <v-*****@online.microsoft.com> wrote

Hi Andy,

Based on my understanding, you want to pass int array into attribute.

As I tried, this can be done in C#, but it seems that it will result in
error in VB.net. I will spend some time on this issue to find the reason
for you.

Hi Jeffrey,

it's me, Jens, who asked the original question. I know that it can be done
in C#, but it is not supported in VB.NET (see the specs on attribute
properties). I heard that the Whidbey release will support it but I can't
tell my customers to wait that long. I already replaced the int[] with a
string that is parsed into an array internally.

The original topic was the CS0617 that you get when you try to set a
write-only property (see example in original post). I think it is an
unnecessary restriction to demand that an attribute property is read-write -
at least I can not see a reason why it is forced by C#, while VB.NET and
C++.NET are happy without it.

As Andy suggested, I emailed Eric Gunnerson. Don't know if he has time to
read his emails though. My suggestion would be to relax the "read-write
attribute property" requirement in a future release.

I'm otherwise happy and do not require a solution or workaround.

Jens.

--
http://ManagedXLL.net/
Replace MSDN with my first name when replying to my email address!

[Jeffrey Tan[MSFT]]

Hi Jens,

Thanks for your feedback.

Yes, VB.net can not do this, I think this is the limitation of the
language.

For your originally concern of needing read-write property for attribute in
C# language, I will help you forword this to the our product group.

Thank you for your patience and cooperation. If you have any questions or
concerns, please feel free to post it in the group. I am standing by to be
of assistance.

Best regards,
Jeffrey Tan
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.

[Jeffrey Tan[MSFT]]

Hi Jens,

I have got a reply from Eric Gunnerson, the PROGRAM MANAGER of Visual C#.

As he said, It's a deliberate choice.
http://blogs.msdn.com/csharpfaq/arch...11/130236.aspx

But, I think this does not resolve the write-only problem. I have consulted
him for write-only property issue. Thanks

Best regards,
Jeffrey Tan
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.

[Jens Thiel]

""Jeffrey Tan[MSFT]"" <v-*****@online.microsoft.com> wrote

I have got a reply from Eric Gunnerson, the PROGRAM MANAGER of Visual C#.

As he said, It's a deliberate choice.
http://blogs.msdn.com/csharpfaq/arch...11/130236.aspx

But, I think this does not resolve the write-only problem. I have consulted him for write-only property issue. Thanks

Thanks Jeffrey, as I mentioned in my previous post I had already contacted
Eric on this. I received his blog link, but it's a misinterpration of the
issue. Eric is already aware of it.

Jens.
--
http://ManagedXLL.net/
Replace MSDN with my first name when replying to my email address!

[Jeffrey Tan[MSFT]]

Hi Jens,

Yes, that blog article only talks about the read-only issue, which did not
resolve write-only issue. So I contacted Eric for the write-only property
issue.

Today, I got the feedback from him, that is:
"In general, I'd expect that most attribute classes are just containers for
information and don't have any real logic in them, and that's why the
design is the way it is."

So the answer for this issue is that: This is an expected behavior, the
Visual C# development team choose this type of design.

Also, I have asked Eric about why VB.net allow write-only property. The
answer is these 2 languages are developed by different teams, and VB.net
team just choose another different design for it.

I hope all these makes sense to you. But if you still have any concern,
please feel free to feedback here, I will assist you.

Best regards,
Jeffrey Tan
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.

[Jeffrey Tan[MSFT]]

Hi Jens,

Does my reply make sense to you? Do you still have concern on this issue?

Please feel free to feedback. Thanks

Best regards,
Jeffrey Tan
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.