I won't answer the 'will C# replace C++' bit directly, that could start world war 4, however, what I will say is that in time, managed code will completly replace unmanaged code. If thats .net, well we will see. In some ways I hope it isn't, because if it isn't, then whatever beats it would have to be an order of magnitude better 
That said, I would say as a guess, 50-75% of game development studios out there are probably already using .net for internal tool development (I say that just juding by job adverts I've seen). So it's just a matter of time before more games are produced in .net.
If someone 'scofs' when you mention using a tool in, or as the basis of a project, then clearly that person is ignorant of the tool.
What I will say, is that if you want to start a major project, you absolutly *must* be comfortable with the language before you do. Especially, you need to be aware of not only it's features and abilities, but also it's limitations (be they by design or not) and how you either avoid or work around those limits (or in some cases, take advantage of them).
it's entirly what you feel comfortable doing I guess..
Personally, you could call me something of a .net ******. My inital experience with .net seemed to be a case of using it casusally, with a sort-of 'ho hum another tool' sortof attitude. But over the course of about 6 months I gradually started using it more and more, eventually to now where 95% of what I do is .net, 5% being C++ (although mostly C++.net - which I highly advise you to avoid at all costs, unless you need to make a managed wrapper to unmanaged code, in which case it does the job well)
When it comes to a language I choose, I will base it on how productive I can be with that language, how easily it will let me implement algorithms and designs, how easily it will let me document and maintain (and expand) that code, and finally how easily it will let me debug my code.
If you look at .net, you will see that it does *extremly* well in all those areas.
Maybe not everyones goals, but I think they are important.
When I consider C++, I see the following problems:
productivity: worrying about memory managment, compile times, dealing with headers/linking/etc (I'm often amazed how much time you can waste sorting out linker errors in C++...) etc
implementing algorithms: very debatable, but I feel C++ is quite poor at this, mostly for the points above. If you take qsort as an example, you have to use function pointers, converting void* pointers to objects, doing an in-place sort (can't have pointers to members), etc. In .net, you simply have your class implement the IComparable interface, and done, you can sort or store that object in many different ways.
documentation and maintainance: well that should be obvious. maintainance includes future proofing. Lack of the points below is key here.
debugging is also problematic, espeically with the lack of any proper exception handling (I don't feel C++ or sturctured exeption handling is any use at all frankly). Let alone the fact most 3rd party libs don't do any internal debugging of their own (they assume you are using them correctly). Ohh the fun of HRESULT. C++ is also very loose, where .net is strict. Ever had a underflow/overflow bug on a variable? arn't they fun, and are just the tip of the ice berg.
However, of course, there is the other side of the coin.
.net isn't perfect either, MDX is currently still effectivly beta, which makes it slightly unreliable, and debatable as a basis for a commercial project (I've recently discovered a pretty bad memory leak for example if you do certain things - that said I'm using it in 2 commercial projects at the moment), and of course, you have the overhead of requring the .net framework.
You also have to accept that most of your code will be approximatly the same speed as debug C++, but this usually doesn't matter at all as speed comes down to algorithms not raw processing grunt. Also memory usage is potentially higher (although in real world code it's not that bad). overheads on classes are quite small considering (16 bytes I think), and overheads on structs are pretty much zero. (Many people are surprised to see that their 10-line app is using 20+mb in task manager, but this is actually the .net GC pre-allocating resources)
A nice example might be the Ogre engine vs Axiom (a .net port of ogre). basically, they are almost exactly the same speed in every test, with some exceptions (axiom is almost twice as fast in one, ogre 20% faster in another, etc). Yet by far the easier to use would probably be axiom, it's smaller, takes about 15sec to fully build, etc, due to it's ease of debugging and integrated documentation it's more productive. (not that i perticuarly enjoy the design of either, but as a comparison it works...)
etc.
As I say, I'm a fan-boy. But I am from experience.
I'm pleased you are starting to enjoy C#, it is a very nice language.
damn it's after 4am... argh
That said, I would say as a guess, 50-75% of game development studios out there are probably already using .net for internal tool development (I say that just juding by job adverts I've seen). So it's just a matter of time before more games are produced in .net.
If someone 'scofs' when you mention using a tool in, or as the basis of a project, then clearly that person is ignorant of the tool.
What I will say, is that if you want to start a major project, you absolutly *must* be comfortable with the language before you do. Especially, you need to be aware of not only it's features and abilities, but also it's limitations (be they by design or not) and how you either avoid or work around those limits (or in some cases, take advantage of them).
it's entirly what you feel comfortable doing I guess..
Personally, you could call me something of a .net ******. My inital experience with .net seemed to be a case of using it casusally, with a sort-of 'ho hum another tool' sortof attitude. But over the course of about 6 months I gradually started using it more and more, eventually to now where 95% of what I do is .net, 5% being C++ (although mostly C++.net - which I highly advise you to avoid at all costs, unless you need to make a managed wrapper to unmanaged code, in which case it does the job well)
When it comes to a language I choose, I will base it on how productive I can be with that language, how easily it will let me implement algorithms and designs, how easily it will let me document and maintain (and expand) that code, and finally how easily it will let me debug my code.
If you look at .net, you will see that it does *extremly* well in all those areas.
Maybe not everyones goals, but I think they are important.
When I consider C++, I see the following problems:
productivity: worrying about memory managment, compile times, dealing with headers/linking/etc (I'm often amazed how much time you can waste sorting out linker errors in C++...) etc
implementing algorithms: very debatable, but I feel C++ is quite poor at this, mostly for the points above. If you take qsort as an example, you have to use function pointers, converting void* pointers to objects, doing an in-place sort (can't have pointers to members), etc. In .net, you simply have your class implement the IComparable interface, and done, you can sort or store that object in many different ways.
documentation and maintainance: well that should be obvious. maintainance includes future proofing. Lack of the points below is key here.
debugging is also problematic, espeically with the lack of any proper exception handling (I don't feel C++ or sturctured exeption handling is any use at all frankly). Let alone the fact most 3rd party libs don't do any internal debugging of their own (they assume you are using them correctly). Ohh the fun of HRESULT. C++ is also very loose, where .net is strict. Ever had a underflow/overflow bug on a variable? arn't they fun, and are just the tip of the ice berg.
However, of course, there is the other side of the coin.
.net isn't perfect either, MDX is currently still effectivly beta, which makes it slightly unreliable, and debatable as a basis for a commercial project (I've recently discovered a pretty bad memory leak for example if you do certain things - that said I'm using it in 2 commercial projects at the moment), and of course, you have the overhead of requring the .net framework.
You also have to accept that most of your code will be approximatly the same speed as debug C++, but this usually doesn't matter at all as speed comes down to algorithms not raw processing grunt. Also memory usage is potentially higher (although in real world code it's not that bad). overheads on classes are quite small considering (16 bytes I think), and overheads on structs are pretty much zero. (Many people are surprised to see that their 10-line app is using 20+mb in task manager, but this is actually the .net GC pre-allocating resources)
A nice example might be the Ogre engine vs Axiom (a .net port of ogre). basically, they are almost exactly the same speed in every test, with some exceptions (axiom is almost twice as fast in one, ogre 20% faster in another, etc). Yet by far the easier to use would probably be axiom, it's smaller, takes about 15sec to fully build, etc, due to it's ease of debugging and integrated documentation it's more productive. (not that i perticuarly enjoy the design of either, but as a comparison it works...)
etc.
As I say, I'm a fan-boy. But I am from experience.
I'm pleased you are starting to enjoy C#, it is a very nice language.
damn it's after 4am... argh
