Creating Symbian application using .NET - c#

Does tooling exist for Visual Studio that makes it possible to create a Symbian mobile application using .NET?

In the past, Visual Basic, VB.NET, and C# development for Symbian were possible through AppForge Crossfire, a plugin for Microsoft Visual Studio. On 13 March 2007 AppForge ceased operations; Oracle purchased the intellectual property, but announced that they did not plan to sell or provide support for former AppForge products. Net60, a .NET compact framework for Symbian, which is developed by redFIVElabs
http://en.wikipedia.org/wiki/Symbian#Other_languages

I guess RedFiveLabs (the maker of .NET for Symbian) is out of business. Except for links to their website, I can't find anything anymore from them. Their website is unreachable ( http://www.redfivelabs.com ) Their product is/was called Net60.
Silverlight is available for the S60 5th gen devices: http://www.silverlight.net/getstarted/devices/symbian/
Symbian itself is also almost dead, their Symbian^3 isn't good enough, and I guess Nokia put their bets on MeeGo (although I read somewhere that even Windows Phone 7 was an option).
This makes the development of anything for Symbian not really worthwhile, also since the current user base doesn't interact with the OVI appstore like users of other phone OS's.

AFAIK the only .NET platform is Windows.
There is also Mono for linu, but I am almost sure, that you can't code in c# for symbian.

There's an article on that here: http://www.danielmoth.com/Blog/net-compact-framework-on-symbian.aspx
It contains a link to an interesting article on porting the .NET Compact Framework to Symbian phones. http://www.jot.fm/issues/issue_2006_04/article4/
That article stated:
Our analysis shows that the specifics
of the Symbian OS and the resource
constraints of today’s smartphones
make porting difficult but not
impossible.
In other words, it's POSSIBLE but probably not worth your effort.

Related

Are there any drawbacks to learning C# in MonoDevelop?

I want to learn C# because... It seems to be a pretty marketable language these days. More than C, not so much as PHP/MySQL in my area, but I'd rather be a software developer than a web developer. Anyways, I'm running linux, and I have no hope of working on a windows platform until I buy a new computer. So, are there any drawbacks to learning C# under linux? If so, are there any good lessons online for doing such a thing? Any good tutorials online for learning C# in general?
update
so what I'm getting is that the main drawback is that although the full C# language spec is implemented in mono, the full .Net framework isn't. But, until I can get a new system and run windows, I guess lacking the full framework will have to do.
The language spec is fully implemented but the framework itself is not. So learning C# the language will be no different (ignoring the benefits of using visual studio as your IDE). Writing against the framework will be a bit different.
edit> It also depends on what kind of programming you intend to do. Much of the parts of mono that aren't complete are also often edge cases for beginners that you aren't likely to run into. So if you're just learning C#, there's a very good chance that you won't come across the parts of the framework that haven't been implemented yet (and I mean yet, they are very fast at updating mono from what I've seen so far, so by the time you're ready to really explore the framework and all that it entails, there's a good chance that it might be completed by then)
learning C# on linux may actually be good, when you start doing it on windows, you will know both. The IDE will not be as modern, but I'll bet there are not many people that can do it on both.
You'll be able to concentrate on the actual C# language and you can learn the microsoft IDE when you get to use C# on windows.
The major drawbacks that I see are:
The latest .NET versions are not supported
Different tools between Mono and Visual Studio
In spite of that, I think you can learn a lot about C# on Mono.
Any good tutorials online for learning C# in general?
Here's a tutorial I wrote:
http://www.csharp-station.com/Tutorial.aspx
Feedback has indicated that all of the code in the tutorial runs fine on Mono.
Joe
Learning the language should not hurt, I would not depend on it to land you a job. However, keep in mind that many of the runtime services that are accessed via C# may not be available. Knowledge of those services is perhaps just as, if not more, important the language itself.
The main problem with C# on Linux is that your development system will not be as good, in most people's estimation. But you may get really good at vi(1)...
On MonoDevelop you won't have all the newest features of the .NET framework, it's somewhere between 2.0 and 3.5.
It supports C#3.0 though.
Mono is gaining traction very, very quickly. I've heard rumblings that MS is silently supporting Mono (see their approach with getting SL to run on Linux). In some cases, mono actually outperforms .net on a windows based server.
The downside would be the IDE and features, as many have already mentioned. Visual Studio is by far the best IDE out there.
It does support Asp.Net MVC IIRC though.
Mono overcomes the single biggest drawback to using .NET from Microsoft for many developers, the requirement to run on the Windows platform. By bringing the shared source release of the .NET Framework to multiple platforms and then building an open source project around extending it, The Mono Project has made the strengths of .NET available to a wide range of developers. The ability to develop using a variety of languages, all using a common interface and deployable on a number of platforms is a very compelling development strategy.
As far as the web services aspects of Mono are concerned, nearly all of the Framework is complete meaning a developer can begin developing web services today using Mono. Mono features nearly complete implementations of ASP.NET, ADO.NET and Web Forms, along with almost all of the SYSTEM namespace. For more a detailed visit mono's official site,mono-project.com check out these articles on Cool Solutions for Developers:
Well there is nothing wrong if we learn something & probably we might end up improving it which will be more useful to the future users.Probably that is the power of open source.I think all developers will agree to this point :)

