We Keep Coding

Is it possible? GUI in c# , app in C++

Is it even possible to create GUI layer in C# and rest of application in C++? If I am not wrong one of antyvirus software had GUI made in Delphi. How it could be done ?

You have several options for doing it, including:
Use P/Invoke to call into the C++ DLL from C#.
Expose a COM interface from the native code, and call it from C# using COM interop.
Write a native Windows service and call into it from managed code.
Use C++/CLI to write a managed library in C++, which you can easily link to from C#.
If you're starting from scratch, option 4 is probably your best option. (Aside from just writing the whole thing in C#, that is.) The first three options all involve some additional wrangling and overhead, and probably aren't worth the hassle if you don't have a compelling reason such as needing to interact with an existing native library or having some need for a service-oriented architecture.

If you write your business logic in C++/CLI, and your UI in C#, it shouldn't be a problem. If you want to write in pure ANSI C++, you might have to write C++/CLI wrappers around the objects you want to expose to C#.

write the app logic in c++ dll, then use pinvoke from c# to talk to the dll.

See this answer. It seems to answer your problem

Converting C++ solution to a class library

this might be a simple question, but as I have zero experience in C++ and my boss has given me a C++ solution work with I need to ask this question.
I have a C++ solution that needs to be turned into a .NET class library which can then be used in another .NET solution done in C#.
Is this even possible???
Cheers

