I will be developing some applications using mobile barcode scanners and need to choose between C++ and C# for coding on the scanners.
I am considering Intermec's CK31 or similar for the combination of wifi, scanning choices, programmability and user interface options. It runs Windows CE .NET 4.2 according to their spec sheet.
Intermec's Developer Library comes with .Net and C++ SDKs. My previous Win CE 2003 experience is in C++ (MFC GUI, sockets and serial comms). I'm comfortable in C# with WPF and can learn other GUI frameworks if I have to. That gives me freedom to choose a language - any recommendations one way or another?
I am NOT looking for answers advocating C++ over C# as languages in general - my productivity in either is similar and I have enough experience to be able to create complex, robust C++ solutions.
What I would appreciate are war stories or factors to put into our platform evaluation, about programming on these devices. eg: battery life of C# apps vs C++ apps, memory consumption or other environmental impacts of the language choice. If there are specific versions of .Net CE to avoid, that would be a good tip.
I've been designing and developing software for Windows Mobile and Windows CE in C, C++ and C# for quite a few years now. Moreover, I been doing so for Honeywell (formerly Hand Held Products, purchased by Honeywell in 2007) where I've worked on nearly all aspects of the devices, from drivers and services to Line of Business GUIs and utilities.
First of all, I won't tell you one language is better than the other... I probably spend a 50/50 split of my time with each, and each platform definitely has their own place in the mobile development.
I will however, give a suggestion that you likely stay away from any device that runs an OS as old as WinCE 4.2, especially if you are even considering .NET development. The reasoning for this is that 4.2 only has, at most, .NET CF 1.0 embedded in ROM (part of the OS ROM image), meaning that you would require a ~5MB CAB file to install at least .NET CF 2.0 Yes, you could develop with CF 1.0 but, truly, it's not worth the pain of using such an old framework. Most WinCE 5.0 devices these days come with CF (Compact Framework) 2.0 installed in the ROM so I would at least look for that.
On that same vain, you may even want to consider using a device with Windows Mobile 6.0 or 6.1 as they are easy to program with and will always have CF 2.0 pre-installed. In case you're wondering why I have not mentioned CF 3.0 or CF 3.5, it's just because the first Mobile platform to be release with those versions will be Windows Mobile 6.5, which is not out yet. Though you can always install the framework if you want (~8MB CAB).
Granted, WinCE definitely gives you a more "Windows" look and feel to its GUI over its Windows Mobile cousin, so that is all a matter of your programming preference and what your end users want and need.
Regarding kgiannakakis's comments on SDKs being only a thing layer, this is just not true. If you have a proper SDK you should have all of the same access to any devices or drivers that you would in C++ but with the ease of C#. For example, Honeywell provides an extensive SDK for all of our devices in C++, VB and C# and the C# portion of the SDK actually has more functionality than the C++ portion. You will never have to do a P/Invoke with our code from C#.
If you want to take a look at the SDK I'm talking about, it's freely available to download here and has some great examples.
IMHO I would actually consider the provided SDK as more important than the hardware in many cases since, most of the time, the hardware for the devices is pretty much the same. They all have ARM CPUs, WiFi, Bluetooth, Laser or Image based scanners, etc.
Though, I looked at the Intermec link you posted and it doesn't look like that unit actually has a built in scanner...are you using an external scanner hooked to the device?
Take a look at the Honeywell offering if you want here. We've got devices with probably the best imager based bar code scanner in the business, built into all of our units. And we have a rock solid SDK (I should know, I wrote a lot of it). And the SDK provides .NET extremely access to all of the hardware on the device. Ok...I'll stop my sales pitch now.
As for one language over the other...it really all depends on what exactly you want to do.
Drivers and services cannot be written in anything but Native (Win32) C or C++. So .NET is out for anything like that.
C and C++ can absolutely be your friend on mobile devices in terms of keeping things lightweight, since you don't need the whole .NET framework to run the add. Remember, you have a maximum of 32MB of memory for any process (not including DLLs..that's another lecture) so if your application is going to be processing a ton of data, C++ may be the way to go.
One of the major disadvantages I've found to C and C++ on mobile systems, however, is that making a GUI is way harder than it is with .NET Actually, most of the C++ apps I write are completely headless and have no GUI at all... .NET CF does not have WPF (yet), and is stuck with WinForms, but it's really easy to pick up. Pretty much drag and drop in the designer. And also remember, like I mentioned before, that WinCE has a completely different GUI paradigm than Windows Mobile. However, sometimes the Windows Mobile way is kind of nice, since it forces you to keep your GUIs simple and to the point.
Memory consumption can be higher when using .NET, but not always. For one, having a device with the version of the CF you are going to use stored in ROM will mean that you will generally have no more memory used on a .NET application vs the equivalent C++ app. In some cases, .NET will even use less memory. For example, a .NET app vs a C++ app that uses MFC can often use less memory because the C++ app has to load up the MFC framework (since it isn't already loaded by the OS...).
Also, since C# is managed, you will often end up with less memory usage because the garbage collector is freeing up memory that you may have forgotten to do in a C++ app.
Execution speed on more modern devices is generally no different between the two. Granted, you will always have little parts of each language where one will be faster than the other, but .NET is mature enough at this point that the speed is not really a concern. I have programmed extremely fast applications with highly interactive, animated GUIs that ran just fine on a device with 128MB RAM and a 420MHz ARM CPU. I even wrote one app that I had to slow down because it was calling into a native DLL via P/Invoke and the .NET portion was essentially getting "Impatient."
I have never seen any issues with battery life in one language vs the other. But I've never specifically tested for it either.
I really think that, in the end, it still comes down to the SDK that comes with your device of choice. If it has poor .NET support then you will find your self doing a lot of extra work getting everything to work, in which case I would go with C++. But if it has great .NET support (like the one I work on) you will find yourself with a lot less work and probably get the job done significantly faster.
Also, remember that it's not just the SDK of the hardware vendor you have to take into account. While you need that specific SDK as each device is different (i.e. the SDK I linked to earlier will not work on that Intermec device) all of the non-hardware related OS stuff is pretty much standard across the board, which is where the Windows Mobile or Windows CE SDK from Microsoft comes in. Their C++ support is pretty good, but they are really pushing all things .NET these days, so as updates are made to the OS, less updates are made to the C++ SDK and much more functionality now relies on using .NET Not that you couldn't do it in C++, it's just that they haven't done a lot of the work for you that they did do in the .NET SDK.
Ok...that was long, but I was trying to dump the finer parts of my years of experience into one thing. I hope it made sense.
The answer to your question has to do with the type of your application. If your application is mainly around communicating with the hardware and only a thin layer of business logic and User Interface is needed, then C++ would be a better choice. To interact with the scanners you need to talk to a driver. This is better and faster achieved with C++. The .NET SDK will actually be a wrapper of C++ code using a ton of P/Invoke, which makes the code performing less faster.
If on the other side your application requires a significant business layer and/or a User Interface, then .NET (and specifically C#) is a better option. In that case the productivity gains far out weight the performance gains of C++.
Another important factor is the type of the devices the application is going to be deployed to. Are you targeting Windows Mobile devices only? Then .NET is a safe option. For Windows CE devices you need to investigate whether the compact framework is pre-installed or not. Also, some Windows CE devices may not support all .NET namespaces.
Finally, I recommend reading Mobile Architecture Pocket Guide, which is a recent document about architectural decisions for mobile applications.
First I'll strongly echo Adam's recommendation against running anything based on CE .NET 4.2 at this point for essentially the same reason. At this point it's an ancient version of the OS and unless you are getting the terminal for free it's not worth it and if you choose to do C# development the download of the CAB to run .NET 2 is just painful.
We've developed a lot of applications for both Motorola(Symbol) and Intermec devices. The current set of APIs for both of them work reliably so I'd worry more about the suitability of the device than the specific APIs. They also both provide reasonable sample programs that make it easy to cut and paste a solution.
I have noticed one other big difference between Motorola and Intermec. On the Intermec devices I've worked with (in C#), it takes about a second for the decoder for each symbology to be loaded. This typically isn't a big deal if you use a limited number of symbologies and setup the scanner at the start of the application, but can cause significant delays if you change the decoders(symbologies) within the application.
I've been developing for about 15 years. Approx 5 years in C++ and 3 years in C# (which currently is my language of choice). In C++ I always used stdlib, and sometimes boost.
I have cut my development time with a third since I switched from c++ to c#. That was done because of a couple of things (nothing scientific, just my opinons):
.Net is a more complete framework and easier to use than stdlib and boost combined.
C# has a better structure which make easier to read others code and to code.
Unit testing in .Net is light years from unit testing in C++, especially with Resharper and xUnit (xUnit got clean syntax, resharper let's you test specific test methods directly inside dev studio).
I mostly code servers, GUI programming should be even faster.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 2 years ago.
Improve this question
I'm building an application for multiple desktop platforms: Windows, Mac, and maybe later for Linux.
I was wondering which programming language and IDE combination would be the best for me:
Programming language need to be whether C# (preferred) or Java.
Core libraries must be shared between all platforms, means all platforms must link to a single core library (by library I mean a list of classes and functions).
Windows and Mac are in priority, Linux app is for future plannings.
Design of the app is completely custom, it doesn't follow any guidelines of each platforms.
I'm stuck between these three solutions:
Use Xamarin.Mac + Visual Studio for Windows and link the core classes between them.
Use GTK# for the whole project and compile multiple builds for each platforms.
Use Java for the whole project and compile multiple builds for each platforms.
For #2 and #3, I need an advice that which language is more suitable for me, considering the design of my application. I mean, which one has a better GUI building ability for my goal?
BTW GTK# uses different libraries for each platforms, so that should be an clutter for my core architecture, or not?!
Three years later and Javascript is now also a strong contender in this debate.
There are multiple options within the space.
https://electron.atom.io/
https://github.com/nwjs/nw.js/
And others
Even Microsoft has shipped Visual Studio Code, the cross platform version of their development environment, which is written in Javascript.
What is the Visual Studio Code editor built on
The benefits include utilizing the many available web libraries, and building/using your web development skills.
This sounds like a job for Xojo or something similar: http://www.xojo.com
Mac, Windows, Linux builds with easy GUI design and native apps. Custom UI easily done also, and you'd then have one code base for all three platforms. You can download and use the software for free to develop and test, only requires a license once you decide to build your app.
You can also conside Livecode
Livecode: http://livecode.com
For any platform except web, it is opensource and it includes mobile targets as well, if your code is flexible enough to not being C# or Java.
An option is to build the core logic in a compiled library using C# and GUI independence and then plug it to livecode, leaving the UI work for that tool.
"GTK# uses different libraries for each platforms", do you mean different rendering back ends (such as X11, Cairo)?
You only need to build your GTK# app once. However, you do have to bundle the GTK# runtime (which is different for Windows and Mac) with your app. Banshee is a good example you can follow.
Probably your best bet is to use Nevron Open Vision. It is a cross-platform, C# based User Interface Platform, that implements most of the controls you need to build enterprise-ready applications. It is the framework behind MyDraw (www.mydraw.com) - a professional drawing program similar to Visio. MyDraw is built completely with Nevron Open Vision and does not require any other third-party libraries. We mainly develop it under Windows and just compile it to Mac. Soon we are going to add support for Linux and WebAssembly hosts.
Microsoft just launched .NET MAUI, a cross-platform GUI framework that builds on Xamarian.forms.
As we consider what building device applications will look like in a unified .NET, we see many devices across multiple platforms used, from Android and iOS to Windows and macOS. To address this need we are excited to announce a new first-class UI framework for doing just that: .NET Multi-platform App UI, affectionately call .NET MAUI.
This seems to meet all of your requirements. They do not explicitly mention Linux in their article, but claim to support it in the description on the Github Repo.
It depends on the audience of the app: Consumer mass market or business/IT
If its mass market consumer facing
Electron or native UI, perhaps with shared non-UI code. Visual Studio Code was made with Electron, for example (last I checked). Google Flutter is a new entrant worth evaluating. Dropbox is Python (or used to be). It is a lot of work (a) getting Python packaged properly for smooth x-platform install, and (b) GUI work will take a long time. Sadly, for mass market consumer apps (not utilities for IT people but beautiful designs for the masses like Dropbox, Skype) you will be spending a ton of time getting the installation system to work and getting the app to look and feel appropriate. This is an extremely time consuming endeavour no matter what path you take.
Consumer: Java? I don't think Java is a great fit for consumer desktop although I could be wrong. There are some Java packaging systems that are leaner/all bundled in. I'd also say JVM software companies tend to go under (more on this later). FreeMind the free mind mapper, is a good example of what can be achieved in Java.
Consumer: .NET? Yes, for the Windows side. Then use something native for Mac and shared libraries for non-GUI code. There is ".NET Core" aka Mono but its not fully matured at this time for Mac. Mono has been around for over half a decade and I haven't seen it mature for a consumer app. Ask: How many .NET Core apps are in the Mac app store? I hope it gets better but as of this writing (2020) there's very few notable ones.
Business app or IT tool
If its a basic business app or utility where a basic UI is okay, I'd evaluate Xojo and/or LiveCode mainly for comparison sake. Xojo is fairly close to .NET. Google Flutter as well since it's up and coming. By the time you read this, Flutter may be the best choice.
B2B: Java? This is a pretty tried, tested and true solution for "heavy" enterprise apps. You might not have end-users love you given Java apps tend to eat up memory. But for enterprisey apps the main concern is that the very intense business logic will work. For IT tools, it depends. If it's a 3-screen utility program, avoid Java. If it's a complex ERP then Java is good. Remember to look around for different packaging tools to avoid consumer headaches with the JVM. Again, one Java desktop app I like is Freemind. It's a great example of making a reasonable desktop app in Java. I have used it in both Windows and Mac and it's great. You can also look at Kotlin or Groovy (for test cases) which compile to Java byte code.
B2B .NET? There is so much to unpack here. The key is, in my biased view, .NET Windows desktop development is about 2X-4X faster development time than Windows Java desktop development. From making the GUI, to better code completion, to faster compile times, to less packaging and install snags. That said, at the time of this writing the ".NET Core" or Mono are pretty thin for MacOS. I really, really hope this changes. But I've been waiting years for Mono or .NET Core to provide a full suite for MacOS without the limitations and it hasn't yet happened. If it's an enterprise app, you might be able to get away with using .NET Core for Mac. But please first build a basic .NET Core "hello world" app with all the control/libraries you want to use. Then try building an installer for it on MacOS, and find someone random with a Mac to see if it actually installs and runs. You may find you're struggling in this area today (although I hope it gets better, it hasn't for years).
Overall Notes on Cross Platform
If this is a smaller app which doesn't need a fantastic UX and super-deep OS integration, then I'd consider Xojo or LiveCode, perhaps for the UX elements. Like #merlucin said, you can write the core logic in something shared- perhaps C#, python, etc.
Here's why- Xojo and LiveCode have been around for 10 years now. They are more about keeping things consistent. Whereas I find .NET and QT changes all the time. You have a lot of costs of keeping up with the Joneses and maintaining installers. So for a small app or utility- an XML editor, IT helper tool, Xojo or perhaps LiveCode will help you get there sooner.
When you hit the build button on Xojo, for example, it literally makes 3 executable files for Windows, Mac and Linux. Compare that to the madness of packaging a cross platform Python app, or even packaging a .NET app for Windows, to be honest.
The tradeoff is these tools- Xojo and LiveCode often end to be missing a few critical things you need, requiring a bit of a hack. You can read around their forums. Xojo is a bit like .NET although LiveCode is a different programming paradigm entirely based on "stacks".
Keep in mind developer happiness too. Many developers wont want to code in Xojo or LiveCode because they are lesser known languages. So ensure you get buy-in. What happens if you get laid off and have 5 years of experience in Xojo? Hmm.
In your evaluation, no matter what you choose-- you must compile a basic GUI app in the platform you're evaluating and get 3 people to install it correctly on a Mac. You'll be shocked at the libraries and madness needed. Especially if you're a web developer, you'd see that just maintaining installers is a ton of work across 3 platforms. Never mind GUI consistency.
I am new to windows mobile development. I have certain doubts related to windows mobile development which are as follows.
1) What is the major difference between C# and C (C++) as far as selecting language for development. ( not syntactically ) .
2) Which language should i select for development and Why ??
3) If i go C# as a mobile development then can i have access to all APIs for C# on
desktop .
Aside from syntax, the main difference is that C# is managed and C++ isn't(unless you're using managed c++?)
They're both OO languages(not C). C++ allows you to do your own memory management(which could be a good or bad) while C# is managed code so garbage collection is mostly done for you by the runtime. If you use C#, you will be able to access all other managed assemblies targeted toward the CLR.
Your mileage may vary, but a few years back we tried to develop a C# app for Windows Mobile, and the performance was unbelievably bad. I'm talking "it takes 10 seconds for my dialog box to appear" bad. I'm sure it has gotten better, but the underlying issue remains: these are devices with more stringent resource limitations than a desktop PC, and the performance hit you take with .NET is more likely to affect you noticeably.
So go with C# if your app is in no way performance sensitive, but if you have any performance concerns at all, in my experience C#/.NET will not cut it on Windows Mobile. C++ is then the next most sensible choice.
Windows Mobile Development: Choice of .Net compact vs. Native (c++) code
C++ or C# to program mobile barcode device?
1) Applications written in native code will run faster. Furthermore, memory footprint is smaller in native applications.
2) It depends on application you are writing. If it does not demand top performance and if it does not require a lot of native functionality, then the code should be managed. If you need a lot of flexibility, go for native.
3) No. .Net Compact Framework has a subset of desktop APIs.
1) Too vague to answer
2) C#, because there is a well-supported framework (.NET Compact Edition) for it.
3) No. Not all API's are available in the Compact Edition of .NET.
If you are developing application only for the Windows mobiles, go for any .Net Compact Framework supported language.
You can also use C++(unmanaged) but all depends on the kind of mobile application you are developing.
I have been advised in the past to avoid the .net framework when developing for WM unless absolutely necessary.
this is apparently due to the fact that the .net framework loads quite a lot of dll's and thus has a large memory footprint (obviously this is mitigated to a certain extent if there are other .net apps running that share assemblies) - resulting in rather poor power usage.
also the jitting and house keeping that takes place (out of your control, at undefined periods of time etc - if you move a lot of memory around this may become an issue) - on lower power devices like pda's this constant messing around in the background may become noticeable.
it is however considerably easier and faster to code in .net.
if:
you consider 'quick-wins' to be more important than conscientious efficient code or
you dont care about battery life or
your app isnt performance sensitive or
you dont know how to code with native languages
you dont care about open standards and compliance
then go for .net.
.net compact framework is a subset of the desktop version of .net - thus certain features and aspects of the framework are unavailable.
if youre just starting out i recommend .net - if youre developing a commercial solution etc i recommend the use of c/c++.
hth.
C# is often recommended in development of simple desktop or web apps while C++, which deals with the hardware directly, is used for apps that require higher efficiency.
I would say C#. Given that you are new to Windows mobile development C# would be easier for you to implement things. Also, C# is developed by Windows, so it targets specifically Windows apps.
No. you will only have a subset of libraries for Desktop APIs.
My company has an existing established WinForm application which in running on WinXP. The application does alot of sound processing using DirectSound.
My company would like to evaluate Mono, as an alternative on a per workstation cost to Vista/Win Server 2008.
I've heard that different estimates, ranging from 'it will work easily on Mono' to 'it could take months of recoding in certain cases to get a WinForm app to run with Mono on Linux'.
Does anyone have a good real world experience with this?
A good link reference?
I would like to get a better idea before I commit to testing.
Thanks!
The WinForms part will be easy, you may have to do very little as Mono now claims to support Winforms 100%, however all the DirectSound calls will have to be rewritten to use an API available on Linux, ALSA being the obvious choice.
I have written small apps in VS 2005 and ported them with ease to Mono. If you do a lot of P/Invokes, then you'll have to take that into account, as those may have to be completely rewritten or rethought.
Also, check out MOMA: "The Mono Migration Analyzer (MoMA) tool helps you identify issues you may have when porting your .Net application to Mono. It helps pinpoint platform specific calls (P/Invoke) and areas that are not yet supported by the Mono project."
Mono can help you move the managed code, but it will not help you move the audio layer.
Sadly, the .NET framework does not provide a comprehensive API for audio processing. It merely provides a way of playing back a small sound sample, and it is not even very good at this (See Jeroen's post about audio gaps when running the C64 emulator under IKVM).
You will have to research which Linux API maps best to what your audio application is doing.
Lennart Poettering blog entry on audio is an excellent starting point:
http://0pointer.de/blog/projects/guide-to-sound-apis.html
Once you decide on an API, just like in Windows, you will have to P/Invoke the API that is right for you.
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 3 years ago.
Improve this question
In looking at the use of C# in a ISV setting, I'm wondering what prominent C# based desktop apps are out there? I can think of only Paint .NET.
Is C# a good idea for an ISV, or should one stick to more native environments like Delphi or even QT?
Of course any experienced based advise or feedback would be appreciated.
Yes, C# can be used quite effectivly to build applications. In regards what applciations are out there, what are you looking for? Big apps, little apps?
I know of a big app that is built on the .NET framework (unsure if C# or VB) and that is Quickbooks.
Developing a Desktop applications in C# is great. Its not just for Web Apps.
WinForms are going to save you huge amounts of time. It really is a first class citizen when it comes to desktop windows development. If interop is a problem you can always use P/Invoke and COM object wrapping that VS does for you.
Done right, it will be a breeze to maintain and update when the client changes their mind on what they want.
Yes, the framework needs to be on the machine, But this shouldn't be a problem if they have ever used windows update. Nowadays what language doesn't come with a run time library. In VS you can create simple installers that include the runtime.
Of course if your gonna deploy to Linux and mono, your mileage may very.
PlasticSCM
If you can control the system requirements for your application, C# is fine. Some end users still (even though we're nearly in 2009 now) object to a 40MB runtime for some reason, so if you're looking to deploy an application commercially, that may be an issue for you. In a corporate setting, though, where there is some standardization of software on users' computers, this is probably not a problem.
Delphi and QT specifically are both problems. Delphi is effectively a dead language. Companies that are using it these days are, for the most part, porting their code away from it as fast as they can (job boards seem to be full of Delphi-to-C# migration jobs these days). You may like QT, but that moves almost as slowly as Delphi in the Windows world, so I would never consider it to be a real option.
More:
Business Plan Pro
Rescue Time client
Sony Vegas
Sql Management Studio
VS 2010 (much more so than VS 200x)
NASA's World Wind
BabySmash
Windows Live Writer
Microsoft Office Accounting
Fiddler 2
Windows Mobile Device Center
AdiIRC
Jetbrains dotTrace
Lots of Lenovo utilities
Planbook
These are just the ones installed on my PC...
I think that Microsoft Expression Blend/Studio is written in C#
Anything done for Robotics Studio, any XNA game (quite a few commerical ones are coming out now)
I don't see why you would not use C# as an ISV. The problem is ensuring that your target market has the .NET framework. If you are using 3.5, you can build a mini version into your distribution though this increases the file sizes for downloads of course.
Some supplemental information to think about:
One of the typical points against doing desktop applications the distribution model is a lot more difficult to manage. With web apps, if you have a large user base, you can do an update and instantly have your entire user base running on the latest version.
With traditional desktop apps, you'd have to send out an .msi or build something yourself.
However, with ClickOnce and the Updater Application Block (http://msdn.microsoft.com/en-us/library/ms978574.aspx), it's so easy to build intelligent updating into your application that it might play very nicely into an ISV plan.
Even though VS 2008/WPF is shrinking the gap, it's typically much faster to develop client applications in the WinForms space that on the web, so I think it's a very viable approach.
I believe TimeSnapper is written in C#
I have worked for an ISV before that used Delphi and it was excellent for their needs. It still produces great native applications and although dieing it is certainly not dead (yet). Until recently I would have recommened Delphi over c# for desktop applications as I had performance and footprint consderations but as .net can now be considered ubiquitous and that the platform is now maturing my opinoin would probably go with c# (over Delphi).
If you need to consider employees, you will find that there are fewer Delphi developers around that c# ones. So you may struggle to entice good devleopers in as you are using that.
That said Delphi is looking exciting again with the Delphi prism VS plugin.
Just as an aside did you know that the c# compiler is written in c++? Delphi was written in Delphi from v1.0
Windows Media Centre is powered by .NET.
I believe that MS use C# to build many of their apps both Windows and Web. At this time, C# is a great language to go with because of the flexibility of the language/framework.
The zune software (v2 and up) is written in c#. Oh, and Sage Timberline Office is written in .net (mostly).
Although it's a developer tool, the excellent open source IDE SharpDevelop was built in C#. I've also worked on another which (despite being semi-commercially-available) I'm not at liberty to divulge. (Very vertical market.)
I'm a huge fan of the C#/WinForms combination, and can't see why you wouldn't go that route if your developers are already familiar with C# and you want to get into the desktop space.
A very prominent example for a commercialy successful application would be Microsoft Visual Studio 2005 itself.
If you are looking into building a client or server application for the Windows ecosystem .Net with C# is an absolut valid choice. You'll get a very rich framework, a great third-party-app ecosystem and a huge community.
If you need a minimal memory footprint for your application or are very hardware centric then C++ maybe an option.
If you want to target the UNIX/LINUX or Apple platforms you should be looking in frameworks more native for the respective platform, though you can get a certain degree of interoperability with the Mono project (But I am not up to date on how complete their implementation of .Net currently is).
I believe the matrox graphics card configuration utilities are using the .net-framework.
I'm still just a student, but for what it's worth (and from other answers preceding mine), there seem to be quite a few apps in C#.
I'd advise working through the book Head First C# (Amazon link). This book will give you a pretty solid idea of what you can do with the language.
=-MDP-=
Creative Docs .NET is a very nice example of C# application.
Microsoft's World Wide Telescope software is written in c#
Who are your target users? Their needs will dictate your choice of language. C# and VB.NET are good general purpose langs, but if you are targeting Mac or *nix, you may want something like C++.
If you're looking for a way to get started quickly, I recently published DesktopBootstrap, which is my attempt to factor out the elements you'll need to get started.
Hope that helps!
Before I jump headlong into C#...
I've always felt that C, or maybe C++, was best for developing drivers on Windows. I'm not keen on the idea of developing a driver on a .NET machine.
But .NET seems to be the way MS is heading for applications development, and so I'm now wondering:
Are people are using C# to develop drivers?
Do you have to do a lot of API hooks, or does C# have the facilities to interface with the kernel without a lot of hackery?
Can anyone speak to the reliability and safety of running a C# program closer to Ring 0 than would normally be the case?
I want my devices to be usable in C#, and if driver dev in C# is mature that's obviously the way to go, but I don't want to spend a lot of effort there if it's not recommended.
What are some good resources to get started, say, developing a simple virtual serial port driver?
-Adam
You can not make kernel-mode device drivers in C# as the runtime can't be safely loaded into ring0 and operate as expected.
Additionally, C# doesn't create binaries suitable for loading as device drivers, particularly regarding entry points that drivers need to expose. The dependency on the runtime to jump in and analyze and JIT the binary during loading prohibits the direct access the driver subsystem needs to load the binary.
There is work underway, however, to lift some device drivers into user mode, you can see an interview here with Peter Wieland of the UDMF (User Mode Driver Framework) team.
User-mode drivers would be much more suited for managed work, but you'll have to google a bit to find out if C# and .NET will be directly supported. All I know is that kernel level drivers are not doable in only C#.
You can, however, probably make a C/C++ driver, and a C# service (or similar) and have the driver talk to the managed code, if you absolutely have to write a lot of code in C#.
This shall help you in a way: Windows Driver Kit
It's not direct answer to your question but if you're interested you might look at Singularity project.
Can anyone speak to the reliability and safety of running a C# program closer to Ring 0 than would normally be the case?
C# runs in the .NET Virtual Machine, you can't move it any closer to Ring 0 than the VM is, and the VM runs in userspace.
If you're willing to have a go at a proprietary framework, Jungo's WinDriver toolkit supports user-mode driver development (even in managed code) for USB, PCI, and PCI-E devices.
Microsoft has a number of research projects in the area of having a managed-code OS, in other words kill with Win32 API.
See Mary Jo Foley's article: Rebuilding a Legacy
Writing device drivers in .net makes no sense for current versions of windows.
<speculation>
Rumors are that MS is investing a lot of money in bringing Singularity to the next level. Just look for Midori. But that's 2015+
</speculation>
If I remember it correctly, the Dokan Project is a user-mode file system driver, which also allows .NET code to be executed by a system driver: https://github.com/dokan-dev/dokan-dotnet.
So, you could develop a C# "driver" (user-mode application really), which is then called/invoked by a C++ kernel-mode driver. The kernel-driver could simply pass everything along without manipulating the data and act as a simple wrapper.
Needless to mention, that it is very unsafe and you would most likely end with a BSOD (I tried it).
Mildly related:
The Cosmos Project is an open-source Operating system, which is developed in C# and runs
"(kernel) drivers" and user-level applications written completely in C#/F#/VB.NET/...
Though these are technically kernel-level drivers, the OS is no longer Windows but your own, so I guess that this is not a correct answer ......