Develop Reference

Performance - How does linking C-sharp and C++ effect on Performance?

I'm just about to start with my new project. I'd been working with C++(with Qt )and C#. And so I'm pretty much familiar with both the languages.
I've always used them separately, C# for windows and C++ for cross-platform applications. But this time I wanted to do something different. I wanted to link them and use them together.
I'll be using C# for the GUI development and C++ Back-End.
So now, all I wanted to know that how will this effect the performance of my application ?
Best Regards,
Samarth Saxena.

The performance of the interop layer is good enough that it won't change the overall performance -- that will depend on how well you write your code, whether you do useless copies, concatenate strings in a loop when you should be using StringBuilder, etc.
Still, the cost isn't zero for p/invoke and COM interop, so you want to avoid chatty interfaces (e.g. the interop call should fill a buffer with an entire array, rather than forcing you to make a p/invoke call for each item).
The final interop method, C++/CLI "It Just Works", actually can have a negative cost compared to pure C#. That's because it's the method that the .NET runtime uses internally (whenever the metadata in mscorlib.exe has the internalcall flag), and if adding C++/CLI code to your project saves more managed/native transitions inside .NET itself than it adds, it will save time.

If you use Microsoft's "Dot Net" flavor of C++, you will be fine. Performance will generally be as good as it would be if you wrote everything in C# or everything in C++. That's because both languages will run in "managed" mode, and they will share the same runtime. (The Dot Net runtime.)
However, if you want to use managed C# with good old regular (unmanaged / native) C++, you are going to have a certain performance penalty, due to all the managed-to-native and native-to-managed transitions that need to be done when placing calls between the two, and all the marshalling of data that this implies.
Google for "pinvoke" to see what pains people have to go through in order to invoke C++ from C#. Still, it is quite cool that "pinvoke" exists, and it makes things relatively easy.

Managed C++ (C++/CLI) vs C#/VB.NET

I have worked extensively with C#, however, I am starting a project where our client wishes all code to be written in C++ rather than C#. This project will be a mix between managed (.NET 4.0) and native C++. Being that I have always preferred C# to C++ for my .NET needs, I am wondering if there are any important differences I may not be aware of between using C# and managed C++?
Any insight into this is greatly appreciated.
EDIT Looking at Wikipedia for managed C++ code shows that the new specification is C++/CLI, and that "managed C++" is deprecated. Updated the title to reflect this.

C++/CLI is a full fledged .NET language, and just like other .NET languages it works very well in a managed context. Just as working with native calls in C# can be a pain interleaving native C++ and Managed C++ can lead to some issues. With that said, if you are working with a lot native C++ code I would prefer to use C++/CLI over C#. There are quite a few gotchas most of which could be covered by do not write C++/CLI as if your were writing C# nor write it as if you were writing native C++. It is its own thing.
I have worked on several C++/CLI projects and the approach I would take really depends on the exposure of different levels of the application to native C++ code. If the majority of core of the application is native and the integration point between the native and managed code is a little fuzzy then I would use C++/CLI throughout. The benefit of the control in the C++/CLI will outweigh its problems. If you do have clear interaction points that could be adapted or abstracted then I would strongly suggest the creation of a C++/CLI bridging layer with C# above and C++ below. The main reason for this is that tools for C# are just more mature and more ubiquitous than the corresponding tools for C++/CLI. With that said, the project I have been working on has been successful and was not the nightmare the other pointed to.
I would also make sure you understand why the client is headed in this direction. If the idea is that they have a bunch of C++ developers and they want to make it simpler for them to move to write managed code I would posit to the client that learning C# may be less challenging then learning C++/CLI.
If the client believes that C++/CLI is faster that is just incorrect as they all compile down to IL. However, if the client has a lot of existing or ongoing native C++ development then the current path may in fact be best.

I've done a project with C++/CLI and I have to say it was an abomination. Basically it was a WinForms application to manage employees, hockey games, trades between teams, calendars etc, etc...
So you can imagine the number of managed controls I had on my forms: calendars / date time pickers, combo boxes, grids etc.
The worst part was to use only C++ types for my back-end, and use the managed types for the front-end. First off you can't assign a std string to a managed string. You'll need to convert everything. Obviously you'll have to convert it back...
Every time I needed to fill a grid, I serialized my C++ collections to something like a vector<std::string>, retrieve that in my UI library and then looped trough that and made new DataGridRow to add them to the grid. Which obviously can be done in 3 minutes with C# and some Linq to SQL.
I ended up with A+ for that application but lets be honest it absolutely sucked. I just can't imagine how pathetic the others app were for me to get that.
I think it would've been easier if i used List<Customer>^ (managed List of some object) in my C++ instead of always converting everything between vectors of strings. But I needed to keep the C++ clean of managed stuff.
/pissedof

