Slashdot Mirror
Free Ebook on C# Programming
christophw writes "The programmers of SharpDevelop (better known to the /. crowd will be its sibling MonoDevelop) together with the publisher Apress made the book Dissecting a C# Application - Inside SharpDevelop available as a freely downloadable PDF document (no, no registration required). So if you want to judge for yourself if one can build an application of scale with .NET (or Mono for that matter), you now have a 500+ pages book for the holiday reading season (or the virtual bookshelf)."
Free tech books
Large collection of free online books at UPenn (not just tech)
Kind of like people who fool themselves into thinking they know what they are talking about?
I have found SharpDevelop to be very nice. The environment is very, very similar to VS.NET. It has a very professional look and feel, and I have found it a nice platform for building C# apps.
The only part missing in SharpDevelop is the ability to add "Web References", or references to XML SOAP resources. VS.NET automajically builds local interface classes and adds them to your project when you reference a XML SOAP resource, so that you have local classes and functions to call on. In turn, these call on the SOAP functions over the network. You do not need to know anything about the inner workings of the SOAP protocol to call upon remote functions.
Other than that missing piece, SharpDevelop is very fully featured and has yet to crash. Make sure to read the FAQ on their site if it does crash the first time you try to run it after install - their is a bug in the installer.
Great ideas often receive violent opposition from mediocre minds. - Albert Einstein
Have you used .Net? it is actually quite decent, and if you really need libraries it is possible to make calls to windows dlls. Perhaps you should give it a try, its not just a Java clone. When it matures a bit it will be an excellent way to achieve cross platform applications.
Without working in .NET for more than a couple months, with an open attitude, you can't really have a credible opinion. Just because it's Microsoft, you'll get the people who are automatically anti, and then you also will have people who are only Microsoft that will think it's gods greatest gift. Fox example, C# has some nice features such as using delegates for events vs. having to implement the observer pattern in java. But then you'll also have somebody who doesn't know about the SOAP toolkits in Java that can build WSDL proxies just like the .NET utility does. More than anything, it's all opinion. Use the right tool for the job. If I'm going to write a web service, I'll take an ASP.NET web service any day. If I need to parse a huge file, give me Perl. Can't all languages just get along!!!
Exactly how is .Net supposed to be a way to achieve cross platform applications? Microsoft have no intention of porting .Net to anything other than Windows, and have not provided assistance in the development of .Net clones (such as Mono). Full .Net is likely to remain Windows-only long-term.
For many of us, it's not a case of being pro- or anti-Microsoft, it's a matter of simple business sense: Having only a single supplier for a technology has never been considered a sensible strategy in any area of business - with the strange exception of IT. Perhaps there is a mistaken sense that much software is always short-term and temporary, so it doesn't matter if the neat and friendly development system you use comes from only one company, and runs on only one platform.
.Net seems very short-sighted to me.
Well, I was using Turbo Pascal on Windows a decade ago. Now I'm developing for companies which have rolled out Linux desktops!
Using
I developed a .Net application without cross platform in mind at all, and immediately it ran under DotGNU's Portable.NET. and microsoft has expressed an interest in alternative implementations of .NET. according to the Mono faq at http://www.mono-project.com/about/faq.html#msft
Question 38: Is Microsoft helping Novell with this project?
There is no high level communication between Novell and Microsoft at this point, but engineers who work on
Microsoft is interested in other implementations of
Given MSOFTS past history, I wouldn't bet my marbles on much help from them. A company I know that has a MSOFT product, and uses VMWare where they need to deploy on a non-MSOFT platform.
Except for the fact that .Net code already runs on other platforms see http://www.go-mono.com/ and http://www.dotgnu.org/.
Microsoft dont need to port it.
Mono
Portable.NET
DotGnu
So some of the biggest groups in OSS development seem to think that it might be a good idea to have an implementation of the CLI for other operating systems (Linux, OSX, Windows, Solaris, NetBSD, FreeBSD) and architectures (x86, PowerPC, ARM, Sparc, PARISC, s390, Alpha, and IA-64 to name a few).
What you have to keep in mind is that the CLI (the virtual machine in a sense) is an ISO standard (Java still isnt). The API's such as the System.* namespaces are still in a murky area and they may still be controlled vigorously through MS legal. But that doesnt stop any developer from using API's developed independantly - ie gtk#/Wx.NET for cross platform gui across the above mentioned platforms (still in development.. but it will get there soon).
Ciao
What you have to keep in mind is that the CLI (the virtual machine in a sense) is an ISO standard (Java still isnt)
.Net to legacy (look at how it has treated Visual Basic 6 developers, for example).
I would rather have a non-ISO standard from a company (Sun) that has had a solid reputation for decades for upholding standards, than an ISO standard from Microsoft, which has a solid reputation for dumping standards on a whim.
The ISO standard for the CLI will be of no use at all if Microsoft decides in a few years that an entirely new technology is better and relegates
Except for the fact that .Net code already runs on other platforms
.Net code runs on other platforms.
No. only some
The difference with Java is that if you have a J2EE or J2SE implementation on a platform you get all of it. Every last API and libary. Guaranteed and tested. There aren't half-implemented bits or enterprise features that aren't supplied.
My point is made by another quote from that site:
.Net is always likely to have significant sections with are 'not currently implemented'
Question 50: Can mono run the WebMatrix?
No. That requires System.Windows.Forms support which is not currently implemented.
A non-Microsoft
There is a very big difference between .Net and the OSS implementations - one is supported by Microsoft and the other's aren't. One meets a full (and possibly changing) spec, including libraries, the others don't.
.NET,Mono, or dotGNU then fine. But don't think you can influence anybody else to not use them.
.Net, I already successfully have. I manage development that HAS to be successfully cross-platform. Not partially cross-platform, but where a rich and full-featured deployed application can be switched between different operating systems at short notice, with no porting required for GUI aspects or enterprise features. Using .Net was out of the question. Just look at the notes on the Mono website:
.Net is NOT cross-platform, only selected parts. When you are developing critical business applications, you really can't trust a 'cross-platform' technology that is incomplete, no matter how much you may like that technology.
But if you don't want to use
Oh, I not only think I can influence people not to use
Unsupported technologies
Some technologies are very hard to implement or are being phased out by components in the Longhorn time frame. In some cases, we feel that they are not crucial to the future of the open source desktop.
With all respect to the Mono developers (who have done a great job), I don't want to rely on a system which has missing ('hard to implement') features. This is proof that
Plus the fact that just the CLR was submitted for certification, not the all-importent windows.forms and web.forms libraries every windows developer uses...
Plus the fact that if you do not live in the windows world, there already is a well-established cross-platform language, with the associated runtime, called Java. Well supported by major vendors like IBM, who basically told Microsoft to shove .NET in a warm, dark hole.
Plus the fact that if you do not live in the windows world, there already is a well-established cross-platform language, with the associated runtime, called Java. Well supported by major vendors like IBM, who basically told Microsoft to shove .NET in a warm, dark hole.
.Net in terms of the client side, but the full functionality is there: There are plenty of tools that allow ActiveX/COM integration with both SWT and Swing Java clients for example, and the new Native Desktop APIs are superb. Java works fine in the Windows world!
The thing I find it hard to get across to many Windows developers is that Java does Windows too! It may not do things as elegantly as
It's obvious that by the number of posts you've made on this thread (for a technology you have no interest in)
.NET is being embraced by many in the Gnome community.
.NET/Mono/dotGNU thread.
I have an interest in all IT technologies, as does any decent professional programmer who wants to keep their job.
that you are absolutely infuriated that Java is dead on the desktop and that
I'm not infuriated. Why should I be? I don't develop much for the desktop, and what I do is for Linux (well, actually for Windows as well, as I use Java). I'm only stating simple business facts. Strange that you should get so worked up about it.
Hilarious.
What is the joke?
I can't wait to see you furiously pounding on the keyboard on the next
Well, unless you have a webcam, you won't see!
Perhaps some debate involving facts that counter my arguments would be more constructive than insults..
It would be interse
Oh, I understand how bitter you and the other rabid microsoft haters are that Mono and dotGNU was even started.
.Net: significant bits are missing, and are always likely to be.
.Net. So what? This is of no relevance to the discussion at all. Java (all implementations) runs with complete API and libraries on far, far more platforms than .Net (complete API and libraries).
.Net
Not bitter, just puzzled. Why copy Microsoft? All that expertise could have gone into an entirely new bytecode/runtime/language combination - something that could never be threatened by patents or trying to catch a moving target.
I find it bizarre that so many developers who don't like Java (because of licencing) are prepared to work on duplicating Microsoft technologies. In the past, anyone who has come anywhere developing a successful clone of a Microsoft product as either been sued or bought out. That is not an emotional response, or Microsoft-hating, its all on the record.
And the most infuriating thing for the linux fangirls is that many Gnome developers actually like Mono/Gtk#.
Why should it be infuriating? Mono/Gtk# is a great technology, and has come far in a short time. Good luck to it! It would be great if Mono became a high-quality standard for cross-platform enterprise applications. Guess what! It runs Java too!
My point is that it is NOT
It looks like you've drunk the Sun koolaid regarding cross-platform. dotGNU already runs on more platforms than any Sun implementation of Java.
How is this relevant to anything? The Sun implementation of Java runs on far more platforms than the Microsoft implementation of
Mono and dotGNU are NOT complete implementations of
And finally, when did Sun support the JDK?
Like, since 1994 when Java was released.
Name five platforms that J2EE has been ported to.
Windows, Linux, Solaris, HP/UX, zOS, OS/390, MacOS/X, OpenVMS, NonStop, Tru64.
Name five platforms that Mono runs on.
Well, it's available as packages for Linux, Windows, and MacOS/X. I would imagine that it would compile for many other platforms, such as Solaris and BSDs (that's 5!). I would be surprised to see a version for OpenVMS or zOS.
This comparison is irrelevant anyway - it's not answering my point about incomplete APIs in Mono.
but just as much as Java has failed with "write once run anywhere
.NET will be dropped and they will release somthing new, but that's fine,
I think that almost all current Java developers would disagree with you here! Almost all the tools I use for Java development and all the libraries I use are completely platform neutral. In the early days there were serious platform-dependencies (there were thread issues on Linux for example), but those days are long past. I routinely transfer major projects between Windows, Solaris and Linux with no effort at all.
Eventually way downt he road
Those of us (like me) who spend a significant part of their time struggling to port legacy code to something modern and supportable learn to worry about such dropping of technologies. Java, for all its many faults, has been designed to be around for decades.
Can anybody admit though that virtually everything in the Java 1.5 release was just catching up to where C# is now?
I won't agree! There are huge new features in Java 1.5 with have nothing to do with C# - additions to the threading libraries, GUI enhancements etc. Generics have been under development for a very long time in Java (before C#) and are done in a different way. Annotations are, I agree, a catch-up feature (and very welcome).
And how old is mono? mono is just starting up, their goal isnt even to get api compatibility untill 2.0. and people are running mono in production environments with xsp already.
And how old is mono? mono is just starting up, their goal isnt even to get api compatibility untill 2.0
.Net.
A good reason to hold off using it for large-scale and business critical applications.
and people are running mono in production environments with xsp already.
Yes, but this STILL does not answer my point about incomplete APIs. I wish Mono well, and hope it takes off as a popular and successful development platform: an open-source and robust competitor to Java would be a great idea. But, it should stand on its own - and not try to be what it can never be - a full cross-platform implementation of Microsoft
And for what reason cant it be a full cross-platform implementation. the only parts they intend to leave out are things in the Microsoft.* namespace. and a lot of those they are implementing in the Mono.* namespace. when mono 2.0 is finished, you should be able to run anything not depending on something in the Microsoft.* namespace.
I thought Windows Forms was going to be essentially deprecated anyways, when Longhorn is released, in favor of Avalon/XAML?
Attention zealots and haters: 00100 00100
Let me ad VB help files, J++, VBScript for starters :]
The only missing bits are going to be the Microsoft.* namespace. This is insignificant.
If this is going to be the case soon, I'm certainly going to be more interested in Mono, although I'd still be very nervous about what MS would do if Mono got really successful.
Oh really? What kind of support? I'm somehow entitled to talk to a support engineer from Sun because I download the SDK? Or are you talking abut a support contract?
Support contract. You can buy support for Java from Sun.
Ok, you see like a reasonable fellow compared to the normal slashdork fangirls we see around here so I had a knee-jerk reaction to you and apologize.
That is very decent of you - thanks!
It's not that Java is bad. It's that Sun's stewardship of Java has been bad. All the way from McNealy screaming in the late 90s that Java was the platform and the OS was irrelevant to the disaster that is Swing.
I certainly agree with you in most respects here. Sun have never been good at knowing how to pitch Java. It should never have been released when it was, when it was slow and buggy.
Swing was absolutely a disaster when it was released - I simply couldn't believe people would write applications that had an interface so slow! Now it is vastly better, with the ability to use OpenGL acceleration. I think you can now write very reasonable applications in Swing, but it has taken a long time to get there!
As for J2EE: There are good bits and bad bits. The bad bits are the enterprise Java beans - cumbersome and hard to debug. The good bits (I think) are the JSP/Servlet parts, and the message queue features.
My personal like of Java is that no matter how bad Sun's implementation of things, you have a choice: if you don't like parts of J2EE, use replacements for it such as Spring.
And I can certainly respect your point about porting legacy systems to new technologies being a pain, but hey, it gives you a job (hehe).
heh - and a lot of others too!
I guess what chaps me the most about everybodies anti MS sediments is the fact that MS DOES provide good technologies, but nobody ever gives them the credit.
I agree that when they do things, they do things well. My grouch with them is based on nearly 30 years (!) of using their products (I used their cassette-tape-based Macro Assembler for Z80 in the 70s). They always seem to play catch-up with other technologies then act as if they invented them! From Windowing to Object Orientation. I remember a recent note on their website regarding the addition of inheritance to Visual Basic in VB.Net as 'Innovative'! Excuse me! I was using inheritance in Smalltalk 20 years ago! They could easily have added full object-orientation to Visual Basic a decade before and made things easier for developers, but chose not to, for marketing reasons. Its their combination of arrogance and nerve that gets to me.
when mono 2.0 is finished, you should be able to run anything not depending on something in the Microsoft.* namespace.
This is contradicted by the Mono website!
I quote:
Although WinFS, Avalon and Indigo are very exciting components, at this time it is too early to tell when those components will be available for Mono.
and:
Unsupported technologies
Some technologies are very hard to implement or are being phased out by components in the Longhorn time frame. In some cases, we feel that they are not crucial to the future of the open source desktop.
System.EnterpriseServices and System.Management come to mind, and we are unlikely to put any resources into the task. We would gladly host the code if someone cares to implement it, but they would likely remain unsupported features of Mono.
According to Microsoft, System.EnterpriseServices
"provides an important infrastructure for enterprise applications" and System.Management "allow management software to diagnose and correct problems in an enterprise computing environment".
This functionality is NOT absent in J2EE implementations. Namespaces such as javax.management are available in all J2EE app servers, including JBoss, the open source implementation.
Both of these quotes appear to be out of context, i'm not even sure where the first one comes from and the second one is in respect to running VisualStudio.NET programs under the current version of mono.
Oops, forgot to post some more information.m l
According to http://www.mono-project.com/about/mono-roadmap.ht
Other components like Windows.Forms, Directory.Services, Enterprise Services and JScript are being developed but are not as mature as the other components but are under development by various people.
Both of these quotes appear to be out of context, i'm not even sure where the first one comes from and the second one is in respect to running VisualStudio.NET programs under the current version of mono.
h tm l
They are not out of context. They are taken directly from the Mono roadmap page:
http://www.mono-project.com/about/mono-roadmap.
The second is not in respect to VisualStudio.Net programs. Its a general statement. VisualStudio.Net is not mentioned in that context at all.
Other components like Windows.Forms, Directory.Services, Enterprise Services and JScript are being developed but are not as mature as the other components but are under development by various people.
.Net is being used for. But, a large number of developers (perhaps the majority) develop server-side, and stable enterprise APIs are important to at least some of us. It's neither practical or sensible to start developing with Mono hoping that certain parts of the enterprise features will be stable and complete sometime soon (especially when their website gives contradictory information). The choice for stable enterprise features is currently between Microsoft .Net or J2EE. If you want portability, it has to be J2EE.
Yes, I have seen that page. It's the same page that mentions that some of the enterprise services are likely to remain unsupported!
That page gives a definite emphasis on the intended use of Mono: the 'open source desktop'. Well, fine! That's actually what a lot of
...I'm at least passingly interested in C# and if Mono can help my clients kick their MS habits, then it's all right in my book. As for ASP.NET being a right tool for the job- that's quite debateable. In all honesty, a Java Servlets and JSP engine is in the same class- in fact, it seems more robust (At least on the Linux side of things...) than IIS and ASP.NET is- or IIS/Apache and Mono's rendition of the same.
Having delegates seems to be nice, but I can't say that it produces better code- just easier to follow code. Until I see that it's better all the way around, I'm going to be sititng on the fence on that one...
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
Mono and dotGNU are NOT complete implementations of .Net
Linux is not a complete implementation of Unix