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)
Related
I see, that it's defined in Interface IntStream, but when you write IntStream.range(0, 200).sum(); how the implementation is called? where is it? couldn't find..
As for every interface, it's defined in the concrete class(es) that implement the interface.
In this case, it's in java.util.stream.IntPipeline, which is not a public class. But you shouldn't care about that. All you need to know is that an IntStream has that method, which does what the javadoc of the method does.
If you're really curious about its implementation, look in the source code of IntPipeline.java:
return reduce(0, Integer::sum);
Note on how I found out extremely easily: I just open the type hierarchy of IntStream in my IDE (IntelliJ, but all decent IDEs have that functionality), and notice that it has a single direct implementation: IntPipeline, which indeed contains the method.
If you are using an eligible compiler, there is an option to show its implementation. For example, when I want to see its implementation by IntelliJ, I click go to implementation. Then, it redirects.
In IntPipeLine.java,
#Override
public final int sum() {
return reduce(0, Integer::sum);
}
I'm working on a large Asp.Net MVC3 application (>50 views) and we are currently planning on using Unity for our dependency injection framework. For ease of maintenance, I would like to be able to query the assembly to find all of the base types, then register them with Unity.
Based on sample code from the Unity MVC3 Project for registering all controllers, I tried the following code -
var orchestratorTypes = (from t in Assembly.GetCallingAssembly().GetTypes()
where typeof(IOrchesratorBase).IsAssignableFrom(t) &&
!t.IsAbstract
select t).ToList();
orchestratorTypes.ForEach(t => container.RegisterType(t);
When I run the application I get the following error message
The current type, WwpMvcHelpers.BaseClasses.IOrchesratorBase, is an interface and cannot be constructed. Are you missing a type mapping?
If I register the class using individually, as below -
container.RegisterType<IOrchesratorBase, HomeOrchestrator>();
Everything works correctly. Is there a way to do this so that I don't have to register each type individually?
EDIT
Per request, my inheritance hierarchy is
HomeOrcestrator <- IOrchesratorBaseList<LocalModel>
<- OrchesratorBase<LocalModel> <- IOrchesratorBase
The usage in the controller is
public class HomeController : ControllerListBase <HomeOrchestrator, LocalModel>
{
public HomeController() {}
public HomeController(IOrchesratorBase homeOrchestrator) {
this.Orchestrator = (HomeOrchestrator) homeOrchestrator;
}
The LINQ to get the types appears to work. I don't think that's your problem.
You'll get a similar error if you just write
container.RegisterType(typeof(HomeOrchestrator));
and call container.Resolve<IOrchesratorBase>().
In other words, RegisterType(t) is not the same as RegisterType<I, T>().
The real question is, what are you resolving and how do you want it resolved? Your query is finding implementors of IOrchesratorBase. Are your injection constructor parameters of that type? If so, what's Unity supposed to do when 20 types implement that interface?
Can you provide more information on your class/interface hierarchy, constructor parameters, and what you expect/want to happen?
(I'd refactor to change IOrchesratorBase to IOrchestratorBase, BTW.) :)
Edit
Based on the edited question, the problem is that, in order to resolve a HomeController, Unity is looking for a type registration for IOrchesratorBase. It determines the interface type by the parameter types of the constructor with the most parameters.
If you write container.RegisterType<IOrchesratorBase, HomeOrchestrator>() the answer is obvious - Unity will construct an instance of HomeOrchestrator and inject it.
Now, is there more than one type that implements IOrchesratorBase? If so, and you register both of them (explicitly), Unity will use whichever one you register last. That may not be what you want.
If you have multiple controllers, each taking a different interface type in their constructors (with only one implementation per interface), you'll need to figure out what each interface type is and re-run your LINQ registration for each one. That could be done via reflection - find the orchestrators or the controllers.
If you have multiple controllers, each taking the same interface type in their constructors and you want different implementations for each, you've got a problem. You'd have to register named types and determine the names somehow, or something similar.
Unity isn't magic. It can't figure out your intentions.
Addendum
Unity can operate in a convention-over-configuration mode; see Using Unity With Minimal Configuration.
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
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.