Ten years of .NET - Did Microsoft deliver? Microsoft closes The Noughties by trying to keep up with competitors and to remain a top destination for developers by embracing cloud computing and open source. It opened the decade with another massive platform shift, though: the introduction of .NET. .NET was announced at the first TechEd of decade in Amsterdam in the year …
You're right about Microsoft not using .NET enough (eating your own dogfood, as they say in Redmond). The best example of that is the javascript interpreter in IE. .NET has outstanding JIT compiling technology, something Microsoft pioneered for Visual Basic many years ago, and it came with a JIT compiled javascript. But it's not in IE! Now years later, you have the other browsers showing off their new JIT'ed javascript and embarassing Microsoft in the benchmarks.
Talking with a friend who manages a large Java effort, they regret not having used C#. The real problem for them was the confusion of different class libraries. Perhaps if they had established some conventions at the beginning, but knowing their team of hackers, that would have been like trying to herd cats.
.Net seemed simpler than Java to me and the development tools were much better. Over the course of my training in Java I learned how to create command line programs that could use different functions depending on the option you chose. In the same amount of time using C# I learned how to create windows applications that could link to databases, sort the information in the databases, output the information in the database and perform calculations on it. I only did 9 months total training but I think that was enough to get the gist of what the difference was between a cross-platform running in a virtual machine and a platform specific language. Of course .NET is only really good for making Windows applications but that is a hell of a lot of machines to be writing for if you choose that option. The only reason I can see for choosing Java is that soon smartphones will be a lot more common and writing for those could provide a large target market.
Where .Net scores is that it is possible to quickly build simple applications in a pretty much drag and drop fashion, something Java has never managed to match, altough JSF is getting there and JavaFX may actually deliver it. Undoubtably a powerful feature and one of the things that put .Net where it is today.
My experience though is that as soon as you need more complexity, the cost of building in .Net is pretty much the same as the cost of building the same thing in Java. The old Microsoft adverts showing non-.Net developers poring over plies of diagrams always amused me because it was exactly the same in .Net world for the complex systems...
Yeah, click and drop component programming is RAD. It's a very nice feature of C#.
The irony though is that the guy who brought it to Microsoft had already helped implement it for Borland. Anyone who thinks that WinForms is a new idea whose time had come has missed a big trick. I was doing that kind of GUI development in C++ back in the mid-90s.
Unfortunately Borland failed to modernise their compiler or put funds in Builder so leagues of C++ developers were stuck slaving away in MFC or WTL. Poor bastards. Unfortunately after a takeover a couple of years ago I ended up having to work on legacy projects using MFC and WTL. Years of managing to avoid it came to nought.
It's a cruel world sometimes :-/
Paris because I need cheering up.
If you are writing an application that has a client and server portion and you are going to sell it commercially. What would you say as your sales pitch?
"Runs only on Windows 7, and Windows Server 2008 and SQLServer only" or
"Runs on Windows/Macs/Linux/Unix client and Windows/Macs/Linux/Unix servers and any Database you care to mention".
Which one do you think will work the most?
The latter is where we are and guess what language we use? And the whole lot is written and deployed with open source software. Bang for buck, you bet.
Welcome to the real world.
You have obviously never sold anything in your life. Customers could not give a toss what platform the application runs on - they are buying an application not an ethical debate about platforms.
And if you are a 'commercial company' developing an app it makes commercial sense to create it using the most productive development environment (i.e Visual Studio) and target it towards the most widely adopted platform (Windows).
... Because , surprisingly often, they already have the platform and they aint going to buy a new one because your application requires it. And if it's a server-based app (like virtually all enterprise software) that platform is likely to be Unix/Linux.
If you're just making desktop toys then by all means lock yourself into Windows. But from your facile, ignorant and ill-considered comments you sound like a salesman, so you probably wouldn't understand the difference.
Hah hah, I AM a salesman but that means I actually talk to real, live customers about what they actually going to do.
As opposed to being some pathetic techie sat by himself in a dingy basement imaging what it would be like if he had a girlfriend and hypothothising about why Linux is better than Windows (ring any bells?)
And as for your last point, I have never come across a large company that does not use Windows as a server platform. Sure they might use Unix/Linux as well, but they sure as hell will be using Windows alongside it. And I am talking about proper, big companies. Not two bit little minnows of the type that you probably (just) managed to get a job with.
Honestly, some people on this site think they know what they are talking about wheras in reality they know absolutely fark all.
Did I touch a nerve darling? You seem awfully upset.
I didn't say anything regarding the relative merits of Windows Vs *nix - merely observed that whilst Windows has the lion's share of the desktop, the opposite is true of the server market. I'd have thought an expert like you would know that. Never mind - it's the weekend so you can go for a nice lie-down in a darkened room until you feel better.
Still, it was a good guess that you're a salesman though, wasn't it?
If that's your attitude, I'd hate to work for the poor folk you employ to do your software support. But then, I'd hate to work for a software company driven by the bullshit of the sales department, rather than one where software specifications are made according to sound reasoning, and the needs of the client.
This post has been deleted by its author
"The reason is simple: Garbage Collected Languages are simply not up to the task when it comes to high-performance, high-throughput and low-latency applications."
True these languages will probably always be slower than applications written close to the metal in C or C++. But there exist a wide range of values of performance cost for different GC languages. GC languages also have different improvement factors in relation to programmer productivity from each other. Programmer productivity is the critical constraint to be optimised far more frequently than not, unless you are a live action roleplay games developer or working on system software or realtime control systems.
Perl and Python are GC languages. These both provide much higher programmer productivity than even Java and C#. Python is unlike Perl in the sense that Python source code is usually much more readable. I was changing a Python application I wrote myself 3 years ago earlier today, with a hard deadline to meet and it worked perfectly and on time in a small virtual machine server memory footprint for dozens of concurrent web application users, with no apparent latency evident.
I see the usual ‘” everybody else is a lazy sloppy programmer so by inference i must be a guru” brigade have been prodded into wakefulness. I do have to chuckle into my sleeve at the arrogance of comments that imply that until one is a some sort of coding uber god that one should not have the audacity to write any code least of all attempt to compile an application.!
Silliness. In the real world people use tools to make things. A programming language is a tool. At the moment i am sitting in front of a terminal writing a java app. I use java because I know it to the extent that I can write a functioning app suitable for my purposes. I’ve dipped into other languages as and when they have suited my purposes Perhaps I should stop what I am doing and spend the next couple of years or so until I am completely and utterly proficient in this and any other languages you may wish to suggest We learn through the application of knowledge and the identification and correction of mistakes.
@Rattus Rattus What is this world you live in where an organisation's systems are nomadic, constantly moving from platform to platform and back again? Not the real one, frankly! "Ooo, hang on, it's December again, time to migrate everything to a different platform! Good thing we're IT geniuses and our intranet can run on an Amiga 500!"
Bloody loony, no wonder you work for a government department -- probably the treasury -- no commercial organisation would touch you!
Platform portability is an odd thing. Firstly, anyone who has ever tried running a reasonably complex Java app on a new JVM will usually testify to it being a non-trivial process. Platform portability doesn't really work on a system where it has been designed from the ground up to be portable. Certainly I would never trust a production application on a new JVM without a lot of testing.
C# is actually almost as portable. People have written .Net runtimes for more than just windows.
Finally, as the previous poster makes clear, you don't go and rebuild your entire infrastructure every 5 minutes. Platform migrations are few and far between.
but we still want portability. We have a mix of servers, desktops and embedded systems with a range of operating systems. It's not at all unusual to want to use the same application on two entirely different platforms, and if it's written in something portable then that's easy. If it's written in .NET then we're SOL and have to try to find some other bit of software that's "close enough." Or, in many cases, we have people that just have two computers on their desk instead of one. How's that for government waste then? One computer would suit fine, if only the apps were portable. Therefore, we won't use something non-portable unless we have no choice.
We are a softhouse. One of our clients is a pure Sun/Solaris environment. Sun as in SPARC, not x86 Sun.
Well. We develop for them in Java. Ours desktops are Windows. The server we use to do the initial testing is Linux+Tomcat. And the client does the final validation on his test servers.
The height of portability was wen ours desktops where Windows (and CPUs) 32 bits, and the Linux servers 64 bits (OS and CPU 64 bits). The Sun machines where 64 bits too. Beat this with C#
So, tell me. Why would I want to use something that ties me up with a vendor?
I wonder where you get your JDK from? Mine comes from Sun. Of course, I sometimes have trouble patching it on our Sun servers (we don't have any other kind) because Sun's support servers sometimes forget I'm on the contract and, well, you can't get the JDK from just anywhere.
As for running anywhere, anytime, anyhow, for any real world Java enterprise-level deployment you are looking at running some sort of Java Application Server and they don't come free unless you are willing to go the "Glassfish and another half year's worth of development time" route. The quote we got for Websphere when we needed to deploy P8 (Java-"enabled" to the gills and therefore won't run unless you pony up for the component not mentioned in the sales literature) was so far out-of-court we're still laughing at the rep when he shows his face.
Actually, I don't have an issue with Java as a language or a culture, just with 100% of the programmers whose work I've had the "pleasure" of using since I came to this Java-only Sun-infested site. Every one of them carries a huge chip on their shoulder (whooda guessed so from the comments here, eh?) and uses their custom GUIs to carry their political message to the masses.
The upshot being that every new window is a voyage of discovery to see what former standard behaviour has been re-interpreted for the user's "convenience". The guy who always felt that the "close window" button never should have been in the top right corner, the one who doesn't believe in default cursor positions, the one who always hated "xmit == click on accept" semantics, and a cast of dozens more all go to make for a fuller business experience while at the same time slowing down actual work to a manageable speed.
And lets not forget the buggy screen refreshes, lost key-clicks and the rest of the box-of-tricks Java (on a sun workstation before you gets uppity) brings to the table.
But the good news is this is all portable so these 'features" aren't confined to Sun systems.
My employer has been steadily moving from Java to .NET (in point of fact, we're pretty much there except for some third-party apps which rely on Java). Clearly, we're a majority Windows shop, and my experience is that .NET is much simpler to implement than Java. Sure, there's the periodic necessity to install a new Framework version, but it's no worse than having to update the JVM (or being afraid to update lest the new minor release break existing code). My experience is also that .NET code tends to be quicker and more reliable than Java code. .NET may not have done everything Microsoft set out to do, but it's firmly entrenched and better than its main competitor.
It may also be worth noting the various Express IDEs that Microsoft has released, including Visual C# Express and SQL Management Studio Express. Effectively allowing your average hobby developer and small-business contract developer the ability to create Windows applications.
This means that students and hobbyists alike can be exposed to .NET for free, which in turn should encourage them to move into .NET development. I realise Java has free tools but one of my first gripes from the early days when .NET and C# first came out is that it wasn't free for a hobbyist to play around with C# - and now it is.
This post has been deleted by its author
it really depends on which market you are aiming at - some won't know what a Client Server application is - even though that is what you are selling them.
and writing for .net limits you to Windows XP - Vista, not Windows 7 - oh and you can use other DBs than SQL server.
The big problem Microsoft has is that it has nothing else than the best way to run Win32 and Win16 applications. That's why Vista didn't sell.
.net is just a marketing hype. Compared to C++ it may be good, but it's not really suitable for application development. The .net runtime is just _huge_. And it's typically not installed on most computers.
There are free and open source alternatives like Lazarus, which is a plattform independent Delphi clone. Unlike C++ and C you can have runtime checks and exception handling. (No, runtime-checks barely have any impact on actual performance, those times are _long_ gone)
C# should get more praise I think as it's a fantastic language that continues to improve at a rate of knots. 3.0/3.5 and LINQ in particular are the first languages to have got me excited the way Smalltalk did 25 years ago. And because it's so expressive and has this increasingly declarative and functional style, it is arguably the best language for those onboard with the software craftmanship. Also because .NET is so productive, it has an excellent and natural fit with Agile/XP.
@Anonymous Coward I code in XAML pretty much every day and it's absolutely awesome. Our product is differentiated in part by a very advanced (for want of a better word) UI and the stuff we are able to do easily in XAML would take months in Unmanaged C++.
Our business is a web-based service and we're very happy that we picked .NET to build it with. The .NET class library is excellent, far richer than other platforms we evaluated -- the only missing or weak area being charting controls. However, Microsoft's purchase of Dundas a year or so ago, and MS Chart now being a free add-on, has more than remedied this.
We've now built up a strong library of our own extended and custom controls, which means development of new functionality is rapid, consistent, and rock solid. Compared to previous projects done with PHP (for example), we are in a much better place.
Java was a serious consideration for us, but given that cross-platform was of no interest, and the relative strength of Visual Studio as a development tool, .NET has proven to be excellent.
It has been my experience that coders do not pick Microsoft products for anything other than gaming. Microsoft is picked for them. People who do code as a hobby, don't tend to do it in .Net.
It is the management of businesses who become seduced by Microsoft. Well, they know no better, do they? And the marketing from Microsoft is right. So management announces that they will be an MS house and use MS tools. They then look for people who have experience with .Net, SQL Server and so on. Microsoft products cost a lots of money, proof surely that they are good. Anway, Excel and Powerpoint are cool tools, right, so the rest must be up to this high calibre.
It becomes a vicious circle. People develop their experience with MS products and a critical mass is formed.
I like SQL Server, but it comes at a high price. I like C# too but I find sites developed in .Net to be *slow* [1]. Maybe the developers or the site-design is poor, I don't know. It's just that I can't ever use the word 'responsive' in a positive way with MS products.
These are just opinions based on my experience of Microsoft products. No doubt there are swift apps built on elegant code.
happy christmas all
[1] I define 'slow' as taking longer than 3 seconds for a page to load on a broadband or better connection.
I have chosen .NET, because it's got a rich set of libraries, fantastic language features and an excellent development environment. It can be used on the majority of PC's in business (and at home). It's a pain having to ship the run-times "just in case" the user doesn't have them installed, but this isn't an issue with 7.
The best thing about .NET is the rapidity with which I can build and deploy applications. I'm not talking about internet development here, I'm talking about LOB applications.
No self respecting coder would EVER use the phrase "fantastic language features".
And if you picked .Net to code as a hobby (as you claim), why would you care that "It can be used on the majority of PC's in business (and at home)". You should only care that it runs on your machine(s).
"If the goal of .NET was to see off Java, it was at least partially successful. Java did not die, but enterprise Java became mired in complexity, making .NET an easy sell as a more productive alternative."
- It might be an easy sell cause the people doing the buying are not the ones who'll do the coding.
- When written by good coders Java can be beautiful and simple. However, in the hands of morons it can turn into an ugly thing that's entirely too complex for their comprehension abilities - just like any language, including C#.
- The promises of marketing (perfect integration, has every tool for your needs, you can do everything with the mouse, you won't need to write a line of code and all the other crap) are just crap. Managers eat that shit up as if there ever was a tool that could cover all the needs of a large application. Every particular application has its own specific requirements and quirks and if you don't have good people to implement a proper solution not even .Net can fix it for you.
- Productivity might be better if you develop for IE only. Otherwise for the server side a Java coder who's experienced with a certain stack (say Hibernate, Spring) can develop just as fast if not faster.
RE: The article:
"It took Microsoft a further eight years to come up with the idea of a client profile"
They introduced this after 3.5 which added fatties such as WCF, WPF ontop the existing framework. .NET 2.00 is still a pretty small redist. IMO they didn't really need to use client profiles before this.
I've been using it since about 2002 and love it. The amount of thought that has gone into it is amazing and it is beautifully designed. In the 8 years I have been using it I have only encountered 1 bug which was a teeny UI issue on Vista.
In terms of productivity boosting it is excellent, I don't know about these other coders that seem to favour scouring .h files and reading potentially inaccurate documentation. I guess that might be fun but I'd rather just add an assembly and check out the metadata for the docs. Hell, I can even Reflector the assembly and read the actual code instead.
The number of tools, APIs and whatnot is comprehensive. .NET covers a lot of stuff and in most cases you can remain totally in the managed world. Sure it's technically bloat, but if that bloat ensures that my string is...... er.. well a string and I don't have to worry about memory allocations (0xC0000005 anyone? Ain't never seen that caused by .NET) then i'm happy to have that bloat.
To state (as one brave soul did) that you can't create a "proper" application in .NET is an utter, utter nonsense. I've created and worked on numerous apps of numerous size with .NET and any performance issues have been due to shit code, not .NET.
While I agree that there might be more "inept" developers in managed environments than unmanaged ones if you're _really_ competant you'll develop good code and you'll also be able to recognise that a managed environment is logical abstraction and progression to build ontop of a native stack.
I know its nice to talk computer (bits, bytes, pointers) but I prefer to talk in human terms (numbers, strings and references as an abstract concept instead of the absolute pointer). The two are also not mutally exclusive so my knowledge of the former is not lost by commonly using the latter.
.NET Compact Framework sucks tho. Well....mebbe that's too harsh but it's disappointingly sparse in comparison to FF 2.0.
This post has been deleted by its author
ADO is ridiculous. It requires much more coding for simple connections than DAO does, and DAO is closer to standard SQL than ADO is.
If M$ had really wanted .NET to take off, they would have included an upgrade wizard that modified DAO code to ADO code, or at least provided a standard class that didn't require initial recoding.
OK, come on, you must be joking; you're not? You must be retarded.
Macros and all of a sudden you (put a really bad expletive deleted here) think you have done something for programming? If I wanted macros I would have continued with Assembly.
Dot net should have been led out behind the barn and quietly put down; the concept purged with extreme embarrassment.
OK, hold up your hand, someone out there thinks it was a 'bright' idea.
D**bass.
All Microsoft had to do to guarantee unqualified success of .NET was to insure that Classic VB code ran in the new environment. (If it produced identical results, unlike some of the very few portable snippets today, that would of course have been a bonus.) Instead, they cast off the largest developer community the world has ever known, because the C-freaks who produced it purportedly were unable to grok that Integers were 16-bit and Longs were 32-bit. True story, from the guy who patented iSnot.
In general .NET is a success, but it has its problems. First a few corrections to the other comments.
,NET languages are not interpreted, like Java the code is compiled to an intermediate language and this is just in time compiled (on a per-method basis) at runtime by the virtual machine. The JIT compiler was written by people from the VC++ team and hence is optimised. The performance of JITted code is nearly as good as native C++.
Incidentally, WinForms is not a performance hog. It is a very thin wrapper over Win32.
Microsoft have always been careful to avoid the Java "write once, run anywhere" concept, for good reason. As every Java developer knows, it degenerates into "write once, test everywhere". Consequently .NET code is compiled for one platform. Yes Silverlight can run on different platforms but that IMO is an exception.
One of the principle reasons for .NET was the security model. .NET security was in addition to NT security and added a new concept: code gained permissions to execute other code based on criteria other than the logged on user (things like the source of the code, X502 certificate, hash etc). This is a very important change. This model stopped the existance of .NET viruses (other than the most trivial phishing malware).
Up to Longhorn there was a semblance of a strategy. Longhorn was supposed to be the culmination and the OS was supposed to be substantially .NET. The version handed out at the 2003 PDC was many years of development, and all development had put .NET first. The shell was based on WPF and part of the file system was based on an object database called WinFS. It was ambitious.
However, after the PDC Microsoft very hurriedly dropped Longhorn, re-jigged Windows Server 2003 and added a slimmed down version of .NET. WinFS was gone. Initially they didn't even install WPF or WCF. They went from an OS that could not work without .NET to one where they appeared to be embarrassed about the framework. My constant comments about this tepid acceptance of .NET were not welcomed by Microsoft :-( and later I learned that there was a lot of internal politics involved at Microsoft between those who supported .NET and those who didn't.
The problem with this political battle is that the overall strategy was lost. There was no longer a credible plan to what .NET represented. The result is a confusing plethora of libraries and additions to the languages. This isn't to say that .NET is bad - quite the opposite in fact - but it has lost its way. There does not seem to be a coordinated strategy.
What is its future? Well, the first point to make is that COM will always be in Windows, .NET will not, and cannot, replace it. (Simple example, drag and drop uses COM. Without COM you will not be able to drag and drop items between applications.) But similarly .NET will always be in Windows, since there are tools in Vista and now Win7 that are written in .NET. As yet Microsoft does not trust .NET for their services, but they do allow third parties to write services with .NET (knowing that Microsoft do not provide Windows services written in .NET should you trust a third party .NET service? I cannot answer that.)
Microsoft will continue to develop the library and framework, but the developments will be sporadic, they still have no overall strategy of what .NET means to the Windows platform. If you intend to write a new application then the best course is to write it with .NET: VS makes it easy to do this. If you have an existing application in C++ or VB (classic) keep it in its original language. You can wrap existing code as COM objects since .NET access to COM is high performance. (However, porting native code to .NET is a recipe for disaster.)
If only Microsoft could decide themselves what .NET means to the Windows platform!
The success of .NET cannot be analysed as a discreet entity. It is part of the Microsoft ecosystem and should be treated as such.
It was created in response to the threat that cross-platform applications would provide consumers with a path from Windows to other operating systems. .NET does split the developer community, and so is working as planned. When the waters are murky people stick with what they know, i.e. Windows. Whether this effect is enough to offset Microsoft's investments in the technology is something only Microsoft's accountants can answer.
Business considerations aside, there is still a dearth of killer consumer applications in .NET. I think this is due to the fact that while .NET has been good at slowing the spread of applications across desktop platforms, it has been far less successful at keeping them off the web. I would have like to see a table of this kind of data presented above.
I'm aware this post is unduly cynical, but this should have been part of the article's analysis, and someone has to bring it up.
I support a c++ app, distributed to 60,000+ desktops that has an auxillary VB6 database app to support certain aspects of it. Once VB6 was discontinued, we looked at switching the support app to dotnet but were (and are) horrified to see the penetration rates of the dotnet framework out there on desktops in 'office land'. We tested the target platforms directly for runtimes from the VB6 app, not relying on generic 'industry data'. We concluded that we would have to emply extra staff to deal with all the reboots to implement a dotnet solution.
Dotnet failed us.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
