Comment Feed for Decent .NET APIs (Coffeehouse on Channel 9)

Re: Re: Decent .NET APIs

Paul FLusk — Thu, 25 Jun 2009 12:46:12 GMT

Cheers dan, will have a look. problem with a lot of this stuff, microsoft broken links to blog posts, MSDN broken msdn links as well from google....

Regards.

Re: Decent .NET APIs

Dan Fernandez — Wed, 24 Jun 2009 17:31:25 GMT

Hey Paul,

Doug Handler put together the Bluetooth wrapper that Dahat linked (Coding4Fun Development Kit). We also have a cool Coding4Fun article with full details - BlueBoss Bluetooth Proximity Detection that will tell you when someone's Bluetooth cell phone is nearby (so your manager can't sneak up on you :) ). Is there a specific bug or reason you can't use the Bluetooth wrapper we've built?

BlueBoss Screenshot

Re: Re: Re: Re: Re: Re: Re: Re: Re: Decent .NET APIs

AndyC — Wed, 24 Jun 2009 15:46:23 GMT

Yeah, swings and roundabouts at that point, as they say. To be honest, the best choice at that point probably depends on the target audience. If its just that they might want to do clustering at some point in time, then go with a richer client. If they are likely to want to do clustering now and are liable to have access to the hardware to do it, go for Java/Hadoop and accept the v1 UI will suck and the development language will be a bit nasty. Getting the results as quickly as they can is far more likely to impress than a pretty UI and they probably couldn't care less if your development environment sucks.

Re: Re: Re: Re: Re: Re: Re: Re: Decent .NET APIs

Bass — Wed, 24 Jun 2009 15:20:22 GMT

This is a client server archecture, and I have very little against Java on the server, but we all know Java sucks on the client. (Eg: Swing, srsly).

So I could make the server software Java based and the client .NET based, but!!! my application is _extremely_ modular. It's basically a small core and a collection of plugins that build on that core, true for both the client software and server software. Some of these plugins are for perf reasons bindable to BOTH client and server. So using two languages complicates things like crazy, obviousally. Because I couldn't make plugins that bind in two both, and people getting this software will have to condend with the Java Plugin Framework and Mono.Addins.

I am just going to leave clustering for another day. Which means my program will be gimped for many real purposes (large datasets are not uncommon). This is hard any way you look at it.

It's just upsetting because the kind of calculations I am doing were almost designed for MapReduce. It's almost scary. Hadoop would be a perfect fit.

Re: Decent .NET APIs

Maddus Mattus — Wed, 24 Jun 2009 08:01:41 GMT

http://code.msdn.microsoft.com/WindowsAPICodePack

Check it out! Maybe some good examples in there!

Re: Re: Re: Re: Re: Re: Re: Re: Decent .NET APIs

Sven Groot — Wed, 24 Jun 2009 06:55:59 GMT

Technically you can get Hadoop working on Windows. You need a bash processor and an ssh server (e.g. cygwin) but it works. I think the guys behind Hadoop support this scenario for testing/debugging purposes, but for full-blown clusters it's not officially supported.

My PhD research is on data-intentive clustering solutions like Hadoop. I have actually written a somewhat similar clustering system in .Net, which is designed to run on Linux with Mono. However, before Bass gets his hopes up, this system is not even close to being usable by anyone but me, and that isn't likely to change anytime soon, if ever.

DryadLINQ from Microsoft Research allows you to run .Net programs using LINQ on a cluster, but it's not a published application, though MS apparently uses it internally in production environments.

Re: Re: Re: Re: Re: Re: Re: Decent .NET APIs

AndyC — Wed, 24 Jun 2009 06:22:12 GMT

And this is what people mean about cross-platform being expensive, every additional platform you want to be able to target increases complexity and decreases the options available to you. HPC is pretty specialised stuff as it is, Hadoop really only works with *nix based clusters (which as of today are easily the majority). There are solutions like Windows HPC Server with something like MPI.Net but don't expect a generic one-size fits all solution anywhere, HPC clusters are just too specialized for there to be an easy "it just works" solution to all of them.

If clustering is an important feature, I'd have to say you'd be better going with Hadoop right now. As much as I dislike Java, it isn't that different to C# and given that, odds are, you'll be running on a Linux platform it makes more sense than mono right now - given that there aren't many mature .NET clustering solutions as it is, getting one running on mono is an uphill struggle that makes very little sense.

Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Decent .NET APIs

Ion Todirel — Wed, 24 Jun 2009 01:49:02 GMT

>MICROSOFT ARE YOU HEARING THIS?

no :D

Re: Re: Re: Re: Re: Re: Re: Re: Re: Decent .NET APIs

Bass — Wed, 24 Jun 2009 01:27:23 GMT

I have given up on clustering for now. Maybe int he future someone will decide to make a open source, cross platform, fault tolerent clustering solution for .NET. Probably won't be me though, too big of a project. MICROSOFT ARE YOU HEARING THIS?

Re: Re: Re: Re: Re: Re: Re: Re: Decent .NET APIs

