Does anyone know a GUI designer for Resharper's Type Member Layout? I find that editing the XML to satisfy my wishes is cumbersome. If no GUI designer exists, can someone give me pointers as to have the following order:
1. Properties
2. Constants / Static Readonly
3. Constructors
4. Methods
5. Interface Implementations
6. Nested Types
The secondary order should be:
1. Static > Instance
2. Public Internal Protected-Internal Protected Private
This blog post should help: In-depth look at customizing type layout with ReSharper
Related
I need to model a concrete generic class inheriting from a base generic class. First, see below:
ActivityFacade should be implemented this way:
public class ActivityFacade : BaseFacade<Activity, int>
{
}
How can I model this in a VS2012 UML class diagram? Looking at the diagram, it is obvious that ActivityFacade inherits from BaseFacade, but what's not obvious is the generic type parameters that it is passing in, namely: Activity and int.
You need to add a new binding class (BaseFacade <Activity, int>) connect it to your parameterized class (BaseFacade<T, TKey>) with a template binding connector and then specialize your child class (ActivityFacade) from the binding class.
From the OMG UML specification
"A template is a parameterized element ... used to generate other model elements using TemplateBinding relationships. The template parameters for the template signature specify the formal parameters that will be substituted by actual parameters (or the default) in a binding."
UPDATE:
The diagram I included is drawn using EA. The same concept can be modeled in Visual Studio UML tool. See the section "Template types: To use a template type" in msdn.
Is there anyway to get Resharper to navigate to the concrete implementation of an generic interface for a specific type.
E.g. ICommandHandler<T> and find the concrete implementation? I can get Resharper to show all implementations of ICommandHandler but not allow me to easily get to the implementation of the type T. We have hundreds of handlers and navigating is getting slower.
We are using Resharper 7.1
Update
Examples include things like:
public class AddStockRequestLineItemCommandHandler : ICommandHandler<AddStockRequestLineItemCommand>
public class RemoveStockRequestLineItemCommandHandler : ICommandHandler<RemoveStockRequestLineItemCommand>
public class StockRequestFufillingUpdateCommandHandler : ICommandHandler<StockRequestFufilingUpdateCommand>
Usage like in MVC controller constructor like:
public StockRequestController( ICommandHandler<RemoveStockRequestLineItemCommand> stockRequestLineItemRemoveHandler)
{
this.stockRequestLineItemRemoveHandler = stockRequestLineItemRemoveHandler;
}
I'd love to be able to click on ICommandHandler<RemoveStockRequestLineItemCommand> and go to the implementing class RemoveStockRequestLineItemCommandHandler
Resharper 9.1.1 supports finding the usages of a generic interface. Right click on IComamndHandler and it will show you the usages. However, it would appear, still no way of finding implementations.
Best solution we came up with was
/// <summary>
/// <see cref="ChangePersonAddressCommandHandler"/>
/// </summary>
Using cref link http://msdn.microsoft.com/en-us/library/cc837134.aspx and template and added this above the command or in our controller.
Would love not to have to do this and just navigate straight there with Resharper
ReSharper 2016.1 RTM now supports navigating to the concrete implementation of a generic type using Ctrl+F12.
If I right click on the base object I get a context menu that offers:
Go to Implementation (Ctrl+Shift+Alt+B)
selecting that will then offer me the various derived objects (in your case the classes)
Imagine i have an extension method that operates of an interface of abstract objects:
public static void BlowTheirWhoHoovers(this ICollection<Image> source)
{
...
}
This extension knows how to blow the who hoovers of a list of images.
Note:
it's a list of Images, which is abstract. As long as the lists contain anything that descends from Image (e.g. Bitmap, Metafile, PngImage) the extension can handle it
source list can by any kind of list as long as it exposes ICollection
since source list is going to potentially have items added or removed, it is ICollection rather than IEnumeration (IEnumeration doesn't support modifying the list)
That's all well and good, except it doesn't work, the extension method is not found:
Collection<Bitmap> whoHonkers = new Collection<Bitmap>();
whoHonkers.BlowTheirWhoHoovers();
i assume this fails because:
Visual Studio doesn't think Collection implements ICollection<T>
Visual Studio doesn't think Bitmap descends from Image
Now i can change my extension:
public static void BlowTheirWhoHoovers(this Collection<Bitmap> source)
{
...
}
which does compile:
except it's no longer useful (it requires Collection, and it requires Bitmap), e.g. it fails to work on anything except Collection<T>:
List<Bitmap> whoHonkers = new List<Bitmap>();
whoHonkers.BlowTheirWhoHoovers();
It also fails on anything that it's Bitmap:
List<Metafile> whoHonkers = new List<Metafile>();
whoHonkers.BlowTheirWhoHoovers();
or
List<PngImage> whoHonkers = new List<PngImage>();
whoHonkers.BlowTheirWhoHoovers();
How can i apply an extension to anything that is:
ICollection<Image>
?
i can't force anyone to change their declaration, e.g.:
List<Bitmap>
to
Collection<Image>
Update:
Possible avenues of solution exploration:
finding the syntax that allows extensions on things that the compiler should be able to do
manually casting the list; doing the compiler's job for it
Update#2:
i could have simplified some of the distractions around ICollection, and made it IEnumerable (since it's a hypothetical example i can make up whatever i want). But the screenshots already show Collection, so i'm going to leave it as it is.
Update#3:
As foson pointed out, changing it to IEnumerable allows a way to cheat the answer. So it definitely should stay as ICollection.
Sounds like a covarient problem.
If you change the signature to
public static void BlowTheirWhoHoovers(this IEnumerable<Image> source)
you should be able to do it in .NET 4 (not SL).
The problem with varience is that if you passed into the method an ICollection<JpegImage>, the method itself wouldn't know that it could only add JpegImages and not Bitmaps, defeating type saftey. Therefore the compiler does not let you do it. IEnumerable's type parameter is covarient, as seen by the out keyword, while ICollection's type parameter is not (since it is both in return positions and method parameter positions in the ICollection interface)
public interface IEnumerable<out T>
http://msdn.microsoft.com/en-us/library/dd799517.aspx
I want to have an abstract base class for some of my custom UserControl's. The reason is obvious: they share some common properties and methods (a basic implementation of some elements of an interface actually), and I want to implement them only once.
I have done this by defining my abstract base class:
public abstract class ViewBase : UserControl, ISomeInterface
Then I went to implement one of my views, as usual, with the designer:
public partial class SpecialView : UserControl //all OK
Up to here all is fine. Now I replace the derivation of my SpecialView class with the abstract base class:
public partial class SpecialView : ViewBase //disrupts the designer
Now, the designer in Visual Studio 2008 won't work anymore, stating: The designer must create an instance of type 'ViewBase' but it cannot because the type is declared as abstract.
How can I circumvent this? I just do not want to have the same code copied for all those views.
Info: there is a question question with virtual methods, instead of abstract classes, but there is no suitable solution for me.
Instead of using abstract class, you can mark the functions virtual and override them in the inheriting classes
The best solution is here:
http://wonkitect.wordpress.com/2008/06/20/using-visual-studio-whidbey-to-design-abstract-forms/
Using it now, it's elegant and gets around the underlying problem without breaking your nice OOP design.
Try this solution from Urban Potato, which worked for me, with a strange side effect that I never really had explained, and never got a good workaround. Maybe you'll get lucky and won't have that side-effect!
One could argue that it doesn't make sense in terms of design philosophy to expect to be able to work with an abstract control in the Designer. An abstract class tends to model a type of object for which simply knowing that it's an 'X' doesn't adequately describe it - there's no such thing as an abstract Bird or Car, it's always a specific type of bird or car. Looking at it this way, if you want to view a custom control in the designer, it has to be a specific type of control rather than an abstract one, otherwise what are you looking at? I can see why it's annoying, but I can also see why the Designer was coded in this way.
0 What's the difference between the following?
public class MyClass
{
public bool MyProperty;
}
public class MyClass
{
public bool MyProperty { get; set; }
}
Is it just semantics?
Fields and properties have many differences other than semantic.
Properties can be overridden to provide different implementations in descendants.
Properties can help alleviate versioning problems. I.e. Changing a field to a property in a library requires a recompile of anything depending on that library.
Properties can have different accessibility for the getter and setter.
"Just semantics" always seems like a contradiction in terms to me. Yes, it changes the meaning of the code. No, that's not something I'd use the word "just" about.
The first class has a public field. The second class has a public property, backed by a private field. They're not the same thing:
If you later change the implementation of the property, you maintain binary compatibility. If you change the field to a property, you lose both binary and source compatibility.
Fields aren't seen by data-binding; properties are
Field access can't be breakpointed in managed code (AFAIK)
Exposing a field exposes the implementation of your type - exposing a property just talks about the contract of your type.
See my article about the goodness of properties for slightly more detail on this.
In that case, yes it is mostly semantics. It makes a difference for reflection and so forth.
However, if you want to make a change so that when MyProperty is set you fire an event for example you can easily modify the latter to do that. The former you can't. You can also specify the latter in an interface.
As there is so little difference but several potential advantages to going down the property route, I figure that you should always go down the property route.
The first one is just a public field, the second one is a so-called automatic property. Automatic properties are changed to regular properties with a backing field by the C# compiler.
Public fields and properties are equal in C# syntax, but they are different in IL (read this on a German forum recently, can't give you the source, sorry).
Matthias
The biggest difference is that you can add access modifiers to properties, for example like this
public class MyClass
{
public bool MyProperty { get; protected set; }
}
For access to the CLR fields and properties are different too. So if you have a field and you want to change it to a property later (for example when you want to add code to the setter) the interface will change, you will need to recompile all code accessing that field. With an Autoproperty you don't have this problem.
I am assuming you are not writing code that will be called by 3rd party developers that can’t recompile their code when you change your code. (E.g. that you don’t work for Microsoft writing the .Net framework it’s self, or DevExpress writing a control toolkip). Remember that Microsoft’s .NET framework coding standard is for the people writing the framework and tries to avoid a lot of problems that are not even issues if you are not writing a framework for use of 3rd party developers.
The 2nd case the defined a propriety, the only true advantage of doing is that that data binding does not work with fields. There is however a big political advantage in using proprieties, you get a lot less invalid complaints from other developers that look at your code.
All the other advantages for proprieties (that are well explained in the other answers to your questions) are not of interest to you at present, as any programmer using your code can change the field to a propriety later if need be and just recompile your solution.
However you are not likely to get stacked for using proprieties, so you make as well always use public proprieties rather the fields.