We Keep Coding

Is C++ and .NET used together in Domains like Banking , Health Care and Telecom

Or I should ask how helpful and benifitial will it be to start with C++
This may seem irelevant but it has some significance for me,may be few others like me.
I just want to know ,How Important is it to Learn C++ , COM and ATL while you are a .NET programmer?
I love programming with .NET and C# .Visual Studio just has it's own charm of intellisence ,Color Coding and other pretty features , which make us addicted to it.
I was thinking , almost we can build anything with C# and still it holds true mostly, but it lags sometimes like:
While I try to create a Shell Extension , then it is highly suggested to use unmanaged code instead of any managed code.
Also there are few other things like COM , ATL , which are preferred to be coded in C++ rather than C#.
I am just 4 years in IT industry and love to be Solution Architect.
So need all your inputs to know , how important/helpful will it be in my future venture if I am doing my Current COM Project with C++ , which integrate with .NET UI.
Is there any implementation of C++ and .NET in common domains like Health Care, Banking and Telecommunication.

The issue (at least for the specific cases you mention, such as shell extensions) with trying to "integrate with a .NET UI" is that you really can't. The reason it's not a good idea to write shell extensions in managed code is that a given process can only load one version of the CLR at any given time. If two shell extensions depend on different versions of the CLR, and they both try to load at the same time, it will fail. You can't load the CLR in any way shape or form in the context of your shell extension and be a well behaved shell extension.
My advice would be to not bother with C++ until you really have a reason to learn it (despite that C++ is my favorite language). But when you do learn C++, leave your .NET baggage at the door. There are lots of things (such as excessive use of casting, constantly using new, etc) which are idiomatic C#, and are just plain wrong in C++. You will be a lot happier if you don't try to understand C++ concepts in terms of the CLR -- simply because C++ doesn't run there. You can use some of the design patterns you may have learned for C#, but how the underlying language and machine operates are completely different between the two languages.
Probably the most confusing difference for new C or C++ programmers is the concept of undefined behavior. The C and C++ standards are written in such a mannar as to not be tied to a particular machine. This is in stark contrast to architectures like Java or .NET, where the language is actually defined in terms of a virtual machine (and therefore is extremely dependent on that VM). This leads to places where the standard literally does not say what the correct output of a program should be; and instead says "however the underlying machine usually does this". You'll probably notice this quite a bit if you're ever dealing with floating point math. While C# has strict and specific rules about how and where floating points are calculated and rounded, C and C++ make no such qualifications.
Once you understand C++, then you can move on to COM and ATL. COM is essentially designed to make a C++ like class structure accessible in a language (the COM ABI), machine (marshalling between 32 bit and 64 processes on the same system, etc), and location (DCOM provides RPC facilities) independent way. If you don't understand the C++ object model, then you're going to have an extremely difficult time with the COM object model, because the two are extremely similar. ATL is a set of C++ class templates around COM fundamentals which simply handle some of the boilerplate for you.

I just want to know ,How Important is
it to Learn C++ , COM and ATL while
you are a .NET programmer?
Depends what you do. You are way better of learnin about databases. Pretty much every serious app uses a database.
But C++ IS ued together with .NET - especially C++/CLI (the managed variant) as it is very good for integrating C++ code with managed code effficiently. Quite often pretty much the only efficient way. Which is important if you for example raise events for market data. With a frequency in excess of 100.000 times. Per second.
But this is a NICHE. I work in the financial area, and tthe C++ uses AND integration uses are SMALL compared to the people working in .NET / In the application.

Port unmanaged C++ project to C#