Bass — Wed, 24 Jun 2009 00:05:02 GMT

Because a large percentage of my customer base do not use Windows Server, and I will not make their operating system choices for them.

Re: Re: Re: Re: Re: Re: Re: Decent .NET APIs

dahat — Wed, 24 Jun 2009 00:03:12 GMT

Why so? More so... why not take a look at all of the libraries and runtimes it comes with.

Re: Re: Re: Re: Re: Re: Decent .NET APIs

Bass — Wed, 24 Jun 2009 00:01:34 GMT

Not interested in an OS, interested in a library. Must be cross platform (Mono/Linux+OS X, Windows/.NET)

Re: Re: Re: Re: Re: Decent .NET APIs

dahat — Tue, 23 Jun 2009 23:59:19 GMT

You may want to look in to Windows HPC Server 2008, not just because it's made by some folks down the hall from me... but also because it supports .NET... heck, you can even write your app(s) in F# for it if you want.

Re: Re: Re: Re: Decent .NET APIs

Bass — Tue, 23 Jun 2009 22:17:12 GMT

Basically what you are saying is if I want to write clusterable software, forget about using .NET? I'm sorry, I'm not familar with Java and I don't want to relearn a whole new BCL and language. But I need clustering. I need it. I don't want to have to reimplement Hadoop, poorly. So I am in a f**king prediciment right now and it's quite upsetting.

Sven once said he uses Mono on a cluster. Maybe he knows a good way to accomplish this..

Re: Re: Re: Decent .NET APIs

AndyC — Tue, 23 Jun 2009 17:00:49 GMT

Presumably because you count count the number of people with a reasonable sized Windows Compute Cluster, who aren't using it to run pre-built software, on one hand with fingers to spare. Generally, if your planning to run code across a cluster, you're going to be writing for whatever is available on it rather than picking your personal favorite libraries and packages, because it's a lot of work upgrading one and maintaining stability.

Re: Re: Re: Decent .NET APIs

Bass — Tue, 23 Jun 2009 16:37:56 GMT

I'll take a look at that.

Re: Re: Decent .NET APIs

Bass — Tue, 23 Jun 2009 16:37:43 GMT

I am in a serious predictment. I want to use this: http://hadoop.apache.org/core/

There really isn't any high quality open source .NET alternatives to this.

I do NOT want to use Java, this will make my life harder. But also not using Hadoop will make life harder. Why oh why can't someone make my life easier? :(

Re: Re: Decent .NET APIs

Paul FLusk — Tue, 23 Jun 2009 12:30:09 GMT

Cheers guys.

Sashman, thanks for the link, but it costs 499 bucks for a 1 year dev licence... not exactly what I was hoping for....

When I said I didnt want to use PINVOKE, what I meant was, I want to access an object in a managed framework, not have to use unmanaged techniques inside my app with all the complications at runtime that it can bring. OK, I take it on board that the compact framework is just that, but bearing in mind the importance of networking especially in todays computing, I am a little surprised that there are no add-on api's that could be bolted on to support hardware such as the IPAQ and HTC mobiles (or any system using mobile PC as an OS)... Interop is not an elegant solution in my mind.

The whole point surely of the .net framework and operating in an OO manner is surely that you use objects without knowing what is going on in the background, all the PINVOKE type stuff, Binary as well as error handling that causes all sorts of problems to the developer.

I programme on Java for example, I look up my handset, (W810i for example) I see the following online:

http://developer.sonyericsson.com/site/global/products/phonegallery/w810/p_w810.jsp

Java Micro Edition (Java ME)

CLDC 1.1 (JSR 139)

MIDP 2.0 (JSR 118)

Wireless Messaging API (JSR 120/205)

Mobile Media API (JSR 135)

Java Technology for the Wireless Industry (JSR 185)

Java API for Bluetooth (JSR 82)

PDA Optional Packages for

J2ME Platform (JSR 75)

Web Services (JSR 172)

I can see that if I program an app, I have access to the underlying bluetooth stack, PDA functionality (calendar, email etc) wireless messaging and its all done in a manner that means I can programme in an OO manner in JAVA ME.

Compare this to the microsoft 'experience'... I have hardware that ONLY runs with Windows Mobile edition, yet, I have NO access to the bluetooth stack OBEX etc without doing messy unmanaged code...

I LOVE the .net framework, its an easy to understand, easy to use programming language that has lots of potential. BUT, and its a big one, Java and objective-C are FAR more easy to programme with when you start wanting to interface with hardware. Surely a company such as MS could set up standards based hardware requirements for its software and help manufacturers out with this.

Mobile 7 looks really promising. Microsoft need to learn however that having a beautiful looking, quick OS running on a good quality pleasant looking mobile is one thing. The Iphone is not successful because of this. The Iphone kicks A$$ because of the proprietary apps you can download from small developers. The Iphone however is lacking in one area. Microsoft Exchange. If Windows come up with an OS that supports bluetooth, wireless and MS Exchange access, then NOW we are talking.

