I need to have the same attribute on properties of different classes, e.g. :
[Display( Name = "Last Name" )]
is there a way not to copy paste the same line on different classes/interfaces? instead have a construct that refers to that line and copy paste the reference everywhere instead?
You probably will find AOP helpfull. Search for best framework yourself.
you could create a script in something simple like ruby or powershell to add in that line in the same place on every page, or to add it after a regex match. A simpler method would be to create a parent class and have every class you want to implement this attribute extend the parent class.
If you end up needing to make the same change in so many places that copy and pasting is too much work, then you should look at your project and try to decide if a relationship exists there or if there truly are that many unrelated fields that end up having the same value
I ended up using a constant instead:
[Display( Name = Constants.LastName )]
where Constants.LastName = "Last Name" ); is a defined string constant.
Related
I have a background in C++ and recently I started working in C#.
I have written following pieces of code (in Visual Studio):
var list_Loads = database.GetData<Load>().ToList();
var test_list = list_Loads.Where(o => (o.Name.Substring(0, 3) == "123")).ToList();
When I run the program and I move my mouse over both lists, first I get the count, which is very useful, but when I ask for the entries, this is what I get:
0 : namespace.Load
1 : namespace.Load
2 : namespace.Load
...
Not very useful, as you can imagine :-)
So my question: how can I show the Name attributes of those objects?
I thought: no problem. I have a background in native visualisers, so it should be rather easy to turn this into useful information, but then it comes:
In order to alter the way that those objects are represented, there is the first proposal to add a [DebuggerDisplay] "tag" to the definition of that class in source code.
However, as those classes are part of a framework I'm just referring to, I don't have access to the source code and hence I can't modify this.
Then I found another solution, which comes down to: "Write an entire C# project, debug, test and install it and it might work" (see documentation on "Custom visualisers of data" on the Microsoft website).
I almost choked in my coffee: writing an entire project, just for altering the view of an object??? (While, in C++, you just create a simple .natvis file, mention the classname and some configuration, launch .nvload and that's it.
Does anybody know a simple way to alter the appearance of C# object, without needing to pass through the whole burden of creating an entire C# project?
By the way, when I try to load a natvis file in Visual Studio immediate window, this is what I get:
.nvload "C:\Temp_Folder\test.natvis"
error CS1525: Invalid expression term '.'
What am I doing wrong?
Thanks in advance
OP (my emphasis):
In order to alter the way that those objects are represented, there is the first proposal to add a [DebuggerDisplay] "tag" to the definition of that class in source code.
However, as those classes are part of a framework I'm just referring to, I don't have access to the source code and hence I can't modify this.
Does anybody know a simple way to alter the appearance of C# object, without needing to pass through the whole burden of creating an entire C# project?
If you just want to specify [DebuggerDisplay] on a type, you don't have to have access to the source code. You can make use of [assembly:DebuggerDisplay()] and control how a type appears in the debugger. The only downside is that [assembly:DebuggerDisplay()] naturally only affects the current assembly whose code your mouse is hovering over. If you wish to use the customised display in other assemblies that you own, then you must repeat the [assembly:DebuggerDisplay()] definition.
Here's an easy before-and-after example with DateTime. I picked DateTime because we generally don't have access to the source code and it has some interesting properties:
var items = new List<DateTime>
{
DateTime.Now.AddDays(-2),
DateTime.Now.AddDays(-1),
DateTime.Now
};
...which on my machine defaults to:
Maybe I'm fussy and I just want to see:
Day of the week and
Day of the year
...I can do that via:
using System.Diagnostics;
[assembly: DebuggerDisplay("{DayOfWeek} {DayOfYear}", Target = typeof(DateTime))]
...which results in:
Example:
namespace DebuggerDisplayTests
{
public class DebuggerDisplayTests
{
public DebuggerDisplayTests()
{
var items = new List<DateTime>
{
DateTime.Now.AddDays(-2),
DateTime.Now.AddDays(-1),
DateTime.Now
};
}
}
.
.
.
}
Overrides
[assembly:DebuggerDisplay()] can also be used as a means to override pre-existing [DebuggerDisplay] on a 3-rd party type. Don't like what style they have chosen? Is the type showing far too much information? Change it with [assembly:DebuggerDisplay()].
I have defined attribute MyAttribute : Attribute that is supposed to be used exactly once within a class (only one constructor per class may have it and it can appear only once on ctor’s attribute list).
I have created a Roslyn analyzer to check this which marks every usage of such attribute (if used more than once) and allows user to pick fixture called "Leave this attribute occurrence and delete all others".
Now within FixProvider I need to return new modified Solution. It's not difficult to modify every Document that requires the fix (by using SyntaxRewriter to modify SyntaxTree inside). However, I have no idea how to modify Solution or Project - they don't have any method like "ReplaceProject"/"ReplaceDocument".
How to do that?
You could replace the text of a document using the following method:
solution = solution.WithDocumentText(currentDocument.Id,
currentDocumentSyntaxTree.GetText());
I have already searched here to answer my question, and the closest I ever got was that post, but it still does not completely clarify the matter to me, so I will ask.
What I need is extending maxlengthattribute in the way that when I set it inside the C# file,
[MaxLength(50)]
[Display(Name = "Project Description")]
public string ProjectDescription { get; set; }
the attribute "maxlength" will be added inside the tag and will be <\stuff stuff maxlength = "50">
I have initially implemented it as writing html-helper to modify TextBoxFor, however, this is out of option since project is tightly intertwined with .js, and inserting renamed method will break a code, which will be a pain to fix.
The answer I referred above provides the closest explanation of what I need, but it looks like I will need to declare attributes (like inside ( ) in function), which I do not see there.
At this point I can either try modifying JS file on the server-side, or extending maxlengthattribute. Thus far, latter is preferable for me, thus I would like to ask how to properly extend it inside the c# file.
Thank you very much in advance!
You can write a custom dataannotation provider. The max length attribute will get added to the control.
Refer this link
Is there a compelling reason to change a generic class name, as "inherited" from a Project Templete? I have this code in my new project, which was created from a (self-created) template:
// REPLACE: Change the name of this class, if desired, to something like "<formName>VisualWebPart"
public partial class VisualWebPart : UserControl
IOW, the comment is mine, but now I wonder: do I really need to change "VisualWebPart" to "DPlatypuswebPart" or so? It won't really make any difference if the Sharepoint site has multiple disparate pages with the same class name, will it? Or will it?
As to the argument for clarity ("which VisualWebPart?!?"), all the coder (me, probably) has to do is to cast his peepers up a few degrees to see the Solution name or the namespace, which are unique.
Note: My preference (if feasible) to just use the same class name in every project derived from the Project Template is for simplicity's sake: so I don't have to do a global search-and-replace, and possibly have some "invisible"/behind-the-scenes files that reference this name not get updated. IOW, I'm shaking in my coding booties that I may open a rat's nest or can of worms by getting too persnickety about names.
OTOH, I'm afraid that not changing the name could end up problematic. Which fear is (most) justified?
Between these two:
With Property:
class WithProperty
{
public string MyString {get; set;}
}
With Field:
class WithField
{
public string MyString;
}
Apparently I'm supposed to pick the first one. Why?
I've heard the argument that the point here is to allow interface changes, but
if I have the second one, and change it to the first one, no other code should
ever have to change. When recompiled everything's just going to point to the
property instead.
Am I missing something important here?
The most important difference is the fact, that if you use a field, and later need to change it to a property (say, to enforce some validation), then all libraries calling your code will need to be recompiled. It's true that you can compile the exact same code if the name stays the same - but the consumers of your code will still need to be recompiled. This is because the IL generated to get the value is different between a field and a property. If it already is a property, you can make a change without forcing consumers of your code to change.
This may or may not be an issue for you. But the property is almost the same amount of code, and is considered best practice. I would always go for the property.
The property can be changed later if you need to add validation or other logic without breaking other assemblies.
Also, the property can be used with databinding.
The important part you are missing is the gravity of this statement:
When recompiled
When your code point to a field and you change it to point to a property of the same name, the C# itself doesn't change, but the resulting IL does - it generates a method call to the getter or setter as appropriate.
Not every app has all of it's pieces contained in a single distributed unit. Many apps rely on interfaces for pluggability/expandability. If you have an app with an interface to a field and you want to change it to a property to take advantage of the power of properties, the app has to be recompiled and redistributed. You might as well just make it a property in the first place.
With a property, you can easily extend it to include new logic.
For example, if you need to add validation logic to the set.
This article goes into several additional reasons why you should prefer properties:
http://csharpindepth.com/Articles/Chapter8/PropertiesMatter.aspx