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?
Related
I've seen questions and answers about why .Net framework 3 or 3.5 or 4 are good. But I've got an app that compiles well in all of these versions including 2. I was curious to know whether there would be a problem if I compile my app with .Net 2 and distribute it. (Version 2 is natively suuported by many versions of windows.)
Is there a performance or speed issue with the older versions or something that I should know of?
Many Thanks
No, there's no problem continuing to use .NET 2 if you want to.
To my mind the principle benefit of using .NET 3.5 would be that you could use LINQ (without extra libraries such as LINQBridge) which may well make your code simpler.
.NET 3 and .NET 3.5 were additions to .NET 2, so there shouldn't be any performance difference - with the caveat that .NET 3.5 came with .NET 2.0 SP1, so there were a few modifications... but if you run a .NET 2.0 application on a machine that has .NET 3.5 installed, it'll be running the SP1 code anyway, so it makes no difference whether you've actually targeted .NET 2.0 or 3.5.
well,not really.
If your app runs on 2.0 then it can also run on 3,3.5 and 4.0 since they are backward compatible.
If you get along with 2.0 then compile for 2.0 there is no reason to artificially raise the requirements.
However if you are not using any 3.0+ features I would recommend you to learn about all the new features. It will speed up your development and improve your code.
How far back does the argument hold? If the original question had asked why go with 3.5 or 4.0 if 1.0 works would the answers be different?
At some point there's risk in clinging too long to an out of date platform. You might still be okay with 2.0, but 2 versions behind might be as far as I'd push it.
I think it really depends on your use-case.
Is this app:
A client you deploy to all sorts of windows clients (e.g. consumer-type win app)
A client you deploy to your enterprise (and they'll manage .net versions)
A server-side app on your data center
A server-side app you sell and others install
etc.
If it's #1, then you want to target .NET 2 if that suites your needs. You probably want the least amount of frictions for your users in terms of not updating .NET. Windows 7 comes with .NET 3.5, Vista with .NET 3 (similarly for the server OSes).
If you know you're targeting Win7 users and above then .NET 3.5 is fine. As the other posters mentioned, the main benefits of .NET 3.5 vs 2.0 is really
LINQ
WPF
WCF
If you are a #2 scenario above, then by all means, use .NET 4. There are many improvements including LINQ, but also in the runtime and if you control the systems then it's definitely worthwhile to be 6 years in the future from a software perspective. Even more so for #3.
For #4, you'll have to decide whether that's an issue for your clients. Most the time it's not, but it can be.
Of course, you can use VS 2010's Multi-Targeting feature to use modern tools regardless.
Not too long ago I wrote the client part of http://chatpast.com which has to be installed. As painful as it was, I wrote that in Windows Forms and .NET 2.0 because that was the least likely to cause problems for users and require a .NET install / upgrade. But the server-side code is all .NET 4.0.
So I guess you can even say that it's not purely and either/or choice. Think about what makes sense for each part of your deployment.
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.
I'm late to the boat and have only just now started using Core Data in OS X / Cocoa - it's incredible and is really changing the way I look at things.
Is there an equivalent technology in C# or the modern Windows frameworks? i.e. having managed data types where you get saving, data management, deleting, searching all for free?
Also wondering if there's anything like this on Linux.
Not for C#, but,
For Windows and Linux, Core Data has been made a reality through Cocotron. This is not a solution for everybody, probably just a solution for a few, but is completely awesome.
Probably the closest thing to Core Data on Windows is the ADO.NET Entity Framework. Unfortunately, it's a lot lower level than Core Data. For example, you have to create and maintain your own database schema.
I'm devolping on Compact Framework 2.0 SP1 and when I try to use Math.Sinh it throws me a Not Supported Exception
If I can't use this function, is there any other alternative?
Thanks!
sinh(x) = (e^x - e^-x) / 2
see wikipedia
So you should be able to write your own function !
We use OpenNETCF to gain access to a lot of APIs that the Compact Framework just doesn't support. The Math package is just one of the them. Indeed, OpenNETCF does support the Sinh function.
OpenNETCF.Math2.Sinh(angle: double)
If you do a lot of work with the Compact Framework, the OpenNETCF Smart Device Framework can be very helpful.
Look at the PInvoke signatures of Math.Sin for example, I suspect Sinh would be there on the mobile device, but just not mapped/imported into the CF to save a byte or 2.
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.