(as another aside, why no MS exchange API yet again? No MAPI support and no means easily sending/recieving mail via MS exchange via .net framework??)

Now, I am not naieve. If MS are honest, I bet they would say the proprietary paid-for APIs do exactly what I am asking for. I bet MS make big bucks from all those MSDN subscriptions too. But dont then wonder why Apple kicks MS into the grave when their Mobile 7.0 OS flops against the competition put up from Apple. MS have a real opportunity here to create functionality that will destroy blackberry and apple to boot as a result. All developers need are free APIs to programme with, not dynamic objects and a whole host of other arbritary upgrades to C# 4.0 which I cant really be bothered to go out and purchase VS 2010 for. If MS come up with the APIs, I will come up with the cash for a new Developer Studio.

Edit:

Oh, MS, just whilst I am ranting, why no decent graphing/charting APIs? why do I have to pay the likes of Dundas mega-bucks to put a bar chart in an app?

So, in summary microsoft, to give Steve Jobs a good kicking:

Windows Mobile 7 to ship to Mobiles which have standardised hardware to software support

Support for OO access to Bluetooth, Wireless and PDA style apps (calendar object access, contacts access, mobile funcitonality access), plus some form of BASIC grapahing/charting object (so we dont annoy our MSDN and MSDN Gold certified Dundas buddys off now).

Easy object oriented access to MS exchange server via existing network objects and above bluetooth or wireless objects or mobile GPRS connection.

IMPORTANT ONE!!! Access to GPS functionality on the mobile device with decent, useful methods.

A MS appstore with online training and support for $50 annual membership. This is key. Apple have gotten this completely right in limiting the apps that get put onto the Iphone. Profits come from sharing 40%/60% with the developer from downloads and recurrent licencing.

That is all! I am sure the worlds largest software manufacturer will not struggle with developing the goods!

Re: Decent .NET APIs

sashman — Tue, 23 Jun 2009 10:38:35 GMT

you might take a look at franson's bluetools, for .net 2.0. It also includes compact framework binaries.

Re: Decent .NET APIs

stevo_ — Tue, 23 Jun 2009 08:16:50 GMT

Eh? I think you need to look around, .NET has a sizable 'open source' community, the amount of projects people do and freely serve them up on codeplex (etc) is really good, before that people used to use codeproject (although personally that tends to make me shudder)..

It might not be as big as java (I don't know), but it certainly has a good open community.. especially on blogging where concepts are shared and discussed which are just as powerful to discover and participate in as a finished 'product'..

Also, pinokve isn't always do'able depending on your environment, but if you can I don't think its such a big deal to write a native wrapper and then a more .net style oo around that.

Re: Decent .NET APIs

blowdart — Tue, 23 Jun 2009 06:16:18 GMT

I DONT WANT TO HAVE TO USE PINVOKE INSIDE AN OO MANAGED PROGRAMMING LANGUAGE!

What do you think the libraries will end up doing? Bluetooth is an OS function, as is Wireless, any library you will find will have to go to an API call level via pinvoke anyway.

(As for bluetooth on the compact framework, well the compact framework is just that - compact)

Re: Re: Decent .NET APIs

Joe Chung — Tue, 23 Jun 2009 05:37:27 GMT

Have you tried IKVM (http://www.ikvm.net)?

Re: Decent .NET APIs

Bass — Tue, 23 Jun 2009 04:40:14 GMT

There isn't much of a open source community around .NET, Java is much better in this regard, I think. It sucks because I very much prefer C# as a language to Java but most of the libraries I want to use are Java-based.

Re: Decent .NET APIs

Ion Todirel — Tue, 23 Jun 2009 04:35:10 GMT

> I DONT WANT TO HAVE TO USE PINVOKE INSIDE AN OO MANAGED PROGRAMMING LANGUAGE!

why not, do you prefer the API to do that for you? it's not that they can't put this or that in there, it's just not possible to put it all in

Re: Decent .NET APIs

dahat — Tue, 23 Jun 2009 00:22:37 GMT

While I can't speak with any specific inside knowledge (as I have none on this subject)... I would suspect that the reason is that there are simply too many Win32 API’s for Microsoft or anyone else to wrap in a reasonable amount of time. More so the designing and implementation of the wrappers would take even more time so as to make sure they behave in a more .NET sort of way.

Sure, they could take a year or two off from working on the next major version and all of the new stuff it brings to fill this gap... or they could do what they’ve traditionally done and leave niches open for 3rd parties to fill through either paid or free solutions.

I agree that it does kinda stink when you find a 3rd party selling a library that does something you want to do in your own app... and in such a case you’ve got a choice, which is more valuable, your time or your money? Because if you don't have the money, you can usually build your own wrapper yourself with a bit of time and skill... and chances are depending on the APIs you are dealing with, you’ll probably have plenty of snippets to get you pretty far along.

When it comes to Bluetooth support... I'd suggest taking a look at the Coding 4 Fun Development Kit, you might also take a look at the Managed Wifi API project over on CodePlex.