I need to port a C/C++ unmanaged project (VS 2008) to C# (preferably .net 3.5).
Are there any conversion-helping
tools; let's say something
translating the code syntax and
asking you verifications/modifications for each
problematic point (I guess I'm dreaming...)
Where can I find some useful howtos or articles about this translation.
They would be very useful if they contained specific hints like:
extern variables should be set in public static classes
(I don't know, I'm guessing...)
Please no suggestion like "You can call your c++ dll from .net", because I know it's possible, but just I can't.
Note:
The C/C++ project uses only STL and
other basic functions, no 3rd Party
libraries etc.
I can't use it directly or wrapped
from C# because our company needs to
mantain/modify the code and we're extremely
more skilled in C# than in C++.

It will cost you far more to convert it than to wrap it and pay a freelancer (like me) to help you out by changing the C++ code for you every few months (or every few years) when you need to make a change. There are some mechanical approaches but the bigger issue is that you can never really be sure that the new C# code does exactly what the old C++ code did. I have clients who have tried this and most gave up and threw the work away. The ones who succeeded did it very slowly, like this:
First, you wrap the old library and get your UI or whatever the new code is (web service, whatever) successfully calling the old library. This gets everyone some "bang for the buck" and buys you time to solve the "we can't maintain our old code" problem. You also develop a comprehensive test suite that proves what the old library does for various edge cases and strange things that only happen in the wild every few years. Over time, you move functionality from the old library into a new C# one and change the calling code to use the new library for that functionality. You move the most volatile parts, the things you change most often, out first. At every stage you run the test cases again to make sure your translation from C++ to C# didn't mess up the results it calculates. Maybe some of it you never move out, maybe in the end it is all moved. You stop when you feel the risk of being unable to maintain your own library and needing to pay someone to do it for you has dropped below the cost of continuing to translate it.
I recommend you have access to someone with good C++ skills when you start. You will probably run into things that don't make much sense to you. But you can get the value from the library pretty quickly, and still solve your underlying problem in the long term.

Depends on what you mean by port.
You can rewrite some of the stuff in C#. Not everything. Some HW or legacy libraries would have to be handled with C/C++ even if you port your own code. I don't know of any reliable automatic converter for C++->C#, and I doubt one can exist.
A better idea may be to wrap your existing code in new C# code. You could create an interop layer in C++/CLI, for example. Or you can communicate with your native code with something like Google Protocol Buffers, if you don't want to mix native/managed code in the same process.

I doubt code conversion tools would help. If you need to make some C++ work in some fashion with .NET, the easiest way is to write a managed C++ layer that wraps it and provides an interface for .NET apps to work with. But it depends on the code.
What is the purpose of rewriting and what does your code do? Does it interface with other components? Does it have a GUI? Is it a standalone executable or a library? Is it a COM / ActiveX server or does it use COM components? Does it link to other DLLs or use 3rd party libraries?
All these affect how you're going to port / rewrite from scratch your app. For example, if your code is an MFC app you may as well forget trying to salvage much code. If your app does http / high level networking stuff you may as well write from scratch. If your code low level you might have to refactor with some C# and some C++ accessible through a managed C++ layer.
Lots of choices and it really depends what your app is doing, how it was written etc.

Effort estimation: using C / Win32 or learning C# / .NET

I intend to write a small application to scratch a personal itch and probably make the life of some colleagues easier. Here is what I have:
10+ years of experience in C
Plenty of experience in programming against the Win16/32 API in C from the Win3.1 to 2000 days.
C library written by myself already doing about 75% of what the application shall do.
What the application shall do:
open a binary, feed it into the mentioned library.
take the resulting text output and feed it into a new Excel Workbook.
apply some formating.
integrate nicely with the Windows environment (availability in "Open With...", remember some stuff using the registry etc.)
(maybe later) before giving the CSV data to Excel, parse it by looking up the meaning of some values in an XML file.
Except for the XML parsing part I have done all of that stuff before including COM / Office Automation in C/Win32. There is a lot of boilerplate code involved, but it is doable and the result will be a pretty small application without the need for an installer.
So why even think about C# / .Net?
no experience with parsing XML
the promise of less boilerplate code for the Windows and Excel stuff (yes, I have done C++ with OWL, MFC, ATL etc. but I am not going there anymore - not for free/fun)
Since I have also experience with C++, VB(not .Net) and a little Java / Objective-C I suppose learning C# will all be about the .Net libraries and not actually about the language.
My considerations so far:
Learning .NET might be fun and might result in less code / first steps in a more modern environment.
Sticking with what I know will lead to a predictable outcome in terms of effort and function (except for the optional XML stuff)
VB looked great at the beginning until the projects where about 80% done, then the pain started and the DLL coding in C. I am concerned history could repeat itself if I choose .Net.
My primary objective is the functionality. Effort is a concern. The XML parsing is optional.
Please advice.
Update: one thing I forgot to mention explicitly is that I am also worried about easy deployment of the tool to my co-workers. With Win32 I am pretty sure I can come up with an EXE file < 1Mb that can be easily emailed and does not require installation. With .Net not so much. Can I create the necessary MSI or whatever in Visual Studio Express (free) or do I need 3rd party tools?

as others have your question mostly covered, I'd just like to quickly comment on your considerations:
Learning .NET might be fun and might result in less code / first steps in a more modern environment.
Totally agreed. It is definitely fun and usually it does result in less code. The investment you make now will certainly benefit you in future projects. It is way faster to program in .Net than in C. Not only it is easier, but it is also safer. You are isolated from many programming errors common in C mostly related to memory mismanagement. You also get a very complete managed API to do stuff you would usually need to build your own framework.
Sticking with what I know will lead to a predictable outcome in terms of effort and function (except for the optional XML stuff)
Hence your indecision. :-)
VB looked great at the beginning until the projects where about 80% done, then the pain started and the DLL coding in C. I am concerned history could repeat itself if I choose .Net. My primary objective is the functionality. Effort is a concern. The XML parsing is optional.
.Net is an entirely different beast from VB. Most of the things you wouldn't be able to do in VB, or at least do them easily, are supported by .Net. For instance, Windows Services are a snap to build in .Net. Socket programming is also supported, but there are very few reasons to do it yourself, as you've got loads of communication APIs with .Net. You've got web-services, .Net Remoting, MSMQ management, and more recently WCF. Proper multithreading is supported by .Net, unlike the idiotic apartment model in VB. In case you really need to go low level, you can also actually use pointers in C#, inside of unsafe code blocks, even though I would never advise to do so.
If you really need to do things in C, then integrating is also relatively easy. You can create COM objects and use interop to work with them from .Net. You can also interact directly with plain ol' dlls using DllImport. Using www.pinvoke.net makes it easier.
When I developed in VB, sometimes I also had to go back to C++ to do stuff that I wasn't able of doing in VB. Since I began programming in .Net, the only extremely rare scenarios I would need to go back to C++ were when I needed to use legacy COM components that used types I was having a hard time to marshal via interop. I wouldn't worry about history repeating itself.

