How can I use a static Guid as argument in an attribute?
static class X
{
public static readonly Guid XyId = new Guid("---");
}
[MyAttribute(X.XyId)] // does not work
public class myClass
{
}
It does not work because Guid must be readonly, it can not be const. The string and byte[] representation would also be readonly.
Is there any workaround for this?
It's not possible and will never be possible, because [Attributes] are compiled as metadata and static variables are initialized at runtime, and of course the former cannot access the latter (except via Reflection).
If the standard
public const string MyGuid = "blah";
won't work for you, then AFAIK the only way to achieve what you want, is with Reflection.
Unfortunately there is no a good way to pass Guid to attribute.
Only workaround would be to use another type for that and convert it to Guid.
Related
Is there any difference between the following?
class C
{
// One:
public static readonly int ValueAsAMember = 42;
// Two:
public static int ValueAsAProperty { get { return 42; } }
}
I'm used to writing constants the first way (unless they're private/internal, in which case I use the const keyword), but I recently saw the second form.
Is there any advantage one way over the other in terms of readability, convention, performance, or anything else?
You have three choices:
public static readonly int Value = 42;
public static int Value { get { return 42; } }
public const int Value = 42;
Choose static readonly if the value will not change at runtime but might change in future versions of your code.
Choose a property if the value might change at runtime. Of course it won't change if you use the given code.
Choose const if the value is really a constant that will not even change in future versions (something like Math.PI or int.MinValue). And of course the use of const is limited by the type of the value.
The difference between const and static readonly is that the const value will be replaced on the call site. If you change the value of a const in a future version then all assemblies that rely on your class need to be recompiled using the new value.
The property requires a method call (calling a getter is a method call). So if the value is constant at runtime there is no need for that.
Yes, there is an advantage:
If the value gets changeable at any point in the future (e.g. in a future version of your code), in a way that it is, for example, time-dependent, you can support that in the read-only property without changing the public interface of your class.
If you have to replace a readonly field with a property, you will have to recompile any other assemblies that use your class.
There are two major differences:
The first is that fields cannot be on interfaces, whereas properties can. So if you want to use this in an interface, you have to use the property.
The second, more interesting, is that readonly fields CAN be modified, while the object is being constructed. Take the following code:
public class MyTestClass
{
public readonly int MyInt = 1;
public MyTestClass()
{
MyInt = 2;
}
}
If a caller does
new MyTestClass().MyInt
they will get 2. The same goes for static constructors for a static readonly field.
The way I see it, using the first way describes the intention of the value better - which is that it is immutable. When a person is looking at the class' interface, he will see that the value is read-only, and won't have to wonder whether it can be changed later (since in the second case he can't see the property's implementation).
An important thing to note about const declarations (I don't believe it's true for readonly) is that changing the field's value constitutes an API change, even if you're just changing the value from 42 to 41. The reason is that for consts, the value is determined during compile time, which means that if I compile a module that uses your constant, and you later change it, I will still be using the old value until I recompile my module with your new version.
readonly is nice to use on things that can only be changed in your constructor. Examples of this is typical services as interfaces when you are following the TDD pattern.
In your example const is best, it's a constant after all.
readonly
const
Cheers
I think the first line making something constant or rather readonly using readonly keyword.
and the second line is making use of a property to implement readonly. Both do the same but if you compare with the IL the property would add few extra lines of code to the dll.
The main advantage for me is with readonly you are allowed to declare it anywhere in your code. But, you will get a chance to set it only once. With the setter, you declare and set in one stroke.
Yes, there's a difference between the two.
A readonly field can only be set in the constructor.
A {get; private set;} can be set at anytime from within the class.
Example:
public class Car
{
public readonly string Name;
public string color {get; private set;}
public Car()
{
Name = "Car";
Color = "Red";
}
// will fail compilation
public void ModifyName()
{
Name = "Subaru"
}
// perfectly ok
public void ModifyColor()
{
Color = "Green"
}
}
A Property is just syntactic sugar around a field, a property without a setter is simply declared a readonly field so the compiler will allow you to set it at runtime in the constructor, because to the compiler you are referencing a readonly field. There is a larger discussion around what to use a field or property, which is not within the scope of the question. And yes its this syntactic sugar that you have to do the recompiling referenced by #SOreadytohelp. Just to be clear a property is a field with a get and set method created for it, C# will allow you to reference it like a field rather than doing an annoying call to the getter or setter everytime.
Is there some way to specify the type of the enclosing class declaration statically? If i had an instance, I could clearly use typeof(this), but statically I don't see a way.
Something like (where this_type is a placeholder):
public class Message
{
public static readonly int SizeInBytes = Marshal.SizeOf(typeof(this_type));
}
Clearly, I could just use the actual type name, but I've got several classes that follow this pattern and would like something less copy/paste error prone.
You can use MethodBase.GetCurrentMethod().DeclaringType but typeof(Message) is probably the cleaner way
public class Message
{
public static readonly int SizeInBytes = Marshal.SizeOf(MethodBase.GetCurrentMethod().DeclaringType);
}
Btw, you'll get a runtime exception when you execute this code as it is trying to get the size of a managed object.
typeof(Message) would be the closest you'd get here, but I think you'd need to use a struct rather than a class to do this from what I recall.
Perhaps:
public class Message
{
public static readonly int SizeInBytes = Marshal.SizeOf(typeof(Message));
}
This way, 'Message' can also be static.
What about an extension method on the type and get it dynamically instead of pushing it to a readonly static variable?
public static class Extensions
{
public static int SizeOfType(this System.Type tp) {
return Marshal.SizeOf(tp);
}
public static int SizeOfObjectType(this object obj) {
return obj.GetType().SizeOfType();
}
}
// calling it from a method, 2 ways
var size1 = this.GetType().SizeOfType();
var size2 = this.SizeOfObjectType();
var size3 = typeof(string).SizeOfType();
var size4 = "what is my type size".SizeOfObjectType();
After a short google search, I've seen other people using reflection to accomplish what you are talking about, but that comes with the caveat that it is probably a lot more expensive than just typing out typeof(this_type). I'd sooner recommend just typing it out.
Type t = MethodBase.GetCurrentMethod().DeclaringType
.NET: Determine the type of “this” class in its static method
Is there any difference between the following?
class C
{
// One:
public static readonly int ValueAsAMember = 42;
// Two:
public static int ValueAsAProperty { get { return 42; } }
}
I'm used to writing constants the first way (unless they're private/internal, in which case I use the const keyword), but I recently saw the second form.
Is there any advantage one way over the other in terms of readability, convention, performance, or anything else?
You have three choices:
public static readonly int Value = 42;
public static int Value { get { return 42; } }
public const int Value = 42;
Choose static readonly if the value will not change at runtime but might change in future versions of your code.
Choose a property if the value might change at runtime. Of course it won't change if you use the given code.
Choose const if the value is really a constant that will not even change in future versions (something like Math.PI or int.MinValue). And of course the use of const is limited by the type of the value.
The difference between const and static readonly is that the const value will be replaced on the call site. If you change the value of a const in a future version then all assemblies that rely on your class need to be recompiled using the new value.
The property requires a method call (calling a getter is a method call). So if the value is constant at runtime there is no need for that.
Yes, there is an advantage:
If the value gets changeable at any point in the future (e.g. in a future version of your code), in a way that it is, for example, time-dependent, you can support that in the read-only property without changing the public interface of your class.
If you have to replace a readonly field with a property, you will have to recompile any other assemblies that use your class.
There are two major differences:
The first is that fields cannot be on interfaces, whereas properties can. So if you want to use this in an interface, you have to use the property.
The second, more interesting, is that readonly fields CAN be modified, while the object is being constructed. Take the following code:
public class MyTestClass
{
public readonly int MyInt = 1;
public MyTestClass()
{
MyInt = 2;
}
}
If a caller does
new MyTestClass().MyInt
they will get 2. The same goes for static constructors for a static readonly field.
The way I see it, using the first way describes the intention of the value better - which is that it is immutable. When a person is looking at the class' interface, he will see that the value is read-only, and won't have to wonder whether it can be changed later (since in the second case he can't see the property's implementation).
An important thing to note about const declarations (I don't believe it's true for readonly) is that changing the field's value constitutes an API change, even if you're just changing the value from 42 to 41. The reason is that for consts, the value is determined during compile time, which means that if I compile a module that uses your constant, and you later change it, I will still be using the old value until I recompile my module with your new version.
readonly is nice to use on things that can only be changed in your constructor. Examples of this is typical services as interfaces when you are following the TDD pattern.
In your example const is best, it's a constant after all.
readonly
const
Cheers
I think the first line making something constant or rather readonly using readonly keyword.
and the second line is making use of a property to implement readonly. Both do the same but if you compare with the IL the property would add few extra lines of code to the dll.
The main advantage for me is with readonly you are allowed to declare it anywhere in your code. But, you will get a chance to set it only once. With the setter, you declare and set in one stroke.
Yes, there's a difference between the two.
A readonly field can only be set in the constructor.
A {get; private set;} can be set at anytime from within the class.
Example:
public class Car
{
public readonly string Name;
public string color {get; private set;}
public Car()
{
Name = "Car";
Color = "Red";
}
// will fail compilation
public void ModifyName()
{
Name = "Subaru"
}
// perfectly ok
public void ModifyColor()
{
Color = "Green"
}
}
A Property is just syntactic sugar around a field, a property without a setter is simply declared a readonly field so the compiler will allow you to set it at runtime in the constructor, because to the compiler you are referencing a readonly field. There is a larger discussion around what to use a field or property, which is not within the scope of the question. And yes its this syntactic sugar that you have to do the recompiling referenced by #SOreadytohelp. Just to be clear a property is a field with a get and set method created for it, C# will allow you to reference it like a field rather than doing an annoying call to the getter or setter everytime.
I just want don't use "Managers" for each attribute and use some enum for that.
But it seems it is impossible or I am wrong?
So I try to replace
[RequiresRole("Managers")]
with
[RequiresRole(HardCodedRoles.Managers.ToString())]
...
public enum HardCodedRoles
{
Administrators,
Managers
}
How about a class instead of an enum, making the class static to avoid somebody new:ing it ?
public static class HardCodedRoles
{
public const string Managers = "Managers";
public const string Administrators = "Administrators";
}
[RequiresRole(HardCodedRoles.Managers)]
You could also use the nameof keyword, i.e.:
[RequiresRole(nameof(HardCodedRoles.Managers))]
The reason you see the error is because ToString() is a method and thus the value cannot be calculated at compile time.
If you can use [RequiresRole(HardCodedRoles.Managers)] instead, you can perform the ToString elsewhere in your code, and this could give you the functionality you need. This will require that you change the parameter of your attribute from string to HardCodedRoles.
(I would imagine that using a const won't work, because the type of the parameter will still be string, so the input won't be restricted.)
Is it possible to declare a constant Guid in C#?
I understand that I can declare a static readonly Guid, but is there a syntax that allows me to write const Guid?
No. The const modifier only applies to "primitive" types (bool, int, float, double, long, decimal, short, byte) and strings. Basically anything you can declare as a literal.
Declare it as static readonly Guid rather than const Guid
public static readonly Guid Users = new Guid("5C60F693-BEF5-E011-A485-80EE7300C695");
and that's that.
While you can't seem to do that you can do that to be parsed whenever you need it:
const string _myGuidStr = "e6b86ea3-6479-48a2-b8d4-54bd6cbbdbc5";
But don't use the above guid as it belongs to me solely, I first generated it so I claim ownership on this particular guid above! But I'm generious - use this one instead (I don't like how it talks back to me but it's a nice guid overall when it keeps its mouth shut): 284c694d-d9cc-446b-9701-b391876c8394
I am doing it like this:
public static class RecordTypeIds
{
public const string USERS_TYPEID = "5C60F693-BEF5-E011-A485-80EE7300C695";
public static Guid Users { get { return new Guid(EntityTypeIds.USERS_TYPEID); } }
}
Depends on what you want a const for.
If you want to have a known GUID that you can reuse as needed, the above solution of storing the GUID as a string and parsing to GUID as needed works.
If you need a default parameter value, that won't work. The alternative is to use a nullable Guid and use null as your constant value.
public void Foo(string aParameter, Guid? anOptionalGuid = null)