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.