If you're using COM, you may be interested in using C# 4.0 instead of earlier versions - the downside being that it's only in beta. But basically it makes COM stuff somewhat less ugly for various reasons.
I'd expect there to be plenty of good C libraries for XML parsing by now. I would expect the main benefit to actually be the knowledge gained. I doubt that you'll actually produce the code faster for this project, but the next one may well be a lot quicker.
How much do you care about learning new stuff?

It sounds like an ideal project for learning C# & .NET.
You know most of what you need to do so you can use that to gain a base level of understanding of C# & .NET which you can then apply to the stuff you need to learn.
As Rune says though, a key driver could be the timescales. If this is something you need in a hurry then coding it in C & using win32 directly might be the answer.
Sorry I couldn't be more definite.

I think you should use C#. With your experience the learning curve won't be too steep. The code will ultimately be cleaner (and less of it) than you probably could with C/Win32.
There is probably going to be no problem using your existing C-library with the [DllImport] attribute.

It depends. :-) It depends on whether you want to do this quickly or if you want to learn something new. It depends on whether you will be the only maintainer of the code or if others will maintain it in the future. It depends on how complex your xml handling will be and on how complex the COM automation is.
You will probably get a working application quicker if you do it in C than in C#. Both since you have much of the stuff needed already in place and since you know C well.
But this project sounds like a good match for C# and .Net. .Net has great support for XML and COM interop is easy but clumsy in C# (much better in the next version!). So if you are interested in learning C# and .Net this would be a good project to do so.
I would definitely do this in .Net and probably C# (but I am biased). Using .Net would probably result in code that is easier to read and maintain and most probably easier to write. So if you are interested in learning C# I would suggest you go for it!
Edit:
You worry about the size of the executable if you write it in .Net. I doubt that will be a problem, for most if not all of the libraries you will use for a project like this will already be installed on your computer. 1 Mb is rather large for a .Net executable, event for a big project.

a short notice on the installation. .NET is as default xcopy-able so you wouldn't need an installer for the exe to be usable. Mail it around (or with the next release of the .NET framework optionaly leave it on a network share)

You could look at building a hybrid system that uses C++/CLI and C#. C++/CLI provides a nice bridge between the two and lets you easily split different parts of the system between the managed and unmanaged worlds.
Not sure if the setup projects are included in the free versions of visual studio. But you could use clickonce (included with the framework) or WIX (open source XML based msi creation tool).

learning C# will all be about the .Net libraries and not actually about the language
No there are many things you need to learn about the language (delegates , events , generics ...) and also it is object oriented and it manages the memory by itself and yes no pointers :)
anyway C# and .NET are great all you need is some effort to get up to speed

