0

I am creating a custom C# Windows Forms control library (a DLL) in Visual Studio 2019 (Professional). My control has a property that takes the following form (this property is aimed to be accessed by applications which use the DLL):

public double Hello
{
    get { throw new ApplicationException("Hi!"); }
}

(In my efforts to find out why this is happening, I've simplified the property to just throw an exception and do nothing else.)

For some reason, if I run my User Control (in Debug mode), the exception is raised - even though nowhere else in this code calls that property! (The IDE confirms this - saying "0 references" above it). Why does the property "get" accessor seem to be called for no reason? The stack trace shows that the "get" was called by "[External code]"...

This should be pretty easy to reproduce if you have Visual Studio 2019: create a new "Windows Forms Control Library (.NET Framework)" project under C#, then right click on "UserControl1.cs" in the Solution Explorer and click "View Code", then just add in the above code to the class.

PersonWithName
  • 848
  • 2
  • 13
  • 19
  • 3
    I expect the "properties" window uses it. If that's the case, maybe [this is the answer](https://stackoverflow.com/a/1528424/3181933). – ProgrammingLlama Jan 17 '20 at 04:22
  • Ahhhh. Interesting. The thing is that this happens even when loading the Release DLL with the external application (in my case, I'm embedding the control into LabView). I can't see any reason why LabView would need to know all the property values as soon as the DLL is loaded, but it's probably something outside my control. I was thinking it could be some strange quirk of C# that I wasn't aware of. – PersonWithName Jan 17 '20 at 04:25
  • 1
    It shouldn't throw if the property definition is the one you're showing and nothing else. In any case. It could throw if you have a custom Designer that accesses/initializes the default property values of the UC, for example. Or the property is evaluated by reflection. – Jimi Jan 17 '20 at 04:50
  • Yeah, the weird thing is that LabVIEW (which you may not know anything about) seems to query the property as soon as I try to drop my .NET widget into the project - even before I try to run it. Don't know what LabVIEW is doing here but I can't change it (if I had a choice I wouldn't be using it in the first place...). I've just opted to change my properties to getter/setter methods instead. – PersonWithName Jan 17 '20 at 06:50

1 Answers1

1

I have reproduced your problem. Based on my test, I find that winformscontrollibary will

load all the properties you set in the code, because it needs to load them into the

property bar of form. Like the following, if you write the following code.

 public partial class UserControl1: UserControl
    {
        public UserControl1()
        {
            InitializeComponent();
        }
        public double Hello
        {
            get { return 1.02; }

        }
        public int Number
        {
            get { return 1; }

        }

    }

You will see the correct property(Hello and Number) in the right of form. enter image description here

Therefore, if you write the code throw new ApplicationException("Hi!"); in the get method , it will throw the exception.

Jack J Jun
  • 5,633
  • 1
  • 9
  • 27
  • Yeah the primary problem for me is that this still happens even outside of Visual Studio when I use it with LabVIEW (even without running it) - I've just opted to use getter/setter methods instead. It honestly makes more sense than using properties (imo) in this case since the getter/setters are reading/writing over a TCP/IP socket. – PersonWithName Jan 17 '20 at 06:52
  • I am not familiar with labview, so I don't know how does it use with winformcontrol library. Like I mentioned before, the reason why it call the property is that the dll need to load all the properties. – Jack J Jun Jan 17 '20 at 07:19