Microsoft says .NET Framework porting project is finished: If your API's not on the list, it's not getting in Microsoft's .NET Core 3.0 team is done with the project to port the venerable .NET Framework API to the open source platform. Program Manager Immo Landwerth made the announcement in the form of an issue on GitHub (where else?) and stated that the gang had reached the point where it reckoned that everything needed for "modern …
This is a ramble but... Remember the ,NET announcement stating .NET was the future after VS6 all those years back. Well, if you look at what they are really doing now, they're just adding in API's for modern tech to a VS6 "platform" (A.K.A not-so-lock-in-oriented)... jettisoning .NET and all but accepting the mistake it was.
I once failed to finish a MCSD (the old acronym... not new), looks like it as well failed to finish!
WTF?
It's been massively successful, is hugely popular (in conjunction with C# mainly), and is literally in no way being jettisoned. You may not like it personally, but you obviously either don't follow it or don't understand it.
It has been ported from a Windows-specific framework to a multi-platform framework using largely the same API surface and tooling. It continues. It lives on. It grows. Now on Linux and Mac as well. You're living in another world.
I think he means from back in the day when .Net originally came out it was effectively Microsoft's Java Runtime replacement after the lawsuit over their version. He's just saying it could have been written as cross platform from the start avoiding the rewrite although maybe they were worried about stepping on Java's litigious toes?
"...saying it could have been written as cross platform from the start avoiding the rewrite..."
Correct, you're not so young either ;-).
I think I've showed my age in knowing a time when .NET most certainly was not "massively successful" (that's laughable to think at one point). I just find it ironic that the very thing .NET set out to do, propietary lock-in, is now back to (or even further back) kindred of VS6 was.
Things change, but for how long will they remain changed....
I think I've showed my age in knowing a time when .NET most certainly was not "massively successful"
Well, yes. Obviously it wasn't successful when it was first introduced; people had to adopt it first. That's a meaningless observation.
the very thing .NET set out to do, propietary lock-in, is now back to (or even further back) kindred of VS6 was
I do not think that clause means what you think it means. Or, indeed, much of anything. "back to ... kindred of VS6 was"?
It seems like you're trying to claim that .NET was introduced to lock customers into Microsoft technology (well, yeah, like everything Microsoft was doing at the time); and that now it isn't, because of .NET Core (yes, Microsoft is shifting its business model to accommodate changes in the market); and that this is in some way relevant to ... Visual Studio 6? I have no idea where you're going with that last bit, under any plausible interpretation of your phrasing.
"is hugely popular"
I don't think that 7.5% on the TIOBE index counts as "huge"... (it's split between C-pound and VB.NET, around the same 3.7% or so for each).
In fact, it's anything *BUT* HUGE!!!
I'd say "pathetic" after 17+ years of MS hype and trying to SHOVE IT INTO OUR ORIFICES WITHOUT PERMISSION...
But maybe what YOU call huge is not quite the same as what _I_ call huge!
(*ahem* that was a subtle reference to penis size - muahahahaha!)
troll icon because obvious
[all in fun, after all!]
Ah Bob. Your hatred of everything Microsoft simply leads me to discard everything you say about them as bad-intentioned and automatically doubtful. Your arguments may be 100% correct sometimes, but you've ruined it for yourself by refusing to ever be balanced or fair.
As for the specifics, masses of stuff from Stack Overflow and others shows C# to be moving around amongst the top 5 places for preferred and most used languages. And C# means .Net in practical terms.
The boy who cried wolf was eventually ignored.
Agreed.
".Not" (what _I_ call it) started out in teh early 2000's with Microsoft "Passport" (the predecessor to "Microsoft Login" for Win-10-nic, one login to rule them all etc.) which was [during the '.dot bomb' era] supposed to take over and dominate ALL OTHER methods for logging into web sites, with MS as the tollbooth keeper, naturally.
This *FAILED*
But with it was a back-end API that was oriented towards IIS servers. This was extended into the object framework for C-POUND (what I call C#) which was intended to REPLACE JAVA because Sun saie "our language, Micro-shaft, and that means OUR RULES".
Some bright-bulb then "decided" (read: *FELT*, not thought, FELT, with emotions and bias and feelings-of-the-moment and anything BUT truth+facts+reason) that this "framework" should become MS's new "developer platform" around 2003-ish, which basically *RUINED* DevStudio for a while. It was integrated into VB, and it initially became *DIFFICULT* to avoid accidentally liking it in with your C++ applications. I researched just how many steps needed to make THAT happen, and the divorce was *FINAL*.
Since then I've avoided ".Not" as if it were *THE* *PLAGUE*, because for every bass-ackwards "object oriented" WRONG way of doing things, there's an API-centrick EFFICIENT *RIGHT* way of doing things, and I prefer THE RIGHT WAY to THE MICRO-SHAFT WAY. Right?
Anyway, this ".Not" Initiative was one of Ballmer's biggest COCK-UPS *EVAR*.
Still, a slow-clap for porting the framework to the open source version. Whee...
Icon for the *BIG* *FAIL* known as ".Not" aka ".Net".
Because continuing with a flawed, incomplete, or post-release compromised API is infinitely preferable to working with one that maintains 100% backwards compatibility whilst issuing fixes, patches and updated versions.
How are you getting on building everything with v1.0 of every tool and interface you use?
I'm not a developer so this is a genuine query. I have had issues with a number of sales focused software vendors who have insisted that I retain older versions of .net as 'our product isn't compatible with later versions' This may be because they have used unpublished interfaces or quirks in earlier versions which are resolved in later versions but have any of you out there come across this issue in reality.
It's been a major pain for me implementing OS upgrades and trying to maintain a secure infrastructure when the supplier of a key product wont support current versions of .net because "that would require re-devlopments which would not increase application functionality".
It may be laziness, too.
One of the products I contribute (extensively) to is a large .NET distributed application server which emulates various execution environments. It uses a very wide range of .NET APIs and features. It runs under anything from .NET Framework 3.5 to 4.7. We've never had a problem accommodating a .NET Framework upgrade, that I can recall.
(It doesn't run under Core because it requires WCF, among other things.)
... after Ms' forcible "de-supporting" of VB6 rendered some tens of billions of dollars of investment in software written in VB6 pretty much worthless.
(By "forcible" I mean that for a couple of years they omitted a library from their new OS releases which allowed VB6 programs to run on newer boxes, although they caved after people began copying that part, 'MSVCRT40' I think it was, to their newly purchased equipment.)
That measure was intended to compel everyone to buy a new set of programming tools.
Hopefully this is not a repeat performance. Then again, knowing Ms perhaps it foreshadows something similar.
That was doomed to failure anyway since people have been lugging about VB runtimes since Visual Basic came out.
I'm honestly not sure anyone noticed that the library was not included because nobody ever had the habit of it being included in the first place. I know that it was not until XP that I stopped worrying about having my VB runtime versions in a system folder.
Try working at a large company with apps fighting over bugs due to differing VB runtimes.
It was the very definition of DLL hell.
You have to sympathise with MS on this surely. Trying to be progressive.
Then you don't, when their dev tooling roadmap twists and turns on a sixpence so regularly.
Dotnet Core + C# is a beautiful combo. If you rage over those, then you aren't a developer or someone with enough knowledge to comment.
"apps fighting over bugs due to differing VB runtimes."
I pretty much gave up on VB after the switch to 3...
VB 1.0 was fun, had quirks, required some clever hacks, had it working pretty well
VB 2.0 broke most of those hacks, so I had to re-hack because it, too, was quirky
VB 3.0 as I recall had 32-bit-ness and was a worth while fix, but still too many things were broken from 1.0 and 2.0 [not as bad from 2 to 3 though]
After that I gave up on VB. *THEN* some bright-bulb decided ADO-ness and object-ness VB-style, followed by ".Not which appeared to be PATTERNED AFTER THAT HORRIBLE WAY OF DOING THINGS, combined with a bad interpretation of what makes a proper Java object.
VB was intened to be a really useful prototyping tool. People used it to create ACTUAL APPLICATIONS. Then "the plugins" were being sold for it, many (read: probably nearly all) of them *TRIVIAL* things that could be pounded out in a few hours by an experienced coder (read: me) that COULD find his own ass with a map, both hands, *OR* an electric ass finder (even one without GPS!).
but yeah - that invisible unfixable RUN-TIME that you HAD to ship with any VB application, that BROKE in newer versions of Windows, was *PATHETIC*.
On Windows, because it's almost necessary to ship binaries for install, I ALWAYS STATIC LINK EVERYTHING, from RUNTIME to MFC. *ALWAYS*.
On open source OS's, I just ship as source and build from source. You can always submit source packages (with dependencies configured) to package maintainers, and they'll probably do the rest.
"Dotnet Core + C# is a beautiful combo. If you rage over those, then you aren't a developer or someone with enough knowledge to comment.".
Sonny, I've been coding since before your *FATHER* was in diapers!!! Yes, I used PUNCH CARDS, and also these "mark sense" cards that you put pencil marks on like a Scantron test form. However the computer DID have integrated circuits, not vacuum tubes. It was a PDP-11/34, at my high school, running RT-11 and doing batch processing with the optical card reader. It was a brand new computer, right off of the line, back in 1977...
And as far as _I_ am concerned, programming in C-pound is like trying to push a cart with a horse (instead of the horse pulling it). If you don't understand what would happen, you never will. There's a nice saying that's very similar...
C-pound is BASS ACKWARDS, as is the entire CONCEPT of ".Not". The amount of back-end code required to support that *HIDEOUS* model of multiverse.universe.galaxy.star-system.planet.continent.nation.province.county.city.district.down-to-the-atom *HIERARCHICAL* *HELL* with its COLLECTIONS and ENUMERATORS and "My GOD, it's full of *CRAP*" everywhere you look... it's a wonder it even WORKS half the time! And THAT is being *KIND*.
If you have *EVER* coded for windows using the Win32 API, you'd know what I mean. If you have to ask what that is, then there is NO hope for you!
Well having cut my programming teeth back in 1966 - I also instinctively dislike the hierarchical mess that backs .net applications, or even the 'runtimes' for VB et al - but it seems these pale into insignificance compared with the massive meshwork of unseen often redundant, error prone and possibly malware seeded 'scriptware' that backs up current web application.
... Oh and horses don't pull carts, they 'draw' = push them. <g>
>Try working at a large company with apps fighting over bugs due to differing VB runtimes.<
That problem was the VB3 and VB4 runtimes, which is to say Win9x/Win 3.x The later problem which people are more like to remember was the problem with conflicting C runtimes around the time of Win2K, which caused problems with objects written in C for use in other programs (including for use in VB programs).
It was the problem with conflicting C runtimes (as exposed by VB and other programs), along with the decreasing cost of memory and disk space, which caused MS to rethink their shared DLL approach.
Has WPF gotten to the point where you can just slap together a simple utility like WinForms? I know you can make stuff prettier with WPF, and there are some database-driven scenarios it makes easier, but the Java-like amount of crap needed for simple stuff, like 14+ lines of code and/or XML just to change the color of a DataGrid cell made it painful for doing simple things. Basically, it was Enterprisey. But that was years ago.
As has been said, web forms had its uses - something for internal use could be rapidly created.
You can create e.g. tools for stress testing with easy to alter parameters that are more user friendly than just giving someone a bunch of scripts and instructions on how to edit those scripts
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
