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.
Related
According to the MS documentation Sync Framework Toolkit (https://code.msdn.microsoft.com/Sync-Framework-Toolkit-4dc10f0e) is a legacy open source product which MS no longer support:
https://msdn.microsoft.com/en-us/library/jj839436(v=sql.110).aspx
That's fine, but how about Microsoft Sync SDK which is not open source?
Does it mean that open source part useless because server part can be removed by MS in the future?
The question is does it mean that Sync Framework SDK (Server side library) is dead? (Green Part)
I am not sure what do you mean by dead.
As long as you know Sync Framework Toolkit is not supported and you know the consequences of using it.
As to Sync Framework SDK
Some Federal agencies did approve the usage of that SDK.
This link might be the answer to your question.
According to the US department of Veteran Affairs
https://www.oit.va.gov/Services/TRM/ToolPage.aspx?tid=11403
Microsoft Sync Framework Software Development Kit (SDK) Technology is approved with constraints in 2019, 2020, 2021
Approved w/Constraints: The technology/standard can be used within the
specified constraints located below the decision matrix in the
footnote1 and on the General tab.
However, these constraints are not met.
Technology must remain patched and operated in accordance with Federal
and Department security policies and guidelines in order to mitigate
known and future security vulnerabilities.
You might notice this announcement which does not seem to still be valid,
Microsoft Sync Framework 2.1 is now in extended support!
Starting from January 12, 2016, Microsoft Sync Framework 2.1 (including SDK and redistributables) has entered extended support. This change has an impact on how you receive software updates and support for Microsoft Sync Framework. For more detailed information, refer to the Microsoft Support Lifecycle.
I hope that can be an acceptable answer to your query.
Microsoft has stopped supporting Sync Framework. We'd a ticket opened with MS for one of the framework issue, and got to know from MS that the team which has originally developed the framework is disbursed and there is no support available.
Does it mean that open source part useless because server part can be
removed by MS in the future?
You can always download the SDK and keep a copy, so I don't see a problem on the "Microsoft removing it" question.
The question is does it mean that Sync Framework SDK (Server side
library) is dead?
In my opinion, yes. It is only a matter of time before the software won't work with an updated version of windows (last update to the SDK was August 2010). Once that happens or you discover a critical bug, you are stuck.
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.
So I have an app (tool) that uses .NET 3.0. When run on a machine that only has .NET 2.0 (like the default Server 2008 R2 install) it crashes miserably.
What I've seen so far is that people are using a shunt that will first check the .NET version.
Is there a way to build it or add some manifest somehow so that the user is warned of this problem (and hopefully be prompted to install .NET)?
I know this can be solved by an installer, but I have requirements that need it to be a standalone executable. (Ok this is hard to explain, but it's related to the a device driver. The tool comes with the driver, but the user shouldn't be forced to install .NET 3.0 if they won't use the tool.)
I just need to stop at the point where a cryptic "application has failed with exception 0xe0434f4d" message and at the very least give the user some idea of what happened.
Have not tested this, but this article about framework detection tells how you could detect the framework version from code. I'm not sure where your application fails and if injecting checks like this could solve your problem, but if you cannot use this in your app, you could perhaps create a small "starter app" in old .net 2.0 that performs these checks and then either tells the user to upgrade or starts your "real" app?
As I said, haven't tested this approach, it's just off the top of my mind.
This never makes any sense to me. Where are you going to stop? Are you going to make sure as well that the user doesn't install it on Windows 98? That the machine has enough RAM? That the user account has enough privileges?
Software vendors publish system requirements. You always quote the lowest supported Windows version, minimum amount of RAM, required disk space, minimum browser version, etc. Minimum .NET framework version belongs in that list too. The intention of this list is clear: don't expect it to work properly if you don't meet the requirements. If you do it anyway, it is your problem, not mine.
This is different for a consumer-level app. But when you install to Windows 2008 server, you are not writing a consumer app.
I would like the next update of our C# application to be the last one targeting the 2.0 Framework, and the following one to target framework 3.5. The application will be installed on a share on the client's server and accessed from a load of client machines which will need to have Framework 3.5 installed, hence all the users will receive the update at the same time.
I would like to get some way of pre-installing 3.5 before it is actually needed. My real reason for this, is that the framework install can take a long time and I don't like the idea of everyone being idle and the same time until the installation is complete.
What I was thinking was adding background code in our next update which checks to see if 3.5 is installed and that the DotnetFx35.exe is available and periodically offer to user the chance to install it (maybe by starting \\server\share\dotnetfx35.exe /q /norestart.)
I do not want to force an install via a group policy update as there will be machines that do not run our application and hence will not need the new Framework.
Does anyone have any experience with anything like this and/or any tips before I start experimenting?
This might not be the answer you're want, but its a point worth mentioning, I've had personal experience with the framework 3.5 not installing as it should on certain client machines, and the installer app, doesn't give any feedback on errors.
If you have a lot of client machines, just brace yourself for the possibility that some of these machines will have some install compatibility issues with framework 3.5 and you'll need to check the install logs or event viewer for more information.
You can have your clients install .NET 3.5 SP1 whenever they like - it is completely backward-compatible.
If it was me, I'd create a list of the client machines that are going to use the new app and just go around installing it. It would need to be done sooner or later anyway.
I'm wondering if is it there any easy, and common between .NET and Mono, way to retrieve machine statistics (eg. free space left, total memory, etc.).
Under the .NET 2.0 profile I was able to identify DriveInfo class, but in the previous versions (1.0, 1.1) and Compact framework, which I would like to support, there's nothing like this.
I already excluded the WMI API, since it's not supported by Mono and Compact Framework.
Anyone has ideas about it?
Mono supports the DriveInfo class. You should be able to get this information the same way in Mono as you do in Microsoft's .NET implementation.
There's no way to do most of those things with .NET CF without resorting to P/Invoking Windows Mobile API. So you can strike out cross-platform compatibility with it right away.
As per making this work on .NET 1.1 (I'll pretend you did not mention 1.0...) - why? Do you have any Windows NT 4.0 clients that require this?