You have to wrap all C++ classes that should be visible in .NET in C++/CLI classes.
Read this
There are also some automated tools to do this, but I never used these (I don't really trust them). Depends on how many C++ classes do you have, and how complex they are. Writing the wrappers is mostly straight-forward once you get used to some oddities of C++/CLI.

It depends of the output of the C++ solution. Is it an application (*.exe) or a library (*.dll)?
If it is a library (*.dll) you can use Platform Invoke Tutorial to call its functions out of managed code. A lot of examples of calling Win32 native functions can be found at http://pinvoke.net/.
If your result is an application it could be possible, that it has a COM interface. In that case you could use the COM interop to communicate with your application.
Last but not least you could write with C++/CLI a managed wrapper around your C++ functionality. But this is a lot of work and has many pitfalls.

Should a WPF application be written in C++/CLI or C#?

WPF applications are, at its core, managed applications? Right? So, I have to choose between using managed C++ or managed C#. I experimented with managed C++ years ago. It seemed to be not quite be ready for primetime. I'm guessing Microsoft has put more effort into managed C# than managed C++. So, it seems like using managed C# is the best alternative between the two. Is this the case? What experiences have you had with WPF in either language? Thanks in advance.

Managed C++ has been replaced by C++/CLI, and "managed C#" is just C#.
I would strongly recommend you to use C# for a new project, and use C++/CLI only when needed. C# has a better support, has a larger user base, and is easier to work with inside Visual Studio 2010.
Additionally, keep in mind that C++ and C++/CLI are two different languages. For my first .Net project, I chose C++/CLI because I already knew C++, and this was a very bad idea: the learning curve from C++ to C++/CLI is similar to learning C# from C++: don't fall into that trap.

C++/CLI was only really made to support writing interop layers between unmanaged code (i.e. native C/C++) and managed code. For "heavy lifting", you should definitely use C# (or VisualBasic.NET).

You can use managed C++ for your backend but, on inspection, VS (I'm using 2010 Ultimate) doesn't have any in-built templates for a C++ WPF application - only C# or VB.
I'm sure you could force it to work if you wanted to, but I'd suggest you use C#.

C# is the most used, so if you have trouble, there is more online support for C#. C# also has better support by Microsoft. It's overall just a more finished product, even now. If you really don't care yourself, i'd go with C#.

In terms of the backend, they both run on the CLR and both capable of the job. Really it just comes down to what you're most comfortable with. If you're not sure, experiment with both.
Use whatever feels most productive.
Edit:
As has just been pointed out to me though, it seems support for WPF templates (and possibly even intellisense) just isn't there for C++. So in that case I guess I'd have to recommend C#.

IMO without a doubt C# (or VB/F#).
C++/CLI is great when crossing the border of managed world and a c++ library. Complexity is higher though as subtle issues arises from the fact that one combine a managed language and an unmanaged.
Compile times are longer though as well in C++/CLI especially since the code templates are modelled after how the C# compiler works not on how the C++ compiler works.

C++/CLI: why should I use it?

I'm pretty familiar with C++, so I considered learning .NET and all its derivatives (especially C#).
Along the way I bumped into C++/CLI, and I want to know if there is any specific use for that language? Is it just suppose to be a intermediate language for transforming from native C++ to C#?
Another question that popped to my head is why are there still so many programming languages in .NET framework? (VB, C++/CLI, C#...)

Yes, C++/CLI has a very specific target usage, the language (and its compiler, most of all) makes it very easy to write code that needs to interop with unmanaged code. It has built-in support for marshaling between managed and unmanaged types. It used to be called IJW (It Just Works), nowadays called C++ Interop. Other languages need to use the P/Invoke marshaller which can be inefficient and has limited capabilities compared to what C++/CLI can do.
If you need to interop with native C++, classes that have instance functions and need the new and delete keywords to create/destroy an instance of the class then you have no choice but use C++/CLI. Pinvoke cannot do that, only the C++ compiler knows how much memory to allocate and how to correctly thunk the this pointer for an instance function.
The .NET framework contains code that was written in C++/CLI, notably in System.Data and WPF's PresentationCore. If you don't have unmanaged interop needs or don't have to work with a legacy code base then there are few reasons to select C++/CLI. C# or VB.NET are the better choices. C++/CLI's feature set got frozen around 2005, it has no support for more recent additions like lambdas or Linq syntax. Nor does the IDE support many of the bells and whistles available in the C# and VB.NET IDEs. Notable is that VS2010 will initially ship without IntelliSense support for C++/CLI. A bit of a kiss-of-death there.
UPDATE: revived in VS2012, IntelliSense support is back. Not in the least thanks to C++/CX, a language extension that simplifies writing WinRT apps in C++. Its syntax is very similar to C++/CLI. The Windows Forms project templates were removed, the designer however still works. The new debugging engine in VS2012 doesn't support C++/CLI, you have to turn on the "Managed Compatibility Mode" option in Tools + Options, Debugging, General.

First C# is not a 'derivitive' of .NET. .NET is not a language, it is an application framework and class library based on the CLR, for which a number of languages exist.
That said, the most compelling reason to use .NET is that it is a well designed class library and a much easier way to develop for Windows than Win32 or MFC. However I personally decided that I'd rather learn a new language altogether than learn extensions to an old one, and because C# was designed from the ground up to work with .NET, I suggest that is the language of choice for .NET.
C++/CLI is useful is you want to use .NET with some legacy code, and I have used it for creating Windows Forms GUIs and gluing them to existing application code. Its other raison d'etre is that it is the only .NET language that supports mixed managed and native code in a single load module, so it is good for both performance and reuse of legacy code.
With respect to the number of languages, Microsoft want every Windows application to be based on .NET because it is better for the security and stability of their OS. The only way that will happen is by supporting multiple languages. Think of .NET as an application platform or OS API, and then the question makes less sense; there will be many languages for .NET for the same reason as there are many languages for any platform. Those reasons are many, including commercial advantage, application fit, politics, supporting existing developers, choice and no doubt more.

Microsoft has changed its stance on this a few times. It was originally intended as a full-fledged language, essentially something that they wanted all native developers to move to, abandoning native C++ as much as possible.
Then a few years ago, they realized that this simply wasn't what their customers wanted. Developers who are moving to .NET anyway generally jump to a language like C#, and the rest have reasons to keep their code in the native world, so they stay with C++.
So now, Microsoft intends for C++/CLI to be a "bridge" between native C++ code and managed code written in some .NET language. It's no longer a language they recommend you switching your entire codebase to.

It's indeed mainly intended as intermediate language to easily link .net code with native, unmanaged C++. Do yourself a favour, don't use it if you don't need to. C++/CLI syntax is a mess.
Regarding your second question ... I think today C# is the dominant language in .net, but not everyone likes its style and paradigms. .net's architecture makes adding new languages easy (see F#, which aims at functional programming).

I've used C++/CLI to create .NET API's for some unmanaged C++ libraries. Passing and marshalling of parameters takes some getting used to (depending on used types), but once you've got the hang of it, it's really a nice way to bridge the gap between the managed and unmanaged world.

I have not looked at C++/CLI but it harnesses the .NET world - think of it as a in-between C++ and C# where you have the best of both worlds. It could be useful in situations where you want to use C++ that can easily access .NET objects and it's core BCL. Have a look here at this article discussing the primers of C++/CLI. Unfortunately, I have not heard of a Managed C++ application as it has ruffled a lot of C++ friends on the syntax side of things and lost gathering of followers who went back to the unmanaged world of C++.
Hope this helps,
Best regards,
Tom.

for me, i have to use it when there is no other way to reuse c++ class

This post is old but the most important message in my oppinion is missing: You use it for being able to see and manipulate the source code of C++ frameworks you use in C#. Examples: You don't use compiled OpenCV binaries, instead you got the OpenCV sourcecode in your solution and can add simple some Extensions, or deep check how some behavior exists. Or in finanicial math you could QuantLib Sources, and so on. This is much better than having already compield libraries that act as black boxes in a lot of ways. C++/Cli in .NET solves this.

Just so you know. Unless you specify the code to be compiled as unmanaged, when compiling with CLR support it will be compiled as managed code.
While CLI C++ is nice. I find it a pain to code in. There is just something about it that makes me not want to program in it. It isn't even the "^". It is like using a broken .net. I spent 40 minutes coding something fully managed in it that took me 10 minutes in C#. I mean, sometimes I just give up and use C# because it frustrates me when coding in it. I mean if you are going to use .net you might as well use C#(over CLI C++).

Is C++ .NET dying?

I heard somewhere that Microsoft will be focusing their efforts on C# rather than C++ for the .NET platform. I can see signs of this being true because of the GUI designer that was available for C# but not C++.
So I would like to know if C++ in .NET is dying and if it will continue to be second to C# in the future.

If you are targeting the .NET framework in application development then yes C++/CLI is a second class citizen compared to C#. C# was specifically designed as the language for .NET framework meanwhile C++/CLI extension is there to allow developers to bridge native and managed code.
However do not confuse C++ with C++/CLI (C++ .NET is the same thing...). C++ is alive and well in areas such as the kernel, games, high-performance and server apps (e.g. SQL server) all of which are unlikely to change. On the other hand most .NET 'GUI stuff' won't use C++.

Managed C++ never really got to be what MS thought it would be. C# could do (nearly) the same thing, with a lot more intuitive and user-friendly syntax.
Apart from that, C++/CLI will not be left unsupported for a long time, as it's the easy way to create interop between .NET assemblies and native C++ assemblies. That's about all it's used for though (I'm sure there's a 0.001% of C++/CLI developers out there who disagree :P ).

C++/CLI is just the way Microsoft attracts native C++ developers to .NET. It was like a intermediate layer between native C++ and C#, but I'm pretty sure that developers prefer to choose either native C++ or C#.
Microsoft will not let C++/CLI die, at least in near future, however, without community support, C++/CLI will not be able to grow.
In this generation, not growing means close to dead.

I'm afraid it is.
The reason for this is not C# (which doesn't bring anything special and although it's a new language it doesn't lead in new language features but merely copies features of others - generics).
It's mainly because the first attempt of MS to enable C++ for .NET platform - Managed C++ - was a disaster.
After this they hired Herb Sutter, C++ guru, which made fantastic job designing Managed C++ replacement callled C++/CLI.
Why and how much C++/CLI design is superior to Managed C++ design you can find out by reading A Design Rationale for C++/CLI written by Herb.
By the way, Herb made vc compiler one of the best standard-conforming compilers for Windows after years of it being the worst one in regard to standard conformance.

No. It was born dead. It always has been treated as a second class citezen with no vitality roadmap.

i think YES , its dying , actually it already died ;) , coz there arent lots of people who use it , they use whether c++ or c#.
see this

I don't think it's necessarily going away, but the reason for using it almost always comes down to whether or not you need the performance benefits that come with it. If C# can do the same thing at 90% of the efficiency of C++, isn't that really good enough?