I was gently trying to suggest that there is fundamentally no way to do what
you're asking for.

First of all, please define "property wasn't set". Do you mean "property
wasn't set during initialization"? If so, define "initialization", realizing
that you have to define it in a way that you can explain to a compiler.
You'll also have to make the decision to rule out "setting" the property by
some method which is not "initialization".

This would be interesting, since any definition of run-time initialization
is going to have to be understood by the compiler in compile-time terms. For
instance, if you defined "initialization" as "set by an unconditional
statement in the InitializeComponent method", then the compiler could
understand that. It could generate a (hidden) try-catch-finally block around
the InitializeComponent method and check to see if the property had been
"set".

My advice is to punt on this until you find that some other piece of code
has done this.  You really are mistaken about the inherent difficulty in
this.

John

Things are different today than they were 30 years ago when I learned the
difference between compile-time and run-time, so I gave this some more
thought.

The one situation in which I know of a compiler having anything at all to do
with something we typically thing of as runtime is in the case of attributes
in .NET.  When we do something like the following:

[WebService]
public class SomeService
{
}

then we find something like the following in the IL:

 .custom instance void
[System.Web.Services]System.Web.Services.WebServiceAttribute::.ctor() = (
... )

So, I tried placing a throw new Exception("Boom!")  in the constructor of an
attribute I use. No boom.

Are you sure you didn't see these license things happen at design-time and
not runtime?

I suggest you limit yourself to runtime validation of property values. See
the ISupportInitialization interface in the documentation.

John