Answer.

In Visual Basic, a property can be declared in two ways:

• Full property (with custom Get/Set blocks): allows controlling data access, performing additional checks or actions when reading/writing values.
• Auto-implemented property: a shorthand where Get/Set are not written explicitly, and a private field is created automatically:

' Auto-implemented property
Public Property Name As String

' Full property
Private _age As Integer
Public Property Age As Integer
    Get
        Return _age
    End Get
    Set(value As Integer)
        If value < 0 Then Throw New ArgumentException("Age can't be negative")
        _age = value
    End Set
End Property

Nuances when using Set:

• The Value keyword is a pseudo-variable that refers to the assigned value.
• Inside Set, you can perform validation, logging, or trigger events.
• Changing the anonymous field in auto-implemented properties cannot be controlled.

When to use:

• Auto-implemented properties — when a simple "container" is needed.
• Full properties — when setting/getting requires logic (validation, notification, calculations).

Trick question.

What are the consequences of writing Set(ByVal value As Integer) instead of Set(value As Integer) in VB.NET? Why is it not advisable to do this?

Answer: VB.NET syntax does not require (and does not support) declaring the ByVal parameter explicitly in Set — simply use Set(value As Type). If you write Set(ByVal value As Integer), it will result in a compilation error.

Example of erroneous code:

'Set(ByVal value As Integer) — compilation error
Public Property Prop As Integer
    Set(ByVal value As Integer)
        ...
    End Set
End Property

In classic VB6, such syntax was permissible, but in VB.NET it strictly requires Set(value As Type).

---

History

In a large project during the auto-migration of code from VB6 to VB.NET, ByVal was incorrectly placed in Set — the compiler issued cryptic errors that were difficult to localize because the linter did not show a clear cause.

History

In a project handling large datasets, auto-implemented properties were used to store data, and then a problem arose: it was necessary to track whether a property was changing to automatically log each change. It became necessary to switch from auto-properties to full ones — as a result, a lot of time was lost on refactoring, as it was initially not considered that additional logic might be needed in Set.

History

While copying reference-type objects through auto-implemented properties, deep copy was forgotten to be implemented through Get/Set. As a result, duplications of references to the same object were obtained; changing one instance led to changes in another.