It doesn’t have to be in its own file, but your team should decide on a standard and stick to it.

Also, you’re right that “Go to definition” takes you to the interface, but if you have Resharper installed, it’s only one click to open a list of derived classes/interfaces from that interface, so it’s not a big deal. That’s why I keep the interface in a separate file.

I think you should keep them separate files. As you said, the idea is to remain testable and interchangeable. By placing the interface in the same file as your implementation, you are associating the interface with the specific implementation. Should you decide to create a mock object or another implementation, the interface will not be logically separate from FooService.

According to SOLID, not only should you create the interface, and not only should it be in a different file, it should be in a different assembly.

Why? Because any change to a source file that compiles into an assembly requires recompilation of the assembly, and any change to an assembly requires recompilation of any dependent assembly. So, if your aim, based on SOLID, is to be able to replace an implementation A with an implementation B, while the class C dependent on interface I doesn’t have to know the difference, you have to make sure the assembly with I in it doesn’t change, thus protecting the usages.

“But it’s just a recompile” I hear you protest. Well that may be, but in your smartphone app, which is easier on your users’ data bandwidth; downloading one binary that changed, or downloading that binary and five others with code that depends on it? Not every program is written to be consumed by desktop computers on a LAN. Even in that case, where bandwidth and memory are cheap, smaller patch releases can have value because they’re trivial to push out to the entire LAN through Active Directory or similar domain management layers; your users will wait only a few seconds for it to be applied the next time they log in instead of a few minutes for the whole thing to be reinstalled. Not to mention that, the fewer assemblies that must be recompiled when building a project, the faster it will build, making you more productive because you spend less time sitting around waiting for 50 assemblies to build for each change you make.

Now, the disclaimer: This is not always possible or feasible to do. The easiest way to do this is to create a centralized “interfaces” project. This has its own downsides; code becomes less reusable because the interface project AND the implementation project have to be referenced in other apps reusing the persistence layer or other key components of your app. You can overcome that problem by splitting the interfaces into more tightly coupled assemblies, but then you have more projects in your app which makes a full build very painful. The key is balance, and maintaining the loosely-coupled design; you can usually move files around as necessary, so when you see that a class will need many changes, or that new implementations of an interface will be needed regularly (perhaps to interface with newly-supported versions of other software, or file types, etc) you can sever it from its interface and protect usages from knowledge of those changes.

Why is having separate files a discomfort? For me, it’s much neater and cleaner. It’s common to create a subfolder named “Interfaces” and stick your IFooServer.cs files there, if you want to see fewer files in your Solution Explorer.

The reason the interface is defined in its own file is for the same reason that classes are usually defined in their own file: project management is simpler when your logical structure and file structure are identical, so you always know which file a given class is defined in. This can make your life easier when debugging (exception stack traces usually give you file and line numbers) or when merging source code in a source control repository.

It is often a good practice to let your code files contain only a single class, or a single interface. But these coding practices are a means to an end – to better structure your code making it easier to work with. If you, and your team, find it easier to work with if the classes are kept together with their interfaces, by all means do so.

Personally I prefer to have the interface and class in the same file when there is just one class that implements the interface, such as in your case.

In regards to the problems you have with navigation, I can highly recommend ReSharper. It contains some highly useful shortcuts for jumping directly to the method implementing a specific interface method.

There are many times where you want your interface to be not only in a separate file to the class, but even in a separate assembly altogether.

For example, a WCF Service Contract interface can be shared by both client and service if you have control over both ends of the wire. By moving the interface into its own assembly, it will have fewer assembly dependencies of its own. This makes it much easier for the client to consume, loosening the coupling with its implementation.

Interfaces belong to their clients not to their implementations, as defined in Agile Principles, Practices and Patterns by Robert C. Martin. Thus, combining interface and implementation in the same place is against it’s principle.

Client code depends on the interface. This allows the possibility of compiling and deploying the client code and the interface without the implementation. Than you can have different implementations working like plugins to the client code.

UPDATE:
This is not an agile-only principle here. The Gang of Four in Design Patterns, back in ’94, are already talking about clients adhering to interfaces and programming to interfaces. Their view is similar.

It rarely, if ever, makes sense to have a single implementation of an interface¹. If you put a public interface and a public class implementing that interface into the same file, good chances are that you do not need an interface.

When the class that you co-locate with the interface is abstract, and you know that all implementations of your interface should inherit that abstract class, locating the two in the same file makes sense. You should still scrutinize your decision to use an interface: ask yourself if an abstract class by itself would be fine, and drop the interface if the answer is affirmative.

Generally, though, you should stick to the “one public class/interface corresponds to one file” strategy: it is easy to follow, and it makes your source tree easier to navigate.

¹ One notable exception is when you need to have an interface for testing purposes, because your choice of mocking framework placed this additional requirement on your code.

Putting a class and an interface into the same file puts no limits on how either can be used. An interface can still be used for mocks etc in just the same way, even if it is in the same file as a class which implements it.
The question could be perceived purely as one of organisational convenience, in which case I would say do whatever makes your life easier!

Of course, one could argue that having the two in the same file might lead the unwary to consider them to be more programmatically coupled than they really are, which is a risk.

Personally, if I came across a codebase which used one convention over the other I wouldn’t be too concerned either way.

I personally don’t like the “I” in front of an interface. As a user of such a type I’don’t want to see that this is a interface or not. The type is the interesting thing. In terms of dependencies your FooService is ONE possible implementation of IFooService. The interface should be near of the place where it is used. On the other hand the implementation should be at a place where it can be easily changed without effecting the client. So, I would prefer two files – normally.

Coding to interfaces can be bad, is in fact treated as an anti-pattern for certain contexts, and is not a law. Usually a good example of coding to interfaces anti-pattern is when you have an interface that only has one implementation in your application. Another would be if the interface file becomes so bothersome that you have to hide its declaration in the implemented class’s file.