Is WPF on Linux (already) possible?

I love programming with .NET, especially C# 3.0, .NET 3.5 and WPF. But what I especially like is that with Mono .NET is really platform-independent.
Now I heard about the Olive Project in Mono. I couldn't find some kind of Beta.
Does it already work? Have any of you made any experiences with it?
Edit: I know about Moonlight. But I want a standalone WPF application. And because of Moonlight I hope WPF on Linux will become true.
You'll have better luck working with Moonlight, which targets the Silverlight API, which is a subset of full WPF.
edit: Sure, Silverlight isn't "intended" for the desktop, but there's no reason why you can't embed a silverlight engine in your application. It's been done before, such as for the Mac NY Times Reader
more edit: see Miguel's post on Standalone Silverlight Applications
Update: Since people keep upvoting this, I want to point out it is long since out of date. Mono got acquired by MS years ago, and their posture regarding open-source has changed, so consider this post obsolete. (As obsolete as the WPF framework itself, heh).
Mono is in a bit of an uncomfortable position when it comes to Microsoft APIs such as Winforms and WPF. A subset of the .Net technology is an ECMA standard, but free implementations of these APIs are probably on shakier legal ground. I believe this was a large factor in the covenant between Novell and Microsoft, which is good for Novell customers. But people who use Mono that aren't customers of Novell aren't protected. For this reason a lot of people in the F/OSS community look askance at Mono despite its technical merits.
For this reason, Gtk# will always be preferred, since it is truly Free. Many people consider it to be superior to Winforms anyway. As far as WPF is concerned, it will almost certainly be a low priority for Novell. They may implement it eventually, but I would expect Moonlight to be the closest you could get for the forseeable future.
Since posting this, Microsoft has extended their covenant to anybody who implements the ECMA 334 & 335 standards.
From the mono website
At this point, the Mono project does
not have plans to implement Windows
Presentation Foundation APIs as
part of the project.
Moonlight is an implementation of silverlight, which is a browser based flash like technology based on a subset of WPF.
In my opinion the choice to not implement WPF is monos biggest mistake. As WPF is fast becoming the default choice for new .net user interfaces. See this blog for more.
There is a library called Silverform SDK that aims to provide cross-platform WPF and Silverlight implementation.
The library is implemented in managed code and currently works with OpenTK and Unity3D as render backends. Major functionality, such as binding, layout, main controls and primitives, has already been implemented (check Unity web player demos here). Initially it has been focused on Unity3d render, while support for standalone Mono applications will be added as a separate build in the future.
Disclaimer: I am one of the developers of the library.
If you check Known bugs of this link(also includes steps needed to install .NET onto Ubuntu)or this you may find that some(may be buggy) version of WPF works on Wine as for now. I did not find any definite test done as for now, but worth to try to run WPF "Hello world".
UPDATE2:
I have run latest IlSpy on latest Wine for Ubuntu 16.04. With 32 bit version of dotnet45 and corefonts installed via winetricks with windows 7 compatibility.
For this time no crashes and all things work fine. Fonts look really good.
IlSpy is shown via WPF and for person who loves programming with .NET is essential tool - the decompiler.
I downloaded latest portable SharpDevelop(build using WPF) with no extra. It started. Failed to create WPF project. Created WinForms. After opening some cs files and evidencing some glitches, tried to type - and it crashed.
UPDATE
I followed steps and got latest ILSpy.exe running on Ubuntu 14.4.
Next items to note:
wine stated that dotnet40 is not supported by 64 configuration, changed to 32 bit
fonts are ugly, but readable
basic functional works fine - I can see decompiled code - which is good enough for some development, but View -> Search and View -> Options -> Display crash.
Conclusion:
WPF on Linux is possible. But need some way to tackle issues.
From the Olive home page:
Olive is unsupported, should be
considered as experimental software,
and since it implements a shifting API
there are no guarantees of any kind
about the stability of the API.
I doubt anyone would have used it in a real project.
Yes, it is possible using NoesisGUI a real-time multi-platform XAML implementation. There are a few games already released using this technology in Linux, like VoidExpanse
Disclosure: I am one of the developers of this product.
I heard a podcast interviewing miguel de icaza (the mono lead) maybe a few weeks ago, so that would have been maybe mid-december 2008, and he said that they had no WPF support at all yet.
Theoretically, a stripped version of WPF COULD be compiled against WinPR or LibWine to run on Linux.
Currently there is no such setup, so someone would need to make one. Hopefully this might change soon.
As of running against or in a full Wine environment, I think that is seriously overkill and will result in too much bloat to be worth making a very small number of additional programs work.