What can be done in VC++ (native) that can't be done with VC#?

What can be done in VC++ (native) that can't be done with VC#?
From what I can tell the only thing worth using VC++ native for is when you need to manage memory yourself instead of the CLR garbage collector, which I haven't seen a purpose in doing either (but thats for another question to be asked later).

Cross-platform development. Yes Mono exists, and Java's somewhat more predictable to have it function EXACTLY the same on more platforms, you can find a C/C++ compiler for just about any platform out there, where you can't with C#.
Also linking into 3rd-party libraries, while I'm sure there's a way to leverage them in C#, you'll be able to take advantage of them without interop (Marshaling, etc) in C++.
Edit: one last thing: RELIABLE memory management. Yes you can use dispose(), and try-finally, but there's nothing quite like KNOWING the memory is gone when it's popped off of the stack. Through techniques like RAII, when you use well-constructed classes, you will KNOW when your classes release resources, and not waiting around for the GC to happen.

With P/Invoke there is very little that is impossible in .NET (most obviously device drivers).
There are also things where the advice is to not use .NET (e.g. shell extensions, which get loaded into any process that opens a file dialogue1).
Finally there are things which will be much harder in .NET, if possible at all (e.g. creating a COM component that aggregates the FTM).
1 This can create a problem if that process is already using a different version of .NET. This should be alleviated in the future with .NET 4 having the ability to support side by side instances of the runtime.

I'm not sure if you're talking about language features or applications. My answer though is for applications / components.
Really there are only 2 things you cannot do in C# that you can do in C++.
You cannot use C#, or any other .Net language, to write a component for a system that only accepts native components
You cannot use C#, or any other .Net language, to alter certain properties of a CCW for which the CLR does not allow customization
The most notable item here is Device Drivers. This is a framework that only accepts native components and there is no way to plug in a managed component.
For everything else it's possible to do the same thing in C# as it is in C++. There are just a lot of cases where you simply don't want to and a native solution is better. It's possible for instance to manage and manipulate memory in C# via unsafe code or IntPtr. It's just not nearly as easy and generally there's no reason.

You can't write device drivers for one.

I think there are several important points:
You can do anything in C#/C++/Java/Python/Lisp or almost any other language, finally all of them Turing complete ;)... The question is it suits your needs?
There is one big and extreamly important limitation of C#... It runs only one single platform Windows... (Mono is still not mature enough).
There are many applications where GC is just a waste of resources, applications that can't afford you throw up 1/2 of memory untill next gc cycle: Games, Data Bases, Video auido Processing and many other mission critical applications.
Real Time applications (again games, video processing and so on). Non-deterministic GC makes life much harder for them.
In fact, most of desktop applications: Web Browsers, Word Processors, Desktop Environment itself (like Windows Explorer, KDE or Gnome) are written in compiled languages with careful thinking about resources... Otherwise, they would just be terrible bloated applications.

Whereas writing shell extensions in Windows XP was possible in C# it is next to impossible to write shell extensions for Vista and Windows 7. Shell extensions and Namespace extensions (and anything else that uses the new Properties system) (kindof) must be done in C++ unless you're into pain.

There are two obvious answers:
VC# can never run without the .NET
framework. Native C++ can. That may
be necessary in some areas (others
have mentioned device drivers, but
more common examples might simply be
clients where the .NET framework is
not installed. Perhaps you're
distributing an application and you
know not all of your customers are
willing to install .NET, so your
sales would go up if you made an app
that just worked without the
dependency on .NET. Or perhaps you're
working on some mobile device where
the couple of megabytes taken up by
the .NET CF can not be justified. Or shell extensions where using .NET can cause nasty problem for the user.
And VC# can never use C++ language
features. Native C++ can. (Managed
C++ can too, of course, but that's a
different issue). There are, believe it or not, things that can be done more conveniently or elegantly in C++. And they're only accessible if you're programming in C++.
System calls are no problem, however. p/invoke lets you do those from C#, almost as easily as you could from C++.

inline assembler
You cannot use C++-Libraries with classes (P/Invoke can only be used for functions AFAIK)
You cannot use callbacks with P/Invoke.

Is C# in particular and .NET in general self compiling yet (this is not a troll, I genuinely don't know)? If not, you can use VC++ to write C# and .NET, but you can't use C# to do the same job.

This is tongue in cheek, but it also is an answer to your question... you can screw things up much more severely in VC++ than you can in VC#. Not that you can't manage to screw things up severely in VC#, but in general, you can screw them up easier and more thoroughly in VC++.
Again, kind of tongue in cheek, but also an answer to your question. Perhaps not what you were hoping for, but... :-)

