That's one of those questions where if you have to ask, it doesn't matter.
i.e. C# will be fast enough for you

Microsofts directx wrappers to the .net framework have all been discontinued apart from XNA which uses directx 9 so is a little out dated and won't give you the low level access you want. Slimdx is a 3rd party wrapper and seems to be the way most people go with C#/other .net languages.

C++ is usually compiled straight to native code so doesn't need the .net framework (although there is also a variant of C# for .net). C#'s slowness compared to regular C++ only really comes down to the .net framework, any language using a virtual machine (.net, mono, java etc) is always going to be slower than native code (C, C++).

C# is easier to use than C++. Through slimdx you get the full feature set of dx9, dx10 and dx11, through microsofts outdated wrappers you get full access to dx9 only and through XNA you don't tend to get much access to directx itself but it does use dx9 under the hood.

Slimdx class names etc I believe are slightly different than native C++ directx but conversion of code over to C++ should be possible. Chances are you won't have performance issues on C# anyway, at least not until you start hitting AAA graphics and physics etc that aren't normally possible for a single developer

For a techdemo with pure rendering and nothing else, the language chosen is very likely to be insignificant - work is going to be mostly done on the GPU so your graphics hardware will be the main determinant of performance, by a very large margin. You could probably even use VB Script (not that I'd seriously suggest it...) and not notice much in the way of perf difference. The only real CPU-side overhead will be from API calls, and on any performance graph that's going to be down in the noise - fillrate, shader performance, etc will be where your time goes.

So at this level choice of language is really not a factor, and if that's all you want to do, then go with the language you're most comfortable with.

As soon as you get into adding physics, AI, sound, networking, any kind of non-trivial scene-traversal, things change. That's where you want to pick a fast language with low overhead, but it's also important that your code is written sensibly and in a performant manner. It's easy enough to write stupid C/C++ code with heavy run-time overhead that can be crushed by any other language, so it should be obvious that choice of language is not as important as just doing things right.

Its possible to link unmanaged DLL's into .net applications, not necessarily an easy process (these basically include C++ class libraries etc) and accessing them is usually done through a .net class laid over the top of the unmanaged code, this is often referred to as a wrapper. Slimdx for example, you make a call to slimdx and then slimdx goes off and makes the calls into the directx library. A simple function like print4squares() will be able to be called with just that one line in a C++ application. If the function is written in C# then it can be called from a .net application with 1 line aswell. But calling it in an unmanaged DLL from .net it might require 5 or 6 lines of code before you get to being able to type the line you need hence why wrappers exist, with the wrapper you only have to type the one line of code again and it deals with conversion for you. Wrappers are still alot faster than straight porting a library to C# though. For example MOgre and Axiom are both versions of Ogre3d for .net. However MOgre is a wrapper around the original C++ library and Axiom is Ogre3d ported straight over to full C# code. With the same demo sample in MOgre I get 2 fps lower than the reference Ogre3d implementation (with a framerate in the multiple hundreds this is hardly significant) but on Axiom I can only achieve around half the original Ogre3d frame rate.

For 1 game I think just going with a single language may be much simpler. C# is still pretty fast and most of the time graphics will be through a wrapper and hardware accelerated. Axiom is probably one of the only non wrapped graphics libraries out there for .net. Physics will depend on what route you go down, rolling your own or using an existing library. Once again alot (but not all) physics libraries for .net are wrappers for existing C++ libraries but unlike graphics probably won't be hardware accelerated (unless you are using PhysX for which there is a .net wrapper for and also happen to have an NVidia graphics card, Bullet also has hardware acceleration as a user option but this is on a recent version that doesn't have a .net wrapper yet). A beginners indie game will be fine in C# coded properly. If you think you can cope with C++ though then by all means go for it. Just to show what .net can do (specifically XNA, not known which language, I assume C#): [media]http://www.youtube.com/watch?feature=fvwp&v=OiGADgezjC8&NR=1[/media]
this is of course just rendering, no physics (I think, the water has waves in it but whether theres any actual physics calculation or its just a pre coded effect I have no idea) or AI going on but damn its pretty.

If the other components expose a COM interface you can just add a reference and use the interface directly. Releasing is a bit fiddly but not much, otherwise it's quite straightforward (I've done evil things such as Lotus Notes (spit) interop before, so I can be fairly certain this works!) If you don't want that you could otherwise just write them as standard DLLs and use dllimport. See http://msdn.microsof...8(v=vs.71).aspx for some more info.