C++ or C# to program mobile barcode device?

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.

C# Desktop Applications? [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 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!

What is the deployment rate of the .NET framework?

I've been looking for this information for my commercial desktop product, with no avail.
Specifically, what I'm look for, is deployment statistics of the .NET framework for end-users (both granny "I'm just browsing the internet" XP, and high-end users, if possible), and in the commercial/business sector.
Edit: Other than the data points below, here's an interesting blog post about .NET deployment rates.
Some statistics from 2005 I found at Scott Wiltamuth's blog (you can be sure these numbers are much higher now):
More than 120M copies of the .NET Framework have been downloaded and installed using either Microsoft downloads or Windows Update
More than 85% of new consumer PCs sold in 2004 had the .NET Framework installed
More than 58% of business PCs have the .NET Framework preinstalled or preloaded
Every new HP consumer imaging device (printer/scanner/camera) will install the .NET Framework if it’s not already there – that’s 3M units per year
Every new Microsoft IntelliPoint mouse software CD ships with the .NET Framework
It is also worth pointing out that Vista and Windows Server 2008 both ship with the .NET Framework. XP gets it via Windows Update.
It depends a lot on which version of the framework you are targeting. I believe 1.1 (and even 2.0) are widely deployed. The later versions are not.
You should also visit this site for some very good information on .Net Framework Deployment: http://www.hanselman.com/smallestdotnet/
I don't have any hard numbers, but these days, it is pretty safe to assume most Windows XP and Vista users have at least .NET 2.0. I believe this was actually dropped via Windows Update for XP, and Vista came with at least 2.0 (apparently with 3.0 as pointed out in the comments to this answer).
I needed that same kind of information at my last job, where I was attempting to convince my manager to allow .NET development. The customer base was primarily dial-up users, so requiring a 20+ MB download was a tough sell. Unfortunately, I wasn't able to find any sort of statistics, either from Microsoft or from a research firm.
What I was able to get, however, was web analytics from the company's home page. .NET inserts its version number into the User Agent field, which I was able to log using our analytics package. From there, some Excel gruntwork was able to give me a rough idea of how many customers already had .NET installed, and which version(s).
Unfortunately that won't help you answer the broader question of deployment rates across multiple demographics, but it might be a useful technique for a single customer base.

Categories

Resources