Develop Reference

Why is "Implement Interface Explicitly" only available sometimes and not also "Implement Interface" (i.e. implicitly)?

I was just trying to (re)implement my interface on a class where it was already implemented because I added some properties to the interface. The existing properties were implicitly implemented, i.e. I had chosen this option when I first implemented it:
Now when I went to re-implement it doing the same thing after I added the new properties to the interface, I only had the option to implement explicitly:
Why does this happen sometimes? I've done this plenty of times before where it's worked as "expected", and it always just adds the missing member implementations.

If the option where actually there, and it would actually add in the stubs for the methods to implicitly implement the interface, then the code wouldn't compile, as you'd have two methods with the same signature (since you already have the interface's methods as methods of the class). The only other real sensible behavior for that option, were it to be left in, would be for it to just do nothing (as there is already an implicit implementation).

Is there a way to make every class in a project implement an interface (without doing a bulk find and replace)

Is there any way to do something like this: In Groovy Is there a way to decorate every class to add tracing? but in C#. Since C# doesn't support metaClass I'm stuck as to how to do it. If I could get this solution to work then I would then just iterate through every class using reflection and make it implement the interface.
Thanks,
Joe

Yes, you can use dynamic proxies.
Why don't you take a look at Castle DynamicProxy? http://www.castleproject.org/projects/dynamicproxy/
Or PostSharp, if you want to leverage AOP in a cleaner way:
http://www.sharpcrafters.com/postsharp/documentation
UPDATE
The OP said in some comment:
Ah, I'm actually using PostSharp to output what methods are called and
when. What I'm tring to avoid having to do though is adding an
attribute to every class in my code. So I figured I could just create
an interface like this: [MyAttribute] public interface IDebug {} And
make my classes implement this interface at runtime.
PostSharp supports assembly-level aspects: [assembly:YourAspect]. Later, in your aspect, you can check what method was invoked and to which object belongs to, and do the whole job depending on that.

How can I determine at runtime if an interface member is implemented?

I have an interface called IStructuredReader that reads some structured data from a file and displays it in a form. It has a member called Sync() that, when implemented, scans the data for a user-specified data pattern.
Some implementations of IStructuredReader don't have sync capability. Those implementations throw NotImplementedException for the Sync() method. I would like to be able to check for this method being implemented, so that I can dim the button on the form if it is not.
I can think of a number of ways that this could be done, all of which seem clumsy and complicated:
Separate the Sync method into its own interface, inherit it for those implementations that support the capability, and attempt to cast the reader object to it to identify the capability,
Write a NotImplementedAttribute, decorate the member with it, and check for the presence of the attribute using Reflection,
Add a HasSyncCapability boolean property to the interface.
Is there a canonical way this is done?

This sounds like you really should have two interfaces. Your Sync() method is obviously adding functionality over your base interface, which suggests that this is really a separate concern, as it's not a requirement of IStructuredReader. I would suggest adding a second interface for the types which support this, which would then be easy to check for in your view layer.

The canonical way is for the interface to expose the methods that will be implemented, so the cleanest solution I see is to create another interface called maybe Syncronizable with just that method. If your object implements that interface you know the method is there, and this is not clumsy at all. Using reflection or the extra attribute are indeed not as clean as solutions, but it doesn't mean you shouldn't go for those if it makes your life easier ;)

Overriding an internal abstract method in another assembly

Im currently working on a c# project that uses another .net library. This library does (amongst other things) parse a sequence into a tree. All items are of some type that inherits from the abstract class Sequence. I needed to alter the behaviour slightly and subclassed Sequence myself (lets call it MySequence). After the tree was created, I could replace some tree nodes with objects of my own class.
Now, a new version of the library was published, and a Copy function with the following signature was introduced:
internal abstract Sequence Copy();
I tried to adopt my code to the new version and override it, but whatever I am doing, I get the two errors:
MySequence does not implement inherited abstract member 'Sequence.Copy()'
and:
MySequence.Copy()': no suitable method found to override
This makes sense, since it is abstract (--> it must be overwritten) and internal (--> it can not be overwritten, due to hidden visibility from outside the assembly)
So, the problem is, I understand why this is happening, but dont know what to do against it. It is crucial for my project to subclass Sequence.
And what I also dont understand is, why the internal abstract modfier is allowed in the first place as it basically permits any subclassing of the whole class from outside the assembly!?
Is there any way to solve this? Via reflection or something?
Thanks in advance!

Basically, you are out of luck without altering the library. There may be a subclass of Sequence that does implement Copy, which you can derive from in the new version. But it is likely that the Copy method is need in other parts of the library to create clones.

This modifier means that the class can only be inherited in the assembly that defined it.
There is no way around that.

If a library has a type with a member with the modifiers internal abstract, I conclude that the developers of that library didn't want anyone to derive their own type from that type. You cannot work around this.
You can consider whether this was done deliberately. You should ask the publishers. It might be a mistake, in which case the publishers will probably issue a fix. If it is done deliberately, you should come up with an alternative solution without deriving from that type.
EDIT: Or perhaps they intended for you to derive only from derived types in the same assembly that already implement that member.

Is it possible to force an update of an Interface?

In resharper is it possible to force an update of an interface?
Basically I have a class that inherits from an interface but this class is constantly changing so I need to reflect the changes in the interface otherwise VS complains that I am not implementing something as the signature of the method has changed.
I was wondering if there is a way in resharper to say "Update this class with its interface" ?
Any ideas?

Although not the best way to design, sometimes it is necessary to update the interface based on the modified class.
You can update the interface using resharper's Pull Members Up option.
Use the Pull Members Up option in the refactor menu
Select the interface you would like to update as the base type
Select the members you would like to add to the interface
The members have now been added to the interface.

If you use ReSharper to modify the method, it can/will also modify the interface definition.
For instance, if you use ReSharper's Rename functionality on the method, the interface definition of it will get renamed. Additionally, if you use ReSharper's Change Signature functionality on the method, it asks you if you want to do the refactoring on the interface as well.

If you're changing signature of a method defined in an interface, change it via Refactor - Change Signature.... ReSharper will then ask you if you want to change signature of an interface method.
Other than that, I cannot imagine how would ReShaper know what and how to update.

Letting the interface follow the implementation is the exact wrong direction. First, you should define in your interface, what you need, then implement it in the backing class. You shouldn't expect a tool to support undesired workflows instead...
If you go the right way, R# will give you all support you ever need: You can refactor existing methods via Refactor|Rename..., Refactor|Change Signature... and Implement Members.