When speaking to developers about WinFX one question that repeatedly comes up is, “WinFX sounds great, but what happens to .NET?” Vice President S. Somasegar describes the decision to rename WinFX to the .NET Framework 3.0. Now the WinFX technology you know has a name that identifies it for exactly what it is – the next version of Microsoft’s developer framework.
Why don’t they just name it SuperDuperFramework or Mega.NET. Or something else sounding equally silly as SuperFetch or PowerShell. Ugh.
Edited 2006-06-10 17:46
I dont understand how does mono can compete with microsoft.
Mono framework is only a small part of the new WinFX…
Edited 2006-06-10 17:53
I dont understand how does mono can compete with microsoft.
Mono framework is only a small part of the new WinFX…
Well, quite simple.
Mono runs everywhere. MS.NET doesn’t. And 3.0 features will be only XP and up. So you can forget to run 3.0 executable on 2000.
Mono is consistant, MS.NET isn’t
Err… Mono is a .NET implementation. Currently not supporting .NET 2.0, but still a .NET implementation.
Sooner or later they will add the 3.0 features as well, and as long as the programs don’t use native stuff together with the .NET stuff, they can be run anywhere you have a conforming implementation.
It doesn’t compete with Winfx, but with old C/Gtk+ or C++/Qt frameworks for desktop applications.
It has nothing to do with MS or windows.
Mono was made to be a free Unix developement framework with additional bonus in ability of utilizing VS.net for developement and making switch for windows devs easier.
It has to be somehow comptible but 100% strict compatibility was never a priority (it would end up as wine otherwise).
They have odds to become both. API wrapper for binaries (bytecode) like Wine and cross platform development framework. On some things, they already joined forces with wine (win32 calls for example).
A big role of Mono is in easing development of cross platform applications. It basically could allow mainstream windows developers to convert their program to make a linux app in 5 minutes. Or even allow many windows-only binaries to run.
Of course Microsoft did everything to prevent it, so they developed windows forms and other commonly used stuff outside of basic NET definition. However some mono folks started reimplementing those API’s (windows forms for example).
Regarding legal problems, I doubt that MS is going to sue Mono or anything like that. That could just trigger nasty anti-trust lawsuit in USA or EU.
Of course Microsoft did everything to prevent it, so they developed windows forms and other commonly used stuff outside of basic NET definition. However some mono folks started reimplementing those API’s (windows forms for example).
The goal in developing WinForms, et al., was not to prevent cross-platform development. It was to expose the Windows platform to the CLI. It’s outside the CLI spec (not the .NET spec – .NET is a specific implementation and superset of the CLI) because it is a platform library. Mono similarly contains *n*x-specific libraries. Expecting them to include that in the CLI would be like expecting Win32 to be included in the C++ spec. If they wanted to discourage cross-platform development, they wouldn’t have given C#, the CLI and C++CLI to ECMA and ISO in the first place (and continued to do so with subsequent iterations).
Edited 2006-06-12 13:25
The goal in developing WinForms, et al., was not to prevent cross-platform development. It was to expose the Windows platform to the CLI. It’s outside the CLI spec (not the .NET spec – .NET is a specific implementation and superset of the CLI) because it is a platform library. Mono similarly contains *n*x-specific libraries. Expecting them to include that in the CLI would be like expecting Win32 to be included in the C++ spec. If they wanted to discourage cross-platform development, they wouldn’t have given C#, the CLI and C++CLI to ECMA and ISO in the first place (and continued to do so with subsequent iterations).
OH pulease! releasing the specifications does not automatically glue Winforms to win32, no more than Java being glued to Solaris or Sun Hardware.
Having winforms being written using Cairo for the back end PROVES in itself that it can be implemented without win32 dependencies, thus making the above excuse nothing more than a convienent way to get out of the ECMA clause relating to platents and royalties.
Little wonder the only ones moving to dot net are the drooling VB programmers – too bad they’ll need to drop their goto commands along the way, and learn some good programming habbits.
I though MS didn’t wanted anybody to implement WinFX or else they would sue? If this is still true Mono wil have a hard time. I guess WinFX will surely not be specified in the .Net ECMA standard.
I’d prefer to have a solid Mono .NET 1.1 than a flaky mono .NET 3.0 !
I’d prefer to have a solid Mono .NET 1.1 than a flaky mono .NET 3.0 !
Crikey, a solid Mono already draws so many resources that the lights dim in my neighbourhood block every time I boot my system, I’d hate to see what actually happens with a flaky one.
*shudder*
None of this stuff makes sense to implement under Mono. .Net 3.0 is just a branding for the .NET framework 2.0 along with a bunch of libraries for graphics, web services, and a couple of other things. Most of these are windows-specific technologies, built on Avalon and ASP.NET and some other things. Mono is not going to implement all this stuff and there are platform-dependent things on Linux to achieve similar goals, so as long as Mono’s framework is equivalent to C# 2.0 and CLR 2.0, Mono will be able to run the platform-independent parts of .Net 3.0. The rest are just libraries.
One target that the Mono folks probably will go after is the subset of WPF that is platform-independent (WPF/E). That would allow people to make web applications which have the snazzy graphics promised by WPF and still run on Linux and the Mac. Everyone wins.
IIRC, the original authors aren’t necesarily trying to go for 100% .NET compatibility, but bringing the important features accross, expose the GNOME services via a GNOME.net framework, and come up with a ‘.NET Similar’ framework which can compete with what Microsoft has to offer, but not necessarily 100% compatible.
The reality is, Mono will *NEVER* be 100% compatible, but the rationale is simple, if the transition from .NET to Mono is alot lower than the transition from Win32 to *NIX then the effort has been worth while – well, according to them anyhow.
As bright eyed as they are, I think they’re wasting valuable resources trying to implement a technology that’ll never be used to create large applications; application vendors will look at Win32, look at WinFX, and ask themselves, where is the benefit to moving a large application from Win32 to WinFX.
The transition from win16 to win32 took time, but people moved because there were some tangiable benefits like protected memory, pre-emptiveness, multi-user compatibility etc. But the benefits between moving from a unmanaged to a managed environment are going to be considerably less compelling.
C# and VB.NET aren’t bad languages, but I do think the risk is, is this; Novell getting too wrapped up in compatibility rather than simply concerntrating on making the best implementation that uses GNOME and .NET as the core. They also risk losing sight of the fact that Microsofts number one strength is their IDE; anyone who has ever used their IDE, especially when they need to rapidly put together a prototype or create a front end to be quickly deployed with in a few hours, will relise that is one of their strenghts.
Novell needs to meet that with an IDE that is feature for feature, better, cheaper, and smarter than what Microsoft has to offer; right now GLADE is a usability joke, and Sharpdevelop is nothing more than a glorified text editor; you need to have an IDE where you create a form, drop widgets, double click on the widgets, assign code, compile, test, and push out to the users.
Novell needs to meet that with an IDE that is feature for feature, better, cheaper, and smarter than what Microsoft has to offer; right now GLADE is a usability joke, and Sharpdevelop is nothing more than a glorified text editor; you need to have an IDE where you create a form, drop widgets, double click on the widgets, assign code, compile, test, and push out to the users.
Are you kidding? Who needs a bloated IDE? Real coders use vi
Anyway, speaking of IDEs, if VS.NET 2005 ships with .NET 2.0, do you just drop .NET 3.0 on top of it, or will they release a new version of VS?
VS2002 = .NET 1.0
VS2003 = .NET 1.1
VS2005 – .NET 2.0
Given this, I would assume that a new release of VS will be released to work with .NET 3.0.
From the blog, it would appear that the CLR and languages will be the same between .NET 2.0 and 3.0 – the only difference will be the addition of some new libraries. Because of this, I would expect that VS2005 should be able to support .NET 3.0 just fine. All you would have to do is install the .NET 3.0 SDK on a machine with VS2005 already installed, and the library references would likely be immediately available.
“it would appear that the CLR and languages will be the same between .NET 2.0 and 3.0 – the only difference will be the addition of some new libraries.”
Nope, this is not correct. There is plenty of new language features in .NET 3.0. Take for instance the whole LINQ thing with SQL queries as first cass language constructs etc.
Hi,
no this is part of C# 3.0, not .NET 3.0.
I already told the mono guys in #mono that I think, that they should stop implementing winforms and co and only implement the basics needed to write .NET apps on linux. As GUI framework they should use gtk# only, and they should write a new webframework instead of using asp.net. Because imho they will run always behind the current version of .NET.
But they were not happy about what I said and obviously they are pretty happy with the current situation and wanna implement a complete .NET implementation. But how do they wanna archieve to implement WPF and WCF? This is imho too windows specific. But ok, if they believe to make it work… I do not say anything against it
They already did great work.
And the IDE: MonoDevelop is already nice, but it is still not as professional as VS2005, or eclipse. But this can change in the future. Maybe we will have a C# plugin for Eclipse too in the future. Eclipse has a project at the summer of code 2006 for this plugin.
So: Keep up the good work mono!
Mike
Edited 2006-06-11 12:00
VS2002 = .NET 1.0
VS2003 = .NET 1.1
VS2005 – .NET 2.0
Given this, I would assume that a new release of VS will be released to work with .NET 3.0.
You can code against .NET 3.0 using VS 2005 (as many are doing so currently), however, you won’t get designer support (i.e., drag and drop controls) and other WinFX-specific UI to make development easier. A CTP of the WPF designer (codenamed Cider) is currently available for VS 2005, but it is being developed to be supported on VS “Orcas” which will come in the Vista timeframe and have designer support for not only WPF, but also WCF and others. In short, since the framework and CLR will still be version 2.0, you can target WinFX (nka .NET 3.0) with VS 2005, but there will be additional features in VS “Orcas” to make the development experience easier and more integrated with the IDE.
As far as I can tell, Orcas right now is just a bunch of addins to VS 2005 to support the WinFX (*ahem*.NET 3.0) libs. At least this is what you see on the MS downloads.
Right now there’s the VS extensions for WinFX, which adds WPF project support and (really good) intellisense support for writing XAML. And there’s Cider, which adds (currently mediocre but better than nothing) visual design support for XAML. There’s this really cool (alpha-quality) thing you can get in the VS 2005 SDK (freely available) that integrates IronPython into the IDE so that you can write python code with intellisense and execute python commands from within VS 2005.
I agree on the ide bit. MS definetly has it there and we need that on linux. Look at the new Delphi 2006 and all the components for that thing. You can push out an app in a few hours with that and VS2005. Try doing that flashy stuff with vi…ha, no way. To each his/her own but when it comes to fast deployment(like where I work)vi and all those othere editors just dont cut it. Python looks to be a great language, but there’s not a single ide that can match VS2005. And Im sorry, be it that damn thing is bloated as hell and runs worse as the project size increases, it has saved my ass from upper management on more than one occasion.
There is nothing stopping a good IDE from being developed using Python and GTK; the problem is, there is a large number of ‘old school programmers’ who think that ‘real programmers don’t use gui!” so for ever and a day, the *NIX world will play second fiddle to the ease of development and deployment which Mac and Windows have to offer.
Hence, when people here piss and moan about “Windows has lower TCO than Linux’ there is an obvious bloody reason for it.
There is nothing stopping a good IDE from being developed using Python and GTK; the problem is, there is a large number of ‘old school programmers’ who think that ‘real programmers don’t use gui!” so for ever and a day, the *NIX world will play second fiddle to the ease of development and deployment which Mac and Windows have to offer.
Hence, when people here piss and moan about “Windows has lower TCO than Linux’ there is an obvious bloody reason for it.
To be fair, the availability of decent IDEs on Unix has gotten better in recent years. You’ve got the Java IDEs, KDevelop, and quite a few lesser known but pretty good C++ IDEs based on WxWidgets. But yeah, I always laugh at the kiddies that think they’re old school by using emacs (good Lisp IDE) and Vi.
I just use Vi keybindings in regular IDEs.
To be fair, the availability of decent IDEs on Unix has gotten better in recent years. You’ve got the Java IDEs, KDevelop, and quite a few lesser known but pretty good C++ IDEs based on WxWidgets. But yeah, I always laugh at the kiddies that think they’re old school by using emacs (good Lisp IDE) and Vi.
Just before I reply, but eewwwww, emacs, please, that is the epicentre of bloat and complexity, give me vi anyday.
In regards to IDE’s on Linux, they’re still crap – the day when I can drag and drop widgets onto a form, and assign code as easily as I can with Visual Studio .NET, will be the day that Linux has caught up.
n regards to IDE’s on Linux, they’re still crap – the day when I can drag and drop widgets onto a form, and assign code as easily as I can with Visual Studio .NET, will be the day that Linux has caught up.
I wasn’t comparing the quality of VS.NET to something on Linux. What I was saying, is that compared to 1997 when I start coding on Linux at work – things have changed a lot.
I don’t really care about forms for my linux work, but glade does seem to work ok.
I didn’t notice this before I posted above… Python will at some point be really well supported in VS. There’s a VS Extension SDK sample which integrates IronPython into the VS syntax highlighting, autocompletion, and form-designer codegen features.
As bright eyed as they are, I think they’re wasting valuable resources trying to implement a technology that’ll never be used to create large applications; application vendors will look at Win32, look at WinFX, and ask themselves, where is the benefit to moving a large application from Win32 to WinFX.
Moving to WinFX from Win32 doesn’t have to be an all or nothing situation. Managed code can interoperate with unmanaged, so you can keep the Win32 code while using managed to ease the development of new features, new UI, etc., and take advantage of new platform features. For new development, there shouldn’t be any question about going with WinFX unless you plan to support downlevel OSes beyond XP.
Some of the benefits include doing less work to achieve better application security, better development model for rapid prototyping and seperation of development roles, less work to develop custom UIs and visualizations, new deployment scenarios (e.g., ClickOnce) and easier repurposing of code for different deployment scenarios (rich/smart client, web, devices), including some that may be too risky with unmanaged code. One last benefit that some people may not think about is performance. WinFX/.NET will be the only direct way to accomplish some tasks going forward, so you will pay a performance cost in accessing this functionality via unmanaged code. WinFX also has a performance advantage in remoting scenarios (i.e., Terminal Services/Remote Desktop) because in most cases you’re only sending visual tree transformations even for complex visuals. Almost forgot — you also get to support 64-bit systems natively with little to no work compared to doing so with unmanaged code.
Moving to WinFX from Win32 doesn’t have to be an all or nothing situation. Managed code can interoperate with unmanaged, so you can keep the Win32 code while using managed to ease the development of new features, new UI, etc., and take advantage of new platform features. For new development, there shouldn’t be any question about going with WinFX unless you plan to support downlevel OSes beyond XP.
But the reality is, how many will move? you’re ovbiously too young to remember, it it seemed to take several ice ages for companies to finally move their product from Win16 to Win32, and even by 2000, when Windows 2000 was released, there still were companies (Lotus being one example) of shipping win16 applications, or worse (in the case of Corel), shipping half baked win32 applications that assume a single user environment – hence the reason why Windows 2000 was scaled back from the ‘grand unifier of Win9x and Windows NT” to simply an upgrade to Windows NT.
Some of the benefits include doing less work to achieve better application security, better development model for rapid prototyping and seperation of development roles, less work to develop custom UIs and visualizations, new deployment scenarios (e.g., ClickOnce) and easier repurposing of code for different deployment scenarios (rich/smart client, web, devices), including some that may be too risky with unmanaged code. One last benefit that some people may not think about is performance. WinFX/.NET will be the only direct way to accomplish some tasks going forward, so you will pay a performance cost in accessing this functionality via unmanaged code. WinFX also has a performance advantage in remoting scenarios (i.e., Terminal Services/Remote Desktop) because in most cases you’re only sending visual tree transformations even for complex visuals. Almost forgot — you also get to support 64-bit systems natively with little to no work compared to doing so with unmanaged code.
I’m not debating the merits, I already *KNOW* the merits of moving, the question I have to ask, who is going to move? I don’t see any .NET based applications from Adobe on the horizon, nor do I see anything from Corel, Quicken, Symantec, McAfee, MYOB etc. etc.
All very nice to talk about the wonderful features of WinFX and .NET, but if there isn’t a sizeable chunk of people actually USING those new features, then the technology has been a wasted effort – what makes the issue worse, the vendor lock in of WinFX.
If they’re going to go managed code, why not simply use the Eclipse/SWT/Java foundation? I mean, if you’re going have to rewrite mountains of code, why not write it in a language and a framework that is multiplatform and allows flexibility in the future, if one wishes to make ones product available on alternative platforms.
I don’t see .NET being about big-name legacy ISVs, or at least not about their old big-name products. Adobe isn’t going to rewrite anything if they don’t have to. No one is going to reimplement their working stuff for no good reason. If MS expected any third parties to do that, we’d be looking at Office.NET right now.
.Net seems to be more about the internal developer who’s making line-of-business apps for corporations (including web sites, data collection and reporting tools, and general lame but necessary software). These are the folks who keep corporations locked into windows. Also, MS is trying to get new ISVs or new products building on this stuff. Or new extensions to old products.
So why not continue to use the status quo? for the extensions, it’ll require complicated wrappers and compromises, for new applications, it’ll be difficult to find quality programmers who understand .NET as the only ones who have really gone the VB.NET or C# way are simply VB Classic programmers.
If big names aren’t using, why should I as a developer use it? and people will ask, and just continue using win32, and the issue is made worse by the fact that even Microsoft hasn’t used .NET – why not a MSN Messenger that is based on .NET, and thus, provide an extra layer of security to the end user? how about a .NET version of WIndows Media Player and its codecs so that the same player can be deployed on a number of platforms.
What it seems to be is an issue of “here is a technology we developed, but we wouldn’t touch it with a forty foot pole!”.
If a Windows application was extensible, it was probably using COM to expose its interfaces. .NET plugs naturally into COM (in fact, it started as the COM+ or COM99 runtime).
I agree that some programs could go to .NET with no problems and be perfect poster children for .NET. Things like Messenger would be a definite plus, but, then again, that’s an old product whose codebase would need to be rewritten. The nature of Codecs and media playback make them bad to implement in .NET. The decoders and encoders use assembly in spots and probably require careful buffer management. Not the target app for .NET. .NET is great for gluing together these media parts though.
About the quality programmers: if you’re hiring a new person who’s a quality programmer, they should be able to adapt to .NET in a relatively short time. They’re going to have to learn your existing codebase anyway. If they have familiarity with Java or C++, C# is really easy to learn. The hard part is learning the huge (and expanding) framework libraries. So your breakdown is this: hire an experienced (ex VB) C# developer for projects that will likely only involve glueing together exisiting technologies (like databases and web services). Or hire a skilled (non-ex-VB) developer for a longer term and invest some time in letting them get up to speed on the framework. But you run into this training necessity on any project where you’re not doing something that has been done so often that it’s all but implemented for you in a canned framework.
As a developer, you should use .NET if the libraries look like they will simplify your work. If you’re programming against WPF, you’ve gotta use .NET since that’s the only interface. If you’re already good at Win32 and you’ve got a good framework built up to do what you want, why switch? I’m just an amateur myself, and I’ve written only a couple of toy win32 apps. It was nasty to do and I found that I could get the stuff working in .NET much faster. Isn’t that reason enough to switch?
it’ll be difficult to find quality programmers who understand .NET as the only ones who have really gone the VB.NET or C# way are simply VB Classic programmers.
I think you’re underestimating microsoft’s PR team. From what I’ve heard they seem to be doing a pretty good job convincing a lot of universities that familiarity with the .NET libs is fairly fundamental. OK, the quality part might be a bit of a stretch when we’re talking about recent grads. Especially recent grads whose coursework may have been geared a little too strongly to language than design. Still, money and influence can go a long way to being able to dictate trends.
When I was hopping through university, the status quo was “VB/Pascal for teaching programming fundamentals, and C++ for the serious stuff” – in all due respects, one does not use VB for a large scale application, and there has yet to be a product to be used as a test case as to the scalability of C#.
One can atleast say that with Java, we have complete IDE’s written using it, compilers written using it, whole webservers and application servers written in pure java.
The question is, when will we see the same in the C# world, because right now, Microsoft need to realise, the world doesn’t revolve around Windows, it revolves around UNIX, Linux, Windows, Mainframes etc. etc. C# and VB will remain niche players in the big market until Microsoft make a concerted effort to releasing the specifications in full, and allowing EVERYONE to implement it, royalty free, and without threat of legal action if patented technologies are implemented.
Edited 2006-06-11 10:46
One can atleast say that with Java, we have complete IDE’s written using it, compilers written using it, whole webservers and application servers written in pure java.
The question is, when will we see the same in the C# world, because right now
We already see the same in C# world. Mono’s compiler is written in C#. SharpDevelop is written in C#. The Mono web server is written in C#.
Microsoft need to realise, the world doesn’t revolve around Windows, it revolves around UNIX, Linux, Windows, Mainframes etc. etc. C# and VB will remain niche players in the big market until Microsoft make a concerted effort to releasing the specifications in full, and allowing EVERYONE to implement it, royalty free, and without threat of legal action if patented technologies are implemente
And in the real world, the client does revolve around Windows, proprietary Unix is basically dead, and IIS keeps on chipping away at Apache marketshare.
http://osnews.com/comment.php?news_id=14839
Dude, the bottom line is that win32 has been with us for a decade, companies are reluctant to throw out working code, and even Vista will have the win32 subystem.
But we’re not talking about a static timeline. Every copy of Vista will have .NET installed by default. And for Vista, it’ll be the opposite of what we have today. Today sometimes you have to pinvoke win32 in .NET to get some added functionality that .NET proper doesn’t expose. In Vista (from my understanding), it’ll actually be hard to not use managed code in order to get some functionality.
What it seems to be is an issue of “here is a technology we developed, but we wouldn’t touch it with a forty foot pole!”.
Nonsense. Major chunks of VS2005 are written in .NET. Unlike Sun, Microsoft understands code reuse.
Excuse me? and Sun doesn’t? Microsoft is the one that re-wrote a WHOLE operating system from scratch (Windows NT) when they could have easily worked on and extended their existing UNIX line, so don’t give me the bullshit that Microsoft knows about ‘good code reuse’.
Oh, and .NET is meant to be a competitor to Java, and like I said, if you wanted native access to resources, Java allows that; if you’re going to go to all that trouble using managed code, why not stick with Java, which has a proven track record.
Oh, and .NET is meant to be a competitor to Java, and like I said, if you wanted native access to resources, Java allows that; if you’re going to go to all that trouble using managed code, why not stick with Java, which has a proven track record.
Sun wants you to live in an alternative universe where native code doesn’t exist. JNI vs Pinvoke. Case closed.
If big names aren’t using, why should I as a developer use it? and people will ask, and just continue using win32, and the issue is made worse by the fact that even Microsoft hasn’t used .NET – why not a MSN Messenger that is based on .NET, and thus, provide an extra layer of security to the end user? how about a .NET version of WIndows Media Player and its codecs so that the same player can be deployed on a number of platforms. What it seems to be is an issue of “here is a technology we developed, but we wouldn’t touch it with a forty foot pole!”.
MS does use .NET. The whole of WinFX, including WinFS, is managed code. As mentioned by another poster, Visual Studio uses managed code. Expression Interactive Designer is a WinFX application.
Other Microsoft applications using managed code include (not a complete list):
Windows PowerShell
Microsoft Narrator (Vista)
SQL Server 2005
BizTalk Server
Windows Sharepoint Services
Sharepoint Portal Server
Content Management Server
Upcoming releases of server products like Exchange and MOM use managed code for admin via PowerShell.
XBOX 360 (managed support currently in development/part of XNA/games shown running on CLR).
Edited 2006-06-11 14:25
Oh pulease, Microscopic portions of code; wake me up when I see the whole list completely written in managed code – according to Microsoft, it should be just a compile away in respects to turning C++ into managed C++, and going by the hype, one should be able to compile it into bytecode, then decompile the bytecode back into C#.
But hey, Microsoft sounds honest, I’m sure they products are really crappily written, perish the thought of Microsoft promoting their products to do something that it does very poorly.
But the reality is, how many will move? you’re ovbiously too young to remember, it it seemed to take several ice ages for companies to finally move their product from Win16 to Win32, and even by 2000, when Windows 2000 was released, there still were companies (Lotus being one example) of shipping win16 applications, or worse (in the case of Corel), shipping half baked win32 applications that assume a single user environment – hence the reason why Windows 2000 was scaled back from the ‘grand unifier of Win9x and Windows NT” to simply an upgrade to Windows NT.
You’re mistaken in your assumption about my age. I’ve been using computers before the time of the PC. I have no doubts that there’ll be prenty of movement towards WinFX as development is just easier, deployment more flexible, and the entry cost is pretty low (rewrites aren’t necessary and are an extreme case, but if chosen, don’t have to be done in one release). There are ISVs building on WinFX already. Of course there will be businesses and ISVs that lag “behind”, but that’s the case in all transitions. There are still LOB apps running on DOS and ISV apps with 16-bit installers even though the app code is 32-bit. They are the exception rather than the rule for actively maintained code however. It all depends on the needs of the application (is the app actively maintained, is there competition, is there a better way to visualize the data in your app, what platforms do you target, etc.) and the drive of the developer.
I’m not debating the merits, I already *KNOW* the merits of moving, the question I have to ask, who is going to move? I don’t see any .NET based applications from Adobe on the horizon, nor do I see anything from Corel, Quicken, Symantec, McAfee, MYOB etc. etc. All very nice to talk about the wonderful features of WinFX and .NET, but if there isn’t a sizeable chunk of people actually USING those new features, then the technology has been a wasted effort –
Corel Grafigo 2 (and its predecessor) are written in C#. Symantec LiveState Recovery products, Recovery Disk, Norton Mail Security for Exchange, and possibly others, require the .NET Framework. Several products from McAfee subsidiary Foundstone were written in C# or require .NET. Intuit has several products that require .NET, including the QuickBooks line and companion products like Invoice Manager, Client Manager, and Customer Manager.
what makes the issue worse, the vendor lock in of WinFX.
There’s no more lockin with WinFX/.NET 3.0 than there is with Win32 or any other platform API.
If they’re going to go managed code, why not simply use the Eclipse/SWT/Java foundation? I mean, if you’re going have to rewrite mountains of code, why not write it in a language and a framework that is multiplatform and allows flexibility in the future, if one wishes to make ones product available on alternative platforms.
You don’t have to rewrite “mountains of code”. As said before, you can have it both ways. A complete rewrite, particularly of a large codebase, is an extreme case. It isn’t the norm and won’t be done in most cases, and almost never in one release cycle. .NET can interop with existing unmanaged code. If all you want is to build a new UI for you app, for example, you can just build the UI in managed code and keep everything else unmanaged.
If cross-platform dev is paramount, Java may be an alternative, but that isn’t an overriding issue for most ISVs or consumers as evidenced by Java’s failure on the client. You can also do cross-platform development with .NET. Mono, along with other libraries and frameworks give you this ability if needed and can be just as flexible if not moreso. However, it’s usually in the ISVs’ best interest to take advantage of platform features and integrate with other applications. Users have shown many times that they expect and prefer this. The easiest way to do this will be via .NET.
If they’re going to go managed code, why not simply use the Eclipse/SWT/Java foundation? I mean, if you’re going have to rewrite mountains of code, why not write it in a language and a framework that is multiplatform and allows flexibility in the future, if one wishes to make ones product available on alternative platforms.
Why do you have to ask why? Even Google isn’t writing much thick-client stuff for Linux. About the only people that care about crossplatform these days are the open source developers. And you can ask them why they don’t use much Java for the client.
I modded you up, but you got a couple things wrong…
As bright eyed as they are, I think they’re wasting valuable resources trying to implement a technology that’ll never be used to create large applications; application vendors will look at Win32, look at WinFX, and ask themselves, where is the benefit to moving a large application from Win32 to WinFX.
This defies all logic, and you’re not the first to say this nonsense. .NET is the future of 99% of Windows programming whether people like it or not. There’s just no way around that. It’s not like .NET is just another framework to do programming on Windows. It is the framework to do programming on Windows for the future. And it’s impossible for Mono not to be significant just because of the sheer amount of .NET programming that is being done now and more importantly in the future.
They also risk losing sight of the fact that Microsofts number one strength is their IDE; anyone who has ever used their IDE, especially when they need to rapidly put together a prototype or create a front end to be quickly deployed with in a few hours, will relise that is one of their strenghts.
Novell needs to meet that with an IDE that is feature for feature, better, cheaper, and smarter than what Microsoft has to offer; right now GLADE is a usability joke, and Sharpdevelop is nothing more than a glorified text editor; you need to have an IDE where you create a form, drop widgets, double click on the widgets, assign code, compile, test, and push out to the users.
Maybe you’re thinking of MonoDevelop, instead of SharpDevelop. SharpDevelop is a pretty advanced IDE with full winforms design support, multiple full-language support, and many other features. I’ve got it open right now writing some Boo code and it has full on-the-fly intellisense support, refactoring, forms designer support, etc..
Monodevelop is another story. It’s always been buggy for me. I’m not sure it’s exactly MonoDevelop’s fault – it has quite a few dependencies. But it’s not near as feature-complete as SharpDevelop and obviously nowhere near VS2005 (but few IDEs are).
I think Novell does have an Ximian guy working on MonoDevelop (at least part time), but you’re probably right in that Novell doesn’t (many Unix people don’t) understand the importance of a modern development environment.