From using all three areas (.NET, C++/CLI and C++) I can say that in everyway I prefer using .NET (through C# or VB.NET). For applications you can use either WinForms or WPF (the latter of which I find far better - especially for applications that look far more user friendly).
A major issue with C++/CLI is that you don't have all the nice language features that you get in .NET. For example, the yield keyword in C# and the use of lambda (I don't think that's supported in C++/CLI - don't hold me to that).
There is, however, one big advantage of C++/CLI. That is that you can create a bridge to allow C# and C++ to communicate. I am currently working on a project whereby a lot of math calculations and algorithms have already been written (over many years) in C++, but the company is wanting to move to a .NET-based user interface. After researching into various solutions, I came to the conclusion that C++/CLI was far better for this. One benefit is that it allowed me to build an API that, for a .NET developer, looked and worked just like a .NET type.
For developing an application's front end, however, I would really not recommend C++/CLI. From a usability point of view (in terms of developer time when using it) it just isn't worth it. One big issue is that VS2010 dropped support for IntelliSense for C++/CLI in order to "improve general IntelliSense" (I think specifically for C++). If you haven't already tried it, I would definitely advise checking out WPF for applications.

Android to WP7 absolute newbie question: C# or VB?

I'm going to migrate my Android application into WP7 platform. Android one contains heavy enough calculation stuff (encryption/decryption), plus extensive usage of DB (SQLite) and some graphics (simple) and I'm trying to figure which language to select: either C# or VB
I have some experience both in C# and VB.net, but can't decide which one to select, any clues?

I would recommend C#, based on a couple of factors:
I assume the Android application is written in Java. Between C# and VB, C# is the most similar.
If you are doing lots of calculations, C#'s more terse syntax will probably make the code easier to read. VB is more verbose and thus tends to produce more clutter.
Since you are new to the platform, you will definitely find a lot more resources with C# code examples than with VB.

I went from VB.net to C# and wouldn't ever go back through my own choice!
Aside from the technical differences (see here for just one comparison), it's my personal opinion that C# is more readable, fluent and just plain better.
Do a search on google for heaps of comparisons on why one is better than the other. At the end of the day it's your personal preference... try both and see which you prefer.

There are no technical benefits or drawbacks to choosing either language; the complete set of APIs and platform features are available to you whether you choose C# or VB.NET, so it comes down to whichever you are most comfortable with or want to spend more time with.
The only thing that might sway it one way or another is that (in my opinion) there are more samples, blog posts, and general help written in C# than VB.NET, but that's about the only differentiator I can think of.

If you aren't particularly familiar with either then definitely use C#. By far and way the vast majority of code you will come across in the Web and in books on Silverlight will be written C#.

I'd go with C#, it's a far more popular language. Furthermore, Java to C# is an easier transition.
Edit:
Popularity of a language make's it easier to find information and perhaps more importantly, quality developers.

Choose the language you are more comfortable with.

I would suggest c# because it's more similar to java. So maybe you will manage to save code structure.

C# for sure. C# is a lot more alike Java, and syntax alike much more compatible.
Next to that C# is more popular so more resources for it, and because of the extra time they spend on C# the compiler slightly generates higher performance MSIL.

If you know Java you'll find C# very comfortable to transition to and work with, especially if you're having to maintain older Java code as well as working on the new project. I've worked in situations where I had to work with VB6, VB.NET and C# code within the course of a day and it can be tricky to remember not to use or to use semi-colons or that the variable type goes first or last.

What advantages can I get from learning C++ if I'm mainly a C# Programmer? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
Recently I've started to notice a lot of smirks and generally rude comments whenever I mention C#. Everyone I talk to either says learn Python or learn C++.
Python is a nice language, I get it. But I don't find much use for it right now (for my use cases), and C++ I heard is a faster language (not sure).
So my question is this, what advantage can I get from learning C++ (besides the knowledge and expansion of my horizons), when I mainly program in C#?

