Originally posted
here.
I spoke at the Beantown .NET user group meeting tonight, on the topic of SQLCLR in SQL Server 2005.
One of the questions that came up during the UDT part of the talk was
whether static properties are supported. Unfortunately, I had no
answer at the time--it's not something I'd yet thought to try.
The answer, as it turns out, is yes: they are supported. But they must be defined as
readonly, e.g.:
public static readonly int foo;
As it turns out, this means that they can also only be initialized from a
static constructor:
static myType()
{
foo = 1;
}
... which means that value will stick around from the time the type
is first used, until the AppDomain is reset (for example, if SQL Server
is restarted).
In my opinion, this greatly limits many use cases. One might, I
suppose, have some expensive, yet rarely-modified data to initialize
the member with, and get that data on the first pass only. However, if
the data does chang, I'm not sure that it would be easy to reset the
AppDomain. Do you really want to restart SQL Server in
production environments to update static members?
Another use case I can think of is logging. Perhaps there are
situations in which you'd want to log the first time a type is used.
But that doesn't seem incredibly interesting.
If someone else reading has a more compelling use case, I'd be interested in hearing it!