There's also hard real-time applications. Any language with a GC cannot be used, just in case it decides to collect during a time-constrained part of the code. Java was notorious for not even allowing you to try (hence the EULA about not using it for software "intended for use in the design, construction, operation or maintenance of any nuclear facility"
(yes, I know they've since made a modified version of Java for real time systems).

For example, it makes sense to use C++ if it's harder to translate the header files for existing libraries than it is to give up the existing managed libraries.

The Main difference is:
C++ is a core language with which you can build stand-alone programs. These Programs communicate directly with the the operating system and nothing else. C++ compilers exist for more or less all platforms (operating systems).
C# is a language that conforms to the CLS. A program written in C# can not start without a CLI engine (.NET Framework, Mono, etc.). A Program written in C# communicates with the .NET framework AND with the operating system. You have a man in the middle. Like all servicing personal, this man can help but it will cause additional trouble. If you want to port, you have a different man in the middle etc. CLI Implementations do not exist for all platforms.
By my opinion every additional framework is a additional source of problems.

Using SSE instructions seems to be one of these cases. Some .NET runtimes will use some SSE instructions, depending on your code. But in VC++, you can use the SSE intrinsics directly. So, if you're writing a multimedia code, you'd probably want C++. (C++/CLI might work as well, presumably)

What is a good desktop programming language to learn for a web developer? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'm want to learn a desktop programming language, preferably C, C++ or C#. I'm a PHP/HTML/CSS programmer and I would like to get into desktop applications. I need something pretty powerful and I would like to be able to create applications with Windows GUI's.
What would the Stack Overflow community recommend? Is there any knowledge I should have before diving into these languages?

edit:
A web programmer wants to create Windows applications and you recommend C? What's wrong with you people?!
/edit
Obviously C#.
C# will be easier to get into and will let you build Windows applications using WinForms or WPF and all the new Microsoft toys in .NET. If you know your way around PHP, you should already be familiar with the syntax, object oriented concepts, exception handling, etc.
I suggest you don't complicate your life with C and definitely not with C++ if all you want is to create Windows GUIs. They do provide a good educational experience and they are useful for more advanced things (cross platform development using other toolkits for instance) but at the price of a steeper learning curve and reduced productivity.
Also, if you are a web developer, C# is the only language among the 3 options that you can (realistically, heh) use for the web. ASP.NET is not a bad framework and might be worth investigating too.

"I need something pretty powerful and I would like to be able to create apps with Windows GUI's."
For rich windows GUIs, I'd be tempted to look at the "xaml" variants: WPF (full desktop) and Silverlight (like flash) - this will give you the latest tools etc, and a lot of styling power.
For this, C# would be the primary choice. Managed C++ is an option, but it's more work.

Take a brief look at C first, to the level of writing a few tutorial programs. C is small, well defined and the definite language definition (Kernighan & Ritchie - The C Programming Language) is only a couple of hundred pages long. Although getting your head around pointers and recursion can be a challenge the language itself is sufficiently small that it's possible to know the language completely. One of the pleasures of writing C is it's not too hard to reach the level where one can just code without having to continually refer to documentation to see how to use little know feature x or library function y. Think of learning C as putting the foundations in.
However to actually write useful applications you'll want to use C++ or C#. Which depends on what you wish to write. C# will probably score in most business-orientated cases because of garbage collection and general ease of use, but C++ would score for high performance, low level, or game domains. There's also vast amounts of C++ library code available which can be leveraged relatively easily (and pure C code too which is easily adapted). If your aim is to write something with a particular problem in mind then the availability of such could most likely offset the higher overhead C++ has in just getting things done.
By way of example on this I did a filtered search on 'image' on Sourceforge and returned the following project count
C# : 139
C++: 569
And even with something purposely more business-orientated C++ still scores higher - 'finance'
C# : 12
C++: 32
With anything mathematical or technical the score is heavily weighted against C# - 'fractal'
C# : 4
C++: 44
C : 24 <-- (C++ explicitly excluded)
This is a pretty crude analysis of course, but for example if my aim was to write a desktop fractal generator program then I'd pick C++ over C# as the extra effort involved in handling the UI in C++ would be easily offset by the plethora of example code available in C++. OTOH if I was writing a business application where there was no great advantage to having example code and lots of UI to handle then I'd go for C#.
Afterthought edit: Another reason for at least familiarising yourself with C first is that there's also Objective-C as the main development environment on the Mac and iPhone. Objective-C is C with a very thin wrapper and only really a first cousin to C++, so if you envisage that you might ever be in the position where you want to port code to or develop directly on the Mac then I think you'd find it less confusing if you at least have some feel for how C++ (or C#) builds on C rather than having to 'step sideways' across the tree.

C# vs the others really solve quite different things but given your web background and it's rapid development approach, I'd definitely go with C#

My suggestion is to learn C++. C# is good, but it will prevent you from writing portable code. If you learn C++, you got many choices. In windows you can use Windows Forms application or WPF with .NET framework. MFC is another good choice. QT is the other choice which works on multiple platforms. So by learning one language, you can write code for multiple platforms and you got a variety of GUI tookits. After learning C++, learning C# would be trivial.
All the best

C# is the highest-level language of these, which means that it's the easiest one to accomplish what you want.
Windows GUIs can be surely made with C++ and even with C, but it's harder.

definitely first go to the basics: learn C.
then go to your real goal. if you want any chance of going multiplatform C# is discarded. you'd want to go with C++ and Qt, or wxWindows.

In my opinion you should starting studiying C, to have a base knowledge about aspects like memory, file accessing. C is a low level languaje, this means that you will have more control over the way you access to operating system, but to create windows application you'll have to code a lot of lines of code. For this reason, after doing few things with C, i should start with C# with Visual Studio 2008. .Net Framework comes with a huge number of classes that makes your life easier.
Hope it helps.
Kind Regards.
Josema.

C/C++ both allow low level programming. That means that everything is possible, but even simple things can be hard. If that's what you mean when you say that you want something powerful, you should probably start with C++. It at least gives you some decent GUI libraries (gtk+ with gtkmm or qt), whereas GUI programming with C is a pain.
If, on the other hand, you want to develop applications quickly (and that's what you mean by powerful), then C# is probably the way to go.

I woudl recomend C#. It's not as powerfull as the other two, but for your needs I belive C# will be least painfull. C and C++ are low-level languages, so I think they will be a lot of work for GUI and stuff.

Save the C. To those people that advise learning C, please give arguments for that. I claim that it has absolutely no benefit to learn C rather than C++. I, unlike them, have arguments to back this claim up.
In a nutshell: C is already a subset of C++ for all intents and purposes, but it's far from the most interesting subset. It only offers a very limited insight into new proramming paradigsm. C++, on the other hand, defines a few very interesting new paradigms which, furthermore, are a generalization of all that C has to offer (i.e. iterators which are a generalization of pointers).
To reiterate: if the choice is between C and C++, choose C++.

Although I agree that C is "useful" to know it is certainly no longer essential for the majority of programmers. For me these days it's main function is that it has given me an understanding of how the underlying hardware affects program performance and behavior but that's the end of it. I haven't used it in development work for the last 9 years.
In regards to getting to grips with object-oriented development I feel that both C# and C++ will give you a firm foundation but C++ is far more flexible (and harder to use correctly) while C# is more consistent and way to go if you're going to get into .NET development. I would therefore recommend learning C# and one of the "new" .NET-presentation technologies like Windows Presentation Foundation or Silverlight. Alternatively, learn Windows Forms first but it's a bit lacking in presentation.
The only case where I would recommend C is if you are going into fairly low-level stuff like device drivers, embedded controllers or similar but in most of those cases you could still use C++.

Having come up through the languages, first C on Unix, then C++ with MFC and then C# (starting with 1.0) I think that going back in time to earlier incarnations of the language is a bit like learning Latin. Oh, probably just stolen something from Paul Graham there but I would agree with it.
C is very good if you have to have a minimal object code size, very good for embedded stuff where it's one step up on the assembly language. I'm thinking of things like a Microchip PIC etc where you may only have 1K word of program space.
C++ is very good if you can have the larger object size but still need to be able to hammer the metal directly - so things like device drivers, network stacks, etc etc. The kind of glue program that sits under everything.
An OS could end up in either of these - or more likely a mix of the two depending upon the programmer, the age of the code, what it needs to interface with, the depth of the snow outside (just one more run and then I'll write that method!)
C# is really good at the higher level business focussed user layer applications. They could be web based, client based, a mix of the two - it doesn't really matter. The nice thing about the .net family is that you have a rich library, for this layer that is important, and it is being heavily developed to be richer all the time.
As computers become more powerful the cost of the developer outweighs the cost of the processor or memory.
Go with C#, ignore C and C++. By the time you are happy with C# you won't have any need to program in a lower level language for the speed increase.

Again, another vote for C# and against C. Sure C is interesting from a technical point of view and will teach you all the details, but the truth is, you don't need to know all the details to make an application. If your goal is to make something work, which it sounds like it is, it's C# hands down. C# is the highest level of the three, which means less time fighting the language, more time making stuff work.
It sounds to me like most people are recommending you learn C so that you can eventually make better C# programs. Why wait, go straight for C# and learn it. I do think C++ is an absolutely excellent language and one day you should learn it, but there's no reason why you can't make a quality C# language if you've never learnt C or C++ - many people do that every day!

It doesn't really matter what kind of language you start with but if I were you I would do:
Start with the basics in C (It will probably be hard to understand)
Move to C++
And at last C#

I'd suggest you start with C#, but quickly progress to C++ as once you have learnt how to code generally, you should return to your roots. I'm currently studying electronics because I'm going back even further. The more you know about how and why, the better you can know about how best to get where you need to go. I think a C# programmer that doesn't know any lower level language is going to write rather sub-optimal code, but a low level programmer learning C# is going to be overly cautious of all the managed stuff. So, whatever you choose, you should consider doing both in the long run.

I would go for C#.
I've done my time (lots of it) with the other 2 and find C# 'cleaner'. You also get a rich library of all kinds of functions included in .Net. I assume that you're not interested in developing for other non-Windows platforms which might have been an argument for going for C or C++. I also assume that you don't need the squeeze the last drop of performance out of the system where C might have given you a slight advantage.
To those who say you ought to learn C in order to understand how programming really works I would say that you ought to learn assembler in order to understand how C works. I did and it does help but is it really worth the pain? To be a programmer you have to switch on your brain. Think about what you are doing and understand your tools!
My vote: C#

Learn C#.
Is good to begin with the basics, but better than begin with C I would begin with the basics of C#.
This will give you a solid foundation with the fine points of C# basics and after you could move to more advanced topics.
For example you can take a look to Charles Petzold ".NET Book Zero" here.

I recommend::
First get into C. spend some time get use to it(but not too much)
Then get into C#. that's the way you can deal with GUI things more easyily.
IDE like VisualStudio can help you a lot dealing with GUI.
If you wanna be a real good programmer of C/C++/C#, then it might be not the good way but I think you are not interested in being a Guru or something like that :)

There are a lot more jobs developing windows apps in C# than C or C++. Learn C#.

C# is a good place to start. You can get it for free and you can do some fun graphics using XNA studio (also free).
I would only learn C++ if you have a specific reason to.
If you are doing Windows programming I would recommend that you do the first few chapters of one of Petzold's Programming Windows books. It will give you a basic understanding of C and of how Windows works at the bare metal level. You don't really need to learn C. Charles Petzold holds your hand and gets you up and running in a basic C Windows program.

Learn C#...if you want to develop desktop apps.

With proper set of libraries memory in standard C++ can become as easy as managed (smart pointers). Some C++ widget libraries are as easy to use as C#.NET. However it will probably perform worse than C# due to several abstraction layers. And with C++ you need to learn non-standard libraries. With .NET most of the components that you need are standard.
C is ancient and does not have STL. It demands you to be smart, but I doubt the advantages of it.

I need something pretty powerful and I would like to be able to create apps with Windows GUI's.
Well C is pretty powerful so that would would handle that criteria but something like C# and WPF would make life so ,uch easier if you're aiming to GUI apps.

Without C/C++/C# experience start with C. Edit: Ok, start directly with C# or C++ don't lose time. You cannot seriously code Windows desktop applications with C anymore, it's just to painful.
Then move to Object oriented languages to get something more powerfull.
If you wan't to stay far from windows plateform, C# is not the better option, or check out the Mono plateform.
IMO, C# is far more advanced than C and C++, you will build big application faster. WPF librarues will give you nice UI without windows style (but only on windows systems...)

Are you planning to make gui based applications for windows? Depending on what, I recommend VB. However, given your choices, I would pick C#.