The biggest issues are as follows:
C++ is the de facto standard of system AND application programming for the past 20 years
C++ is portable and compilers exist for ~ 95% of all processor architectures.
C++ can enhance your .NET code, by that I mean PInvoke can be done to run optimized code written in C++ -OR- can be used to run code from 3rd parties, allowing you to write custom wrappers etc.
C++ is linux/mac/PSP/Cray II/Random OS from Thailand compliant, it has no issue compiling because it doesn't run through the .NET CLI (which I have to admit is a beautiful piece of art) C# is bound, for now, to Mono implementations and Windows through .NET.
As a professional .NET applications programmer, I love C#, I worship the ground that the architects walked on. But C++ is in my opinion, the most important language you can/will ever learn because it will open more career doors than any other language in the modern industry. If you know C# it will take you a matter of months to learn it. I reccommend Timothy D'Orazi's C++ book if you have an academic software engineering background.
Afterthought:
C++ is a tool, just like C# or a drill or a shotgun (arguably) fit the tool to the task, I'd rather die than write functional code in C++, likewise, I wouldn't do application development in F#, they're all fine langauges. Learn something that interests you! If you want to be a better programmer, learn C++, if you want to be a better application developer, it may be more to your advantage to learn new technologies within the framework you're already working in! You are a C# programmer, have you learned WPF? WCF? what about the features of C# 4.0? Have you mastered lambda functions? expression trees? There are so many directions you can go from here, C++ is just one of them. Ask yourself the following questions:
What can I learn that will add value to me?
What can I learn that will interest me as a developer?
What can I learn that will benefit me in my immediate position?
What can I learn that will help me get into the kind of career path that I want to be in?
You'll find that there will be many answers that overlap for these questions, take your time, find something that interests you and won't be a chore to learn, you'll thank yourself for it 3 months from now.

Short answer: Learning at least some C++ (and some assembly language too) makes you better at leveraging and, perhaps more importantly, debugging the software platform deep underneath your code. This is true regardless of the programming language or OS you're working in.
Long answer:
One of the differentiating factors, IMHO, between good developers and great developers is that the great ones know what's going on under the hood in a piece of software and are capable of quickly drilling down underneath layers of abstraction in the technology stack, since the toughest software problems are often caused by things way down below your code in the stack.
Therefore, I've always recommended that developers, at some point in their careers, spend at least some time learning two languages which are at the bottom of almost every software stack: C/C++ and x86 assembly language. That doesn't mean you need to become an expert in either, but having a working knowledge of things like pointers, registers, memory management, stacks and heaps, un-GC-ed string buffers, leaks, etc. is hugely useful when you need to reach down into the stack to diagnose a problem, to better understand odd behavior, or simply to make smarter decisions as you architect higher-level software, regardless of the language.
An analogy: I became a much better manual transmission driver once I took apart my motorcycle's engine and saw how the clutch worked. That didn't mean I needed to become a motorcycle mechanic, only that it helped my overall driving skills once what was happening inside my bike was not a mystery anymore.
Also, regardless of the language or framework you're working with, for projects that must call directly down into the underlying platform, C/C++ knowledge is very helpful and sometimes required.
Note that I'm deliberately not touching the more contentious question about whether you should be writing entire apps in C++ or not. Other answers have done a great job covering those arguments. Instead, I'm simply making the case that C++ skills will benefit you, regardless of whether you continue writing most of your code in C# (or Java or Python or Ruby or...)

