VB -> C#: Explicit interface implementation adds a setter for readonly property.

[Yozer]

VB.Net input code

Public Interface IUser
    ReadOnly Property Username As String
End Interface

Public Class User
    Implements IUser

    Public Property Nick As String Implements IUser.Username
        Get
            Throw New NotImplementedException
        End Get
        Set
            Throw New NotImplementedException
        End Set
    End Property

End Class

Erroneous output

    public interface IUser
    {
        string Username { get; }
    }

    public class User : IUser
    {
        string IUser.Username
        {
            get
            {
                throw new NotImplementedException();
            }

            set
            {
                throw new NotImplementedException();
            }
        }

        public string Nick { get => ((IUser)this).Username; set => ((IUser)this).Username = value; }
    }

    static class Module1
    {
        public static void Main()
        {
            var test1 = "" ?? () => 5;
            var test2 = () => 4 ?? () => 5;
        }
    }

Expected output

    public interface IUser
    {
        string Username { get; }
    }

    public class User : IUser
    {
        public string Nick
        {
            get
            {
                throw new NotImplementedException();
            }

            set
            {
                throw new NotImplementedException();
            }
        }

        string IUser.Username => Nick;
    }

Details

• Product in use: VS extension
• Version in use: 8.4.4.0
• Did you see it working in a previous version, which?
• Any other relevant information to the issue, or your interest in contributing a fix.

Could the fix be to always keep the getter/setter in a class property and just generate delegate calls from all explicit interface implementations?

[GrahamTheCoder]

Your suggestion might well work. To figure it out, it might be best to check the decompilation in SharpLab.
It needs to still do the right thing when someone overrides the method, and when someone uses an _ to directly write to the underlying field (if that's possible in this case)

See the slightly related #685

[GrahamTheCoder]

From a quick look:

• SharpLap doesn't accurately decompile the code
  • I believe this is a bug in ILSpy which it's using, because the IL can't be directly represented in C#, arguably it's doing the best it can, but a warning of non-translatable IL might have been nice
• It looks like the underscore syntax doesn't work for this case (presumably since it's not an auto-implemented property within the class - phew)

The way I'd expect overriding Username to work is that Nick's behaviour wouldn't change. So actually it sounds like flipping it around like you suggest would be an improvement there. That said, it's definitely worth a test.

There are some self verifying test cases in the converter which we could add an example to (they are executed in VB, then converted and executed again):
https://github.com/icsharpcode/CodeConverter/blob/master/Tests/TestData/SelfVerifyingTests/VBToCS/InheritanceTests.vb

[Yozer]

I'm slowly starting to look into this, first, there is a small code cleanup around the visitors in #821
What I found is that the current way of generating explicit implementations can change the application logic.
You can find a self-verifying test (currently failing) for it in #822

If this property
Protected Overridable Property Nick As String Implements IUser.Username
is overridden in a deriving class then it also changes the behavior of IUser.Username.

After conversion:

string IUser.Username { get { logic }  set { logic } }
protected virtual string Nick { get => ((IUser)this).Username; set => ((IUser)this).Username = value; }

Because the converter keeps the logic in the first explicit interface implementation it means that logic IUser.Username will never change and this isn't how vb.net works