I have been coding exclusively for a while now on Linux with C++. In my current job, it's a Windows shop with C# as main language. I've retrained myself to use Visual Studio instead of emacs ( main reason is the integrated debugger in VC, emacs mode in VC helps ), setup Cygwin ( since I cannot live without a shell ) and pickup the ropes of managed language. What tools, books, website ( besides MSDN ) or pitfalls do you think I should check to make myself a more efficient Windows/C# coder?
The first things to consider when switching from C++ to C# the fact that mostly share some of the surface syntax, but the difference of programming paradigms gets bigger and bigger as you dig in more into .Net.
Get to know the C# core programming paradigms before starting to program else you might fall in the trap of writing C++ programs in C#, which isn't the best idea by long stretch.
The most important things to get accustomed to are:
Automatic memory management and garbage collection including the dispose pattern. Learn the basics and pitfalls.
What are classes, interfaces, structs and primitives in .Net, and how they behave compared to C++.
Events, delegates, properties, lambda expressions all of which are somewhat new concepts when coming from C++.
.Net generics and differences between templates.
strings, arrays, custom attributes, reflection, exceptions and threading basics in .Net, all of these are heavily used everywhere in .Net, and you must learn their intricacies to use them effectively.
GUI programming in Winforms and ASP.Net (and maybe after there WPF), components, controtrols, databinding. The .Net GUI model.
First start with a generic .Net book that introduces you to all of these concepts. I recommend a book over reading tutorials and articles first of all so you can have a big complete picture of .Net at the end. Articles on the internet might not achieve this.
Best generic .Net book I've read:
Professional C#, 3rd edition. by Simon Robinson, Christian Nagel, Karli Watson, Jay Glynn, Morgan Skinner, Bill Evjen
And second, since you're from a C++ background, and you are used to working close to the metal and thinking in way that is close to how hardware works (raw memory management (pointers, mem allocations, etc) I can only recommend one book that will really demystify what .Net is and what it does :
CLR Via C# by Jeffrey Richter
I can't stress enough how good this book is for every .Net developer, especially when coming from C++ and at the same time being one of the best .Net books I've read. The book is a pure pleasure to read and covers topics from :
.Net execution model (from MSIL to native code)
Memory management (how the .net runtime and garbage collector manages memory, heap layout, memory generations, finalization, large object heap)
Designing types
Assembly loading, reflection, application domains
and many more ...
This is my best advice I could give to anyone on their way to become an expert C# developer in the shortest time possible.
Since you already know how to program in C++, check out:
A Programmers Introduction to C# 2.0, by Eric Gunnerson and Nick Wienholt
Nice balance between language reference and general .net information.
Similarly:
Essential .NET, Volume I: The Common Language Runtime by Don Box and Chris Sells
Really interesting "under the covers" net book (but written for .net version 1 so may be a little out of date).
My background was predominantly C/Unix and Python with some java and dusty 2000-vintage VB6 when I first used C#. I was familiar with managed runtimes from the work I had done with Java and the .Net API's have a somewhat similar look-and-feel to earlier MS API's.
I found Troelsen's Pro C# and the .Net 2.0 Platform to be a really good C#/.Net resource. There are more recent editions out now.
Check out petzold's dotnet book zero. This might help.
Read about garbage collection in .Net. People coming from C++ land are used to the explicit memory allocation and management. In C# explicit memory management is virtually non-existing.
Another topic you should check out is the difference between C# generics and C++ templates. I don't have a good link for that one, though.
Depending on the product you are working on, you might have to resort to calling Win32 API functions from C#. This is done through P/Invoke, so you might want to read a bit about it as well. And if you have to actually use it, http://pinvoke.net is very useful collection of C# declarations for most of the Win32 APIs.
You might also want to learn at least the basics of COM, as very often C#/.Net applications choose/need to reuse components from third party vendors, which are often implemented as COM components. COM is a complex topic though. My favorite books on COM and Essential COM by Don Box and Professional DCOM by Roger rimes. I would borrow these from a library, as all you need to read are the first few chapters (unless you want to go in depth).
A basic understanding of windows, messages and message queues is necessary, if you are going to write client applications. You will be using Winforms of WPF/XAML for these, and both technologies do a good job of isolating the details from you; however to be able to write good code you need to know what is going behind the scenes. I am not sure what a good book would be for that, but MSDN has lot of information.
Get yourself a copy of Resharper. It's probably the single best productivity tool out there for straight up coding.
Shouldn't be the base the CLR? And shouldn't it be unimportant which .NET language is used? If I look through the .NET docs I can decide if I'd like to see the stuff in VB.Net, C# or C++. So if you know C++ why shouldn't you use "managed C++"?
Regards
Friedrich
Related
I like making music using mostly my computer and especially love using synthesisers. There is a wide range of synthesiser plugins available online which are quite awesome. I have downloaded the VST (Virtual Studio Technology) SDK which is the platform that most plugins I know of use.
I would like to know if you can use the SDK on the .Net framework to write plugins; the only documentation and tutorials I could find is for C++ and I'm not that trusted with C++. I could learn to use C++, I taught myself C# in a week, but to use an unknown language and to learn other new concepts don't seem like a good combination.
Could anyone just give me pointers in the right direction on how to get started and even if it is possible to program it using .Net?
Regards Charl
Many beginners find VST.NET the perfect choice to start off with. It comes with some samples and with VS2008/VS2010 project templates that yield working plugins. So its a great way to start.
VST.NET provides a framework that structures and groups the VST API into manageable pieces. Out of the box it provides support for common functionality such as plugin parameters and programs.
So drop by at the VST.NET codeplex site and we'll help you get started.
BTW: To my knowledge the noise project has been abandoned and although VST.NET might not appear to be very active, I still continue to react on the questions posted on its codeplex site.
I second obiwanjacobi's sentiment. VST.Net is about the only .Net VST bridge out there that I know of and the community is great. It's an excellent framework.
https://vstnet.codeplex.com/
As for the statement: "doubt .NET platform would be adequate concerning the raw performance that a VST plugin requires". This is entirely untrue. My tests have shown that on a decent computer, .Net can very easily handle basic synthesis without even raising the CPU level above a few percent. Of course, it's not going to match C++'s performance for very complex synthesis, but in cases like this, there's no reason why you can't fall back on C++ to do the more complex stuff. In fact that is where Vst.Net excels. It would allow you to build very complex synthesis as a VST, and then leverage that in .Net.
At the same time, I think you'd be hard pressed to say definitively that .Net couldn't do very complex synthesis as well. I haven't really tried, but there's no real obstacles when you pay attention to the performance of your code, which would go for any programming platform.
On top of all that, there is now .Net Native to add to the picture. .Net Native has the potential to be AS fast as C++.
I remember hearing of noisevst and VST.NET, two C# wrappers for the VST API but I don't know how stable they are. And I really doubt .NET platform would be adequate concerning the raw performance that a VST plugin requires.
So I would recommend learning a little bit of C++. Yes, C++ is so big and complex that nobody on earth knows every feature of it. But for plugin development purposes all you need to do is to implement a couple of methods. You can start from the provided samples in the VST API. Audio DSP code wouldn't look much different if you'd use C#, C++ or any other mainstream language anyway.
If you also want to implement a GUI for your plugin, that's where the things start getting hairy. VSTGUI is simple but lacks many features. I can recommend WDL's iPlug framework but that would require a little more than basic C++.
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 anyone attempting to implement C# for the JVM? As a Java developer, I've been eyeing C# with envy, but am unwilling to give up the portability and maturity of the JVM, not to mention the diverse range of tools for it.
I know there are some important differences between the JVM and CLR but is there anything that is a showstopper?
There are very significant differences between the CLR and the JVM.
A few examples:
Java doesn't have user-defined value types
Java generics is completely different to .NET generics
Many aspects of C# depend on elements of the framework - delegates etc. You'd need to port the library as well, even for language aspects.
Java doesn't support things like properties and events at a JVM level. You could fake some of this, but it wouldn't be the same.
I don't believe Java has any equivalent to pass-by-reference parameters, even at the JVM level
Subtleties to do with the different memory models would quite possibly bite, although I'm not sure how much is in the C# spec.
Unsafe code in general probably isn't possible in Java
Interoperability with native code is very different between JNI and P/Invoke. This probably isn't much of a problem for you.
You'd have to fake operator overloading and user-defined conversions
You could probably port a lot of C# - but you'd be left with a pretty unsatisfactory experience, IMO.
Going the other way, are you aware of IKVM? It allows you to run Java code in .NET.
Visit http://code.google.com/p/stab-language
The code below if a Stab language code for JVM
using java.lang;
using stab.query;
public class Test {
public static void main(String[] args) {
// Sorts the arguments starting with "-" by length and then using the default
// string comparison
var query = from s in Query.asIterable(args)
where s.startsWith("-")
orderby s.length(), s
select s;
foreach (var s in query) {
System.out.println(s);
}
}
}
Bytecode transpilers
Grasshopper can take a CLR bytecode and transpile it for JVM. Intended primarily for web apps, it does not provide e.g. JVM implementation of Windows Forms classes. Seems somewhat dated, though. The web talks about ASP.NET 2.0, Visual Studio 2008 and so on. First mentioned by #alex
XMLVM can take CLR or JVM bytecode as input and produce either as output. Additionally it can output Javascript or Objective-C. No releases yet, only Subversion. "Experimental development version that is not to be used in a production environment."
IKVM goes in the other direction than OP wants. It provides a JVM implementation running on CLR, a JVM to CLR bytecode transpiler and a CLR library method stub generator for Java. http://www.ikvm.net/uses.html Mentioned by #Jon Skeet
RPC
Why not have CLR and JVM running alongside and make the communication as much frictionless as possible? This is not what the OP wants, but some other answers are already quite off topic in different ways, so let's cover it.
RabbitMQ, has a free option, it is a RPC server written in Erlang with API libraries for C#, Java and more.
jnBridge, the licence may be too expensive for some prospective users.
gRPC, and similar modern RPC libraries offer wide language support, code generation for client libraries in these languages, language independent wire format for data, advanced features like cascading call-cancellation and so on.
Programming languages
Write once, run everywhere ;)
Haxe, compiles to C#/CLR, Java/JVM, Javascript, Flash, Python, … Provides interop mechanisms for each of the target languages. Can be thought about as an ActionScript3 successor to some degree. Seems pretty solid stuff, with at least one company actually depending on it. Much more trustworthy than Stab, mentioned next.
Stab brings some C# features and Java interoperability. Not very useful, you get some C# features, but what you interact with is Java code which does not use them. https://softwareengineering.stackexchange.com/a/132080/45826 The language is relatively obscure, possibly abandoned, with little promise to become better. First mentioned here by #Vns.
Gust of fresh air for the JVM platform ;)
Scala, Kotlin, others, are fairly nice languages running on top of JVM which bring features that a C# programmer may miss in Java. Especially Kotlin feels like a reasonable alternative to C# in the JVM world. Scala may be a bit too large language for a programmer to get comfortable with in a short time.
Mono
That is certainly an option too. Why transpile to JVM if Mono can run it as it is. First mentioned by #ferhrosa
NEW YORK — Nov. 12, 2014 — On Wednesday, Microsoft Corp. reinforced its commitment to cross-platform developer experiences by open sourcing the full server-side .NET stack and expanding .NET to run on the Linux and Mac OS platforms.
According to this press release from which the quote comes, Visual Studio 2015 will add Linux/Mono as a supported platform.
This is a blog written by the Mono project people about it, from the other side: .NET Source Code Integration (November 2014).
.NET Core
A Windows/Linux multiplatform version of (some of) .Net governed by Microsoft. 'nuff said https://github.com/dotnet/core.
Conclusion
It would be now necessary to give these tools/frameworks a try and see how much friction there is. The OP wants to write in C# for the JVM, which may actually work quite well using Grasshopper.
Doing this with the goal to mix C# and Java world libraries in a single codebase may not work so well.
Sources
http://blog.pluralsight.com/new-course-making-java-and-c-work-together-jvm-and-net-clr-interop
It might be simpler to write a converter from IL to bytecode. That way you'd automatically get support for any .NET language on the JVM.
However, this is such an obvious idea that if this hasn't already been done, it's probably extremely hard, or hard to do well/usefully.
Look at Grasshopper. It is a Visual Studio-based SDK and patented .NET to Java converter that enables you to run .NET Web and server applications on Linux® and other Java-enabled platforms.
An option for cross-platform development in C# could be mono: http://www.mono-project.com/
You can use a source-to-source compiler to translate C# into a language than runs on the JVM. For example, there are several C# to Java converters that would allow C# applications to run on the JVM after being translated into Java.
This answer may be late for you, but this one is just new. You may want to checkout Kotlin programming language. It offers the syntactic sugars which C# has and its the closest to C# syntax too, other than any Non-Java JVM language. Its from JetBrains.
I can see two reasons why this isn't getting much enthusiasm.
The first thing to realise is that, when it comes to the actual features of the language, C# and Java are very close. Not only are C# amd Java close, they are also moving in similar directions. There are some features that the JVM won't currently support out of the box, but that's not the real problem. You can always fake what is missing. I think people prefer waiting for Java to get some more sugar, than to create an Almost-Java from scratch. By the time the port is ready, Java may have decided to catch up.
Secondly, the reason why developers prefer C# isn't so much the language itself, but the tools around it, their two-way relationship with C# and how Microsoft supports the whole thing. For example, the C#-XAML combo is friendlier than JavaFX, because C# and XAML were hacked for eachother (e.g. partial classes in C#, bindings in XAML and more). Using C# on JavaFX doesn't improve much. To get the C# experience on the JVM, you need to also port the tools, and that's a much bigger project. Not even Mono will bother.
So, my advice to a Java developer, who wants to use a fancier language ontop of familiar tools, is to check out the existing JVM languages.
Mono is an option too, but I have always been skeptical of it. Even though it is C#-.NET and cross-platform, things built with Microsoft's tools won't generally work on Mono. It is essentially its own thing. We'll see what happens now that Microsoft said they'll be collaborating.
In a progression of languages, I have been learning C and C++. Now I would like to learn C#. I know there are some drastic differences between them - such as the removal of pointers and garbage collection. However, I don't know many of the differences between the two.
What are the major differences that a C++ programmer would need to know when moving to C#? (For example, what can I use instead of STL, syntactic differences between them, or anything else that might be considered important.)
C# for C++ Developers is a great place to start. It is a table that lists the most important comparisons between the two languages.
Once you have explored some of these differences, you might choose a self-contained project you have written in the past in C++, and re-write it in C#. In your first pass, you will probably just end up translating directly across, using the same design and algorithms. As you become more comfortable with C#, you will recognize ways to take advantage of language features only available in C#, as well as the incredibly versatile .NET Framework.
I think it's important to note that pointers weren't really removed from C#, but that they still exist, they are everywhere, and they are called references.
Charles Petzold has a .NET Book Zero that is designed specifically for the C/C++ Windows programmer who wants to learn C# and .NET. It is a free PDF download from his site. All of the source code used in the book is available as a separate Zip-file download.
There was a similar question that has lots of pointers (pun inteded :-)) and resources about the differences between C++ and C# and what to pay attention when learning transitioning - Linux/C++ programmer to Windows/C# programmer.
Look at the Generic collections and LINQ (all the related technology to LINQ) for STL like functionality.
The number one thing to note is that ~/Destructor is c++ is nothing like the ~/finalizer in c# -- See IDisposable/using.
I learned Java in college, and then I was hired by a C# shop and have used that ever since. I spent my first week realizing that the two languages were almost identical, and the next two months figuring out the little differences. For the most part, was I noticing the things that Java had that C# doesn't, and thus was mostly frustrated. (example: enum types which are full-fledged classes, not just integers with a fresh coat of paint) I have since come to appreciate the C# world, but I can't say I knew Java well enough to really contrast the two so I'm curious to get a community cross-section.
What are the relative merits and weaknesses of C# and Java? This includes everything from language structure to available IDEs and server software.
Comparing and contrasting the languages between the two can be quite difficult, as in many ways it is the associated libraries that you use in association with the language that best showcases the various advantages of one of another.
So I'll try to list out as many things I can remember or that have already been posted and note who I think has the advantage:
GUI development (thick or thin). C# combined with .NET is currently the better choice.
Automated data source binding. C# has a strong lead with LINQ, also a wealth of 3rd part libraries also gives the edge
SQL connections. Java
Auto-boxing. Both languages provide it, but C# Properties provides a better design for it in regards to setters and getters
Annotation/Attributes. C# attributes are a stronger and clear implementation
Memory management - Java VM in all the testing I have done is far superior to CLR
Garbage collection - Java is another clear winner here. Unmanaged code with the C#/.NET framework makes this a nightmare, especially when working with GUI's.
Generics - I believe the two languages are basically tied here... I've seen good points showing either side being better. My gut feeling is that Java is better, but nothing logic to base it on. Also I've used C# generics ALLOT and Java generics only a few times...
Enumerations. Java all the way, C# implementation is borked as far as I'm concerned.
XML - Toss up here. The XML and serialization capabilities you get with .NET natively beats what you get with eclipse/Java out of the box. But there are lots of libraries for both products to help with XML... I've tried a few and was never really happy with any of them. I've stuck with native C# XML combined with some custom libraries I made on my own and I'm used to it, so hard to give this a far comparison at this point...
IDE - Eclipse is better than Visual Studio for non-GUI work. So Java wins for non-GUI and Visual Studio wins for GUI...
Those are all the items I can't think off for the moment... I'm sure you can literally pick hundreds of items to compare and contrasting the two. Hopefully this lists is a cross section of the more commonly used features...
One difference is that C# can work with Windows better. The downside of this is that it doesn't work well with anything but Windows (except maybe with Mono, which I haven't tried).
Another thing to keep in mind, you may also want to compare their respective VMs.
Comparing the CLR and Java VM will give you another way to differentiate between the two.
For example, if doing heavy multithreading, the Java VM has a stronger memory model than the CLR (.NET's equivalent).
C# has a better GUI with WPF, something that Java has traditionally been poor at.
C# has LINQ which is quite good.
Otherwise the 2 are practically the same - how do you think they created such a large class library so quickly when .NET first came out? Things have changed slightly since then, but fundamentally, C# could be called MS-Java.
Don't take this as anything more than an opinion, but personally I can't stand Java's GUI. It's just close enough to Windows but not quite, so it gets into an uncanny valley area where it's just really upsetting to me.
C# (and other .Net languages, I suppose) allow me to make programs that perfectly blend into Windows, and that makes me happy.
Of course, it's moot if we're not talking about developing a desktop application...
Java:
Enums in Java kick so much ass, its not even funny.
Java supports generic variance
C#:
C# is no longer limited to Windows (Mono).
The lack of the keyword internal in Java is rather disappointing.
You said:
enum types which are full-fledged classes, not just integers with a fresh coat of paint
Have you actually looked at the output? If you compile an application with enums in in then read the CIL you'll see that an enum is actually a sealed class deriving from System.Enum.
Tools such as Red-Gate (formerly Lutz Roeder's) Reflector will disassemble it as close to the orginal C# as possible so it may not be easily visible what is actually happening under the hood.
As Elizabeth Barrett Browning said: How do I love thee? Let me count the ways.
Please excuse the qualitative (vs. quantitative) aspect of this post.
Comparing these 2 languages (and their associated run-times) is very difficult. Comparisons can be at many levels and focus on many different aspects (such as GUI development mentioned in earlier posts). Preference between them is often personal and not just technical.
C# was originally based on Java (and the CLR on the JRE) but, IMHO, has, in general, gone beyond Java in its features, expressiveness and possibly utility. Being controlled by one company (vs. a committee), C# can move forward faster than Java can. The differences ebb and flow across releases with Java often playing catch up (such as the recent addition of lambdas to Java which C# has had for a long time). Neither language is a super-set of the other in all aspects as both have features (and foibles) the other lacks.
A detailed side-by-side comparison would likely take several 100s of pages. But my net is that for most modern business related programming tasks they are similar in power and utility. The most critical difference is probably in portability. Java runs on nearly all popular platforms, which C# runs mostly only on Windows-based platforms (ignoring Mono, which has not been widely successful). Java, because of its portability, arguably has a larger developer community and thus more third party library and framework support.
If you feel the need to select between them, your best criteria is your platform of interest. If all your work will run only on Windows systems, IMHO, C#/CLR, with its richer language and its ability to directly interact with Windows' native APIs, is a clear winner. If you need cross system portability then Java/JRE is a clear winner.
PS. If you need more portable jobs skills, then IMHO Java is also a winner.