It depends.
The thing I like about C++ is that in some ways, it is a more expressive and yes, more elegant, language than C#. It enables some really nice abstractions (such as generic programming or RAII) that just can't be duplicated in C#.
In those ways, it's an eye-opener. Of course, so are functional languages. So is Python. All of them are worth learning, even if you write all your code in C# now and forever.
Of course, C++ is also an overcomplicated mess, and a far more error-prone language than pretty much anything else. And if you don't know it really well, then it will explode in your face when you least expect it.
Of course, plenty of people will shout PERFORMANCE! when you ask why you should learn C++. I won't. Because in many common cases, C# is going to be as fast or faster as your C++ code. This old exchange between Raymond Chen and Rico Mariani illustrates the performance characteristics of both platforms pretty well.
C++ has the potential to be extremely fast. But it also has a lot of subtle performance pitfalls that mean that most of the time, unless you're some kind of omniscient code-god, your code is going to be less efficient than the equivalent C#.
If you have an interest in programming languages, C++ is a wonderful example of the theory of evolution. ;)
It hasn't grown according to some great predefined plan. It has always improved and adapted one step at a time, according to what would make the language better right now. As a result it is huge, bloated, overly complex, but it is also more expressive than something strictly designed according to a single person's vision, such as C#. C# is designed with an unhealthy obsession with OOP, because that was the cool thing when it was designed.
In C++, OOP sort of drifted out towards the periphery, not so much as a conscious design decision, but because better alternatives turned up.
It's a fun language. And I'd recommend learning it just for the sake of becoming a better programmer. But I'm not convinced that you'll need to actually use it. Of course it will make certain tasks easier (native interop, or programming small programs which for one reason or another can't assume that the .NET framework is installed), but for most cases, you probably won't need it.
That leaves the "become a better programmer" argument, and while that is a valid argument, it is also true for other languages. You should definitely also know a functional language. And Python, or a similar pragmatic, high-level "make it easy for the programmer" kind of language.

I have been C++ developers for last 10 years and last two years, I have been using java for new product development. I have also done some programming on C# just to learn it. Based on my experience I would say C++ is a challenging and high performance language which is good for computer science students to understand programming concept and algorithms. Other usage of C++ would be protocol implementation which doesn't change often E.g implementing SIP Proxy or HTTP Server..
For practice product development where requirements changes often, I would recommend any high level language where developers can focus on application logic instead of reinventing wheel. E.g Recently I started an open source project xcapserver which I was able to do quick prototype in two days using java technologies (Glassfish,REST, log4j, eXist db)but I wanted to lean boost libraries and again it's a protocol which is not expected to change often, so I decided to implement in C++. I spent 4 days just to get the logger working using BOOST::log and another 4 days to fix the thread deadlock issues with Berkeley DB XML.
Another aspect is product maintenance. I have spent days and night to fix memory leaks and corruption and learning curve for new developers is too high versus J2EE or .NET where it's easy to find developers and maintenance is much easier.
In sort, C++ is good programming language which I would recommend to all developers to learn but I don't see much use of it going forward as processors are becoming faster and cheaper so performance is not the reason.

There are reasons to use pretty much any language.
C and C++ have uses in that they are compiled into native code rather than running on a virtual machine. There is a speed advantage and it also means these programs can run without having a 50MB+ framework installed.
Pretty much all games (certainly first person shooters) are written in C or C++.
Is this applicable to you? No idea because I have no idea of what you're trying to achieve.
What will you learn from C or C++? Pointers, memory management and the like. It's quite a different world from more modern garbage collected languages like C#, Java or Python.

Learn C++ so that you can better appreciate C#.

Apart from what others have said:
People do like to see it on resume's.
Learning any language helps you translate that language into C# which makes you more valuable as a programmer.
Learning another language helps you to understand samples using that language, arguably allowing you to draw on a wider range of samples, books, examples, experts.
Wrappers! Learning C++ helps you wrap those pesky C++ dlls for consumption in C#!
That said, there are quite possibly other things you should be learning before C++ if you're a C# programmer who never learned C++ in the first place.

You'd get more utility out of learning a functional language like Clojure, Haskel (or maybe F# given you obviously feel comfortable with CLR). They have a different underlying programming model which will expand your horizons in ways that learning a new syntax will not.
In the other direction, learning C would actually be much more useful than learning C++. That will focus your learning on pointers, memory, and 'close to the metal' topics.

2015 Update
Learn Swift. It will teach you the same use of functional and generative patterns as modern C++ but without the baggage or as many gotchas. It's also semantically a significant overlap with F# so you get a chance to study functional programming. There's a vibrant functional community pushing the bounds of Swift.
Ironically, in my current day job on C# bindings for Realm, I'm still using my C++ skills alongside C# but not much has changed my attitude in the last 6 years.
Original
I speak as a C++ programmer for 15+ years who has spent the last year learning and using C# (and C++/CLI), on top of an ongoing fascination with languages and a broad range of studying other languages to improve my thinking.
I am very very impressed with C# as a language, especially with the improvements in C# 3.0.
I would take the contrary views:
Unless you want employment writing computer games, or relatively low-level components, forget about C++ as a language because there are enough skilled C++ programmers out there and the gaming industry generates a lot more (of presumably varying quality). It is not going to improve your career prospects.
Do invest some time into studying the interesting depths of C#, the implications of operator overloading, how to use unsafe code etc. Pick up a book like the excellent C# in a Nutshell and be able to go through and annotate all the content with deeper explanations of how that idiom might be used.
Learn a dynamic language like Ruby or Python, use it for some real-world tasks such as generating or mangling test files, so you appreciate the simpler language for manipulating files, structures and strings.
Learn F# or another function language and develop a few smirks of your own about the implications of functional languages for parallel processing and clouds :-) In a few years time (or earlier) this will yield huge career benefits when people are scrambling for cloud-savvy programmers. Remember, you haven't learned a new language until you can compare it to the old ones so you need to be able to pontificate about when and where to use F# (or Haskell) instead of C#.

In terms of performance, it is a lot faster. If you have any desire to do game programming or high-performance computing, C++ is a great language for that.
But, I would also say C++ is very difficult to learn. No garbage collector, compile errors that need to be deciphered, and the need for external libraries are all difficulties to overcome.

Regarding C/C++, here are a few things that come to mind out of my own experience.
Learning C/C++ can provide experience working more closely with detailed operating system features and with raw memory. For example, many Audio, Video, and Game applications require this level of access to perform at their best.
Knowing how to interop with components and libraries written in C/C++ is a handy skill. There are many useful libraries out there that still do not have adequate equivalents in C#. TSAPI (telephony), various file format libraries, and legacy components are much easier to work with in C# if you understand their construction in C/C++ and other languages.
If you are working with windows applications, having experience with Win32 through C/C++ allows you to understand how a number of other applications written in non-managed code work; even if you do not have the source code available to you. You can then use P/Invoke more effectively to deal with libraries that would ordinariliy be unavailable or too opaque to handle otherwise.
Many techniques, though potentially black-hat in nature, are tougher to accomplish with C#. Things like DLL substitution, re-writing function entry points, injecting code into other processes, and generating inline assembly code are easier to do with C/C++; though not impossible with C#.
Finally, fine tuned control over un-managed objects is something better suited to code written with C/C++. For example, things like overlapped I/O on windows, some socket library features (ex. UDP Multicast), and device control have more working C/C++ examples out there than C#. But, these are quite esoteric and usually not handled in C# applications anyways. Some of these are likely to have equivalents in future APIs or frameworks as well.
In summary, the main motivation I would suggest for learning C/C++ is to broaden your knowledge of other systems that are not accessible in C#. Learning Python would be a step in the other direction, where learning other styles and semantics of code construction is a more likely benefit. C/C++ code written by other people tends not to have more beneficial nor recognizable patterns like software written in Python, Ruby, or Lisp.

The best reasons for learning C++ for a C# developer is to learn new programming paradigms. C++ is more than just an "object oriented" language and hence offers a chance to learn new approaches to solving problems. With C# 3.0 and .NET 3.5, C++ doesn't affer as many unique paradigms, but if you are not using them, then effective C++ programming will force you to learn them.
In particular, C++ still offers a very powerful generic programming paradigm that is unmatched by C#. The STL forces you to use functional programming concepts that many C# developers avoid or don't use (LINQ extensions and lambda's for example).
I've also found that it strengthens a persons understanding and appreciation for lexical scope. Concepts such as RAII or C++ namespaces really push the need to manage scope very carefully... in C#, many of these concerns exist, but are less "in your face". Template metaprogramming is another unique concept that C++ offers that C# doesn't.

Learn C++ so that you can feel like blowing your brains out.

With every programming language you're able grow your vision of the landscape and apply lessons learned. Although I have never written a production C++ application, it was very educational for me to understand the system at that level. If you have the spare time, dive in! You may also want to explore unsafe C# code. It could help you understand many of the advanced capabilities of C++.

In order to respect the OP's wishes I won't say anything about how I think C++ can help a C# programmer think differently about code. ;-p
Seriously though, as a tool the main advantage of C++ is that it is multi-platform. Code written in C++ can be run on a huge variety of platforms.
On the other hand the big disadvantage of C++ compared to C# is that it takes a lot longer to write correct code.
While it is possible to write faster code in C++ in theory this assumes an unlimited amount of development time. In practice because I can write more sophisticated code more quickly in C#, I can spend the extra time optimizing the code.

It depends what programs you're working on. I've never used Python before, so I can't comment on that.
As for C++; most performance critical software is written in it due to its speed. You have more power over your hardware, but with that power comes responsibility and a steeper learning curve. It also doesn't have access to .NET; so you'll probably have to dig into Win32 programming for doing some of the tasks!
Examples of where C++ is used: Game development, aerospace, air traffic control systems.
Personally, I think that learning C/C++ makes you a better programmer overall, it teaches you many things; especially about performance and memory. And also well.. pretty much everything important is built in C++.

First off, It sounds like your interested in learning more. That is really the most important part of being a good programmer.
That said; Almost all big open source projects are written in C or C++, if you want to leverage or build on top of those you need to know the language. Not only is working with a large open source project look great on the resume, it also let's you examine some really good (and really bad) code. For me that alone has been a invaluable learning experience.

The primary reason to learn any new or different language is to learn a new and different approaches to solving problems in programming. C# and C++ certainly have some similarities. They also have some pretty substantial differences. At first, those differences will seem (as a few have mentioned) to be primarily with syntax. Further study, however, will reveal considerably greater differences that go well beyond simple syntax.
That means that if you decide to study C++, you need to plan on dedicating a fair amount of time and effort to it before you gain much. If you want something that's radically different from the get-go, you'd probably be better off with something else. My own advice for a completely different language would be Scheme -- basically Lisp with a good housecleaning.
There are lots of other functional languages, and some of them are pretty cool -- but Lisp has outlived a lot of would-be successors, and I think it'll outlive quite a few more. If I were a betting man, I'd bet on Lisp outliving F# by several decades...

What Are The Advantages/Disadvantages of Using Both VB.Net and C# In The Workplace?

At a colleague's workplace, a decision is trying to be made about whether to use both languages in the workplace or to standardize on one? There are some VB.Net developers and some C# developers.
What advantages or disadvantages would there be to using both or to using one?
Edit: To clarify this question, the question is not asking the advantages of one over the other, rather what are the advantages/disadvantage of standardizing on both languages versus standardizing on one.
For instance, one point could be that C#/VB.Net may have more third party tools available and hence it may make sense to standardize all developers on that language.

We should probably put on our Reality Glasses for this discussion. It's not just Syntactic Sugar going on here.
You will find that you can write code very quickly in Visual Basic.NET. That is largely due to some features that it has that C# does not yet provide: namely, the My namespace, which provides a plethora of functionality that C# developers have to frequently code by hand. (And that's a damned shame, if you ask me.)
I code in both languages every day. Coding event handlers for forms in Visual Basic is a snap, and it's VERY obvious what methods handle which events. It's not always as clear in C#. On the other hand, you can't always be as explicit in Visual Basic as you want to be, because Visual Basic does so much of the work for you. C# has the advantage of just getting the heck out of your way, and letting you get down to the nuts and bolts. Quite often, that's extremely liberating.
VB will let you invoke static/shared methods on an object instance. C# won't. You'll learn that the hard way when you try to port your code. C# will complain about unreachable code; VB doesn't care one way or the other.
But under the hood, when you get right down to it, it's all .NET. It all compiles down to MSIL. There will be minor differences. Visual Basic, for example, doesn't care about the case-sensitivity of names, where C# does. And the big gotcha there is that the CLR does as well. You'll realize that when you try to use reflection. Does that mean you shouldn't use VB? Nope. Just make sure you case things consistently -- especially your namespaces. (Namespace "My" and namespace "my" are two completely different namespaces to C# and the CLR, but they're the same to VB.)
Choose the language that makes you most productive, that reduces ramp-up time and maintenance costs. You may find that that means working with both languages. (We do!)
EDIT TO ADDRESS OP'S EDIT:
Refactoring tools are available for both languages.
Automated unit testing tools are equally applicable.
3rd party controls are going to be available for both languages because they're compiled down to MSIL.
Now, for IDE productivity tools, the one thing that C# has at this time that VB doesn't is StyleCop. That may change soon (and I hope it does), but I don't view it as a roadblock by any stretch of the imagination.

This is personal experience mixed with workplace lore:
VB.NET is capable of being little more nimble, compared to C#, because there isn't a standards committee (except for any that may exist at Microsoft).
Most of the Google-able code hackery out there is done in C#, and most of the best resource books provide code samples in C# only.
VB.NET is tainted with a history of VB being accessible to even the most incapable of developers. This is unfair, imho, because VB.NET is much more a "real" language. But the taint isn't going to be washed away any time soon, and "real" programmers still generally despise it.
As for real life - I code in my own time in C# and VB.NET at work. I believe that because so much of the code one writes for .NET is calls against the framework objects, the differences are actually quite small. If you can declare variables in both languages you're 80% to being portable. If you understand the framework, the syntax of the languages is a small obstacle.
EDIT to directly answer your question: We happily use both (though mainly VB.NET) and haven't ever had any problems. We use Visual Studio which allows us to pretty freely mix code files/assemblies. I would encourage you not to limit to a single language - I think some diversity is good for the brain.

My workplace had traditionally been a VB.Net shop, but a decision was made a couple years ago to switch to C#. This happened mostly because the VB developers had either left or moved into other positions and most of the new hires preferred C#. We still have a large legacy VB.Net code base, but all new development is being done in C#.
I don't think there's a strong technical reason to choose one language over the other, as they are pretty equivalent in functionality, but I do feel there are some valid reasons to choose one type of developer over the other. While I believe VB and C# are equal, there's is the unfortunate perception that C# developers are better than VB developers. While there is some justification for this, it's overblown. (It was more applicable in the C++/VB days.) That said, the perception exists. This does cause some talented developers to avoid and bash VB (though they usually do so from ignorance). I do think it's harder to hire developers into a VB shop than visa versa, because a C# developer will often balk at the idea of having to use VB, but VB developers usually aren't as opposed to using C#. There is one significant disadvantage to choosing C# over VB and that's that C# developers generally get paid more.
In my experience, the best developers welcome using both languages. The more languages you know, the better.

After tracking your question for a little bit and noting your edit, I have to wonder if you're fishing a little bit...
Either way, I think it's fairly obvious that at least the latest third-party tools favor C#. I, like the other responders, code VB for work and prefer C# for other development. I have definitely noticed that the documentation for many third-party addins/plugins and in some cases the products themselves favor C#. ReSharper, even though 4.5 has better VB support, is still vastly more comprehensive when using C#. And other frameworks, like Fluent NHibernate, don't support VB at all. So for tooling, especially when considering late-breaking stuff, I believe that C# wins. Not to mention the fact that C# got a few new features in 3.0 that won't be available until VB 10 makes a wide release.
I still agree whole-heartedly with the others; if you can do it in C#, you can do it in VB. It's all the same CLR, in the end.

I'd say given that there are "some VB.NET developers and some C# developers," there really is very little benefit to forcing everyone to use one language. Frankly even a VB.NET developer who's never looked at C# should be able to read C# code with no more than a brief introduction to the syntax, assuming he/she has a reasonable understanding of the .NET framework; and a C# developer should be able to do the same with VB.NET.
(I should also add: this is assuming everyone has access to a development environment in which the .NET languages can co-exist harmoniously -- e.g., VS2005, VS2008, etc., as opposed to one of the Express Editions, which as far as I know don't allow multi-language solutions.)

Don't fall for the "most examples / books are written for C#". Working out how to apply a C# example to VB.NET is trivial -- you'll have more trouble trying to understand what the moron who wrote the example / book is trying to do and what their hideous coding (un)convention is all about than you will mentally flipping C# syntax to VB syntax.
Also I'd say don't worry about whether you hire C# or VB.NET programmers: if they are any good at all then they won't have a problem with reading / writing both languages.
We use both here, and after a little resistance from some (we were using C++ before) have settled down fine. As I had predicted, the hardest thing for our team was (and probably still is) the conversion from MFC to .NET, not the language used to access the libraries.
FWIW our main split is VB.NET for UI code, and C# for backend / database / computation code.

C# and VB.net are the same with a different syntax. You can convert from C# to VB.net and back very easily.
VB.net does have a few extra advantages that C# does not, such as inline XML.
Most places have C# because its the more popular language.

I started out as a VB developer so naturally I migrated to VB.Net when I first worked with .Net. In fact my first .Net application was made in VB.Net too. But I tried out C# and found myself liking it better in a matter of weeks.
So I made some of that app in C# (some libraries) and it didn't hurt me. Now though I hate going back to the older VB.Net code and working on it. I really wish I could change it all to C# somehow.
That's not going to happen.
So what I am telling you here is, irrelevant of what language you choose (VB/C#) stick to it. Don't do mixed language development unless you have a compelling reason I can't think of yet :)

The advantage of standardizing on a single language is that basically everyone will have 1/2 as much to learn. I think it's better to spend the time learning more features of .NET, within a single language, rather than learning 1/2 the features in both.
As far as hiring goes, it does not really restrict you as a good VB or C# programmer should be able to switch to the other language without difficulty (or else they aren't really a good programmer :)