Happy 15th Birthday .NET | Hacker News Reader

Happy 15th Birthday .NET

blogs.msdn.microsoft.com

265 pointsvyrotek100 comments

I've been using .NET professionally and for hobby projects since version 1.1.

While initially sceptical of this new MS platform, I was quickly sold on C# compared to Java: The language just seemed so much better. The base class library was easier to use. The tooling was rock solid. In many (but not all) ways it was just a better Java.

Since then, I must admit I think Microsoft has handled the platform really well. It has made the Java-platform seem quite literally stagnant. First class functions and lambdas first now? Really?

Clearly there's been ups and downs. There was times when Microsoft has seemed dormant and not paying attention to the needs and requests of its developers, happy to have conquered the market for in-house enterprise applications. Some APIs were thrown out as soon as they were delivered to market. There were times when I was about to throw it all out due to Microsoft's best option at the time seeming inferior to pretty much everything else out there (ASP.Net Webforms with AJAX being a particularly frustrating story).

But all in all, it seems they've managed to pull through, to react in time. They've gotten better at listening to the community. Now they've even open sourced it "all" and let us in, allowed us to participate and shape the future of .NET, if we want to.

Yes. I can list a bunch of imperfections which remain with us today (like the .NET Core launch and migration-strategy not being all that convincing), but I'll leave that for another time.

Today, on .NET's 15 birthday, I'll say that I'm happy I invested in .NET those 15 years ago. It's literally paid my house, and I've enjoyed working with it while it did.

Keep up the good work, Microsoft. There's a world of developers out there who appreciate what you do.

>I've been using .NET professionally and for hobby projects since version 1.1. While initially sceptical of this new MS platform, I was quickly sold on C# compared to Java

And I'm sure your early inclinations were then confirmed when they released 2.0 and their superb implementation of generics :)

I had been a longtime Perl hacker (it was a thing back then) and was still cutting my teeth on the cost/benefit tradeoffs of strongly-typed languages. I remember being quite frustrated in 1.x while attempting to write a data-access layer and having to use lots of casts to write reusable code.

It definitely took me longer than I'd like to admit to wrap my head around the usefulness of generics, but I certainly remember the "aha" moment I had when I realized how much cleaner they'd make my codebase.

In fact, I ended up completely dropping the code-generation tool I had written -- in Perl, of course :) -- to create the base classes which could work directly with our strongly-typed models.

> ASP.Net Webforms with AJAX being a particularly frustrating story

Very much agreed; I avoided using .NET for anything in any way web related until MVC came out. Working with those Microsoft black box server controls was just too much.

> like the .NET Core launch and migration-strategy not being all that convincing

I can forgive that, since it looks like their migration strategy with the upcoming .NET Standard 2.0 will be much more solid.

> I remember being quite frustrated in 1.x while attempting to write a data-access layer and having to use lots of casts to write reusable code.

Yeah, I hated the 1.x days, as well for the same reasons. I ended up using a template tool to generate strongly-typed collections to avoid all of the ugly casts every where.

Still, .Net 1.x was better than what I had available before, which was ASP & VBScript. Now that was a horrid environment.

Were you also using OCX for the ASP pages?

Nope, honestly dont recognize the OCX TLA. It was pretty much a CRUD app, written in webforms, with a few reports rendered as html/xls. It wouldnt pass as pretty by modern terms, but it was a beautifully cut gem circa 2003.

> There's a world of developers out there who appreciate what you do.

Couldn't agree more: https://dusted.codes/thank-you-microsoft-for-being-awesome

I've been working with Microsoft tech for over 20 years and I absolutely love their style so much more than any other tech company. I'm really glad that they exist and I want to see them succeed. When I try to imagine a world without Microsoft and .NET, I honestly start feeling queasy.

My one big complaint about .NET is that they didn't open source it sooner. Maybe then, Silverlight or something really tight like that would have won out over the shit-fest of JavaScript that we've had to deal with for the past decade. JavaScript is finally catching up though and at least Visual Studio is one of the best editors you can use for that too. (Really, with the right extensions installed, I think it is the best.)

I have a lot of complaints about Microsoft too, but I always complain about things I love. Take my wife, for instance... :)

I have to ask, which extensions do you use for your JavaScript development?

Web Essentials, EditorConfig, Fix File Encoding and Line Endings Unifier. Also, Node.js tools and Tools for Apache Cordova if you work with those.

The reason I think it's the best - I haven't seen better HTML/JS/CSS auto-complete in another IDE. It's also got one of the best Android emulators for working with Cordova/Ionic. WebStorm comes close, but I don't like that I had to setup each new JS library to get auto-complete for it. VSCode comes close, but doesn't support code folding on // #region comments and it can't deal with large files as well as the full VS.

My first Microsoft product was MS-DOS 3.3.

Borland had better language tooling, but they lost their way, and Microsoft got Anders in the process as well, so in a way I consider that Turbo Pascal spirit lives in .NET, to a certain extent. :)

What initially soured me on .NET was how Microsoft branded everything with the .NET moniker.

I'm still a little bit skeptical about Microsoft's cross-platform future with .NET. They are saying and doing the right things, but I have a hard time trusting them.

> What initially soured me on .NET was how Microsoft branded everything with the .NET moniker.

Well, they kind of went all in at the time, even planned to base the next Windows version on .NET.

Which on my opinion, failed mostly due to the tension between WinDev (C++) and DevTools (.NET), than anything else.

Projects like Singularity and Midori prove that if the willingness was there to actually cooperate, they would have managed it.

Now we have .NET Native/UWP, which is basically the original idea of .NET when it was still called COM+ Runtime and AOT compiled.

I used .NET for quite a few years, and was very happy with it. As much as people malign VB.NET, it provided the perfect path for me as an amateur-turned-professional developer - Access VBA -> VB.NET -> C#.

But over time I switched over to web development, and ASP.NET was just bad. The very nature of it - trying to replicate state with WebForms - was fine for intranets and internal tools, but an absolute disaster when working on a public web site. And it was a long time before ASP.NET MVC came along to try to tidy all of that up.

I remember discovering Nancy.fx (http://nancyfx.org), a perfect-looking, light-weight web framework. But I could never persuade anyone to use it - in my experience .NET shops lean heavily on using the accepted MS way of doing things unless you really, really don't have to. You could see that in the .NET community - open source, community-driven libraries just weren't a big thing. That frustration led me to trying out Node, and I never really looked back.

I miss working with C# a little, and sometimes wonder what the world would be like if MS had embraced open source earlier. Right now I'm writing TypeScript in Visual Studio Code - it isn't difficult to imagine that I could still be writing C# if MS had worked at creating a community around it, but alas, it never happened.

NancyFX is fantastic. I started using it a few years ago, after we switched off of IIS to the self-hosted OWIN web server stack for a couple of projects, and MVC was not (maybe still isn't?) supported there.

Wow 15 years already, I still remember learning how to code C# for the first time in .NET 1.1 days, it seems like a lifetime ago :).

Its also worth pointing out that Visual Studio is also having its 20th anv event and shipping Visual Studio 2017 RTM on the same date on March 7th and 8th.

Details:

Join Us: Visual Studio 2017 Launch Event and 20th Anniversary: https://blogs.msdn.microsoft.com/visualstudio/2017/02/09/vis...

1.5 decades. Very impressive achievement.

I am wondering though, and I will ask the question of all the .Net developers out there - Did Microsoft achieve their end goal of reducing "DLL Hell" via the .Net framework?

I didn't do a lot of development in this platform, but whenever I dabbled in it, I used to come across the same sort of issues - "Oh, you PC doesn't have the correct version of the .Net framework installed, I'll have to go and download version x from Microsoft". There were a lot of applications tied to a particular (older) version of .NET and I remember that installing older versions over newer ones used to cause issues on quite a few network systems.

Also, got really tired of finding nice 'little' apps on the ancient web which looked like useful utilities in a 200Kb file, only to find out after downloading that you needed to then download a 100MB+ behemoth framework version x just to run it.

I know in a lot of cases in made development life easier, but on the deployment and implementation side of things, I feel we still suffered the same "DLL Hell", though not to the same level.

> Did Microsoft achieve their end goal of reducing "DLL Hell" via the .Net framework?

Yes, because the dynamic linker has the concept of versions. So it will only link if the right libraries are present in the system.

In theory it is not possible to use the wrong version as it used to happen with DLLs and COM libraries.

In practice, it requires the developers to actually care to version their libraries so that this works.

Quite a few devs, just let the same version numbers as on the project template, or change them to mean whatever version is installed, thus getting back to the old behavior.

When using libraries from devs that actually bother to change the version numbers properly, the problem is sorted out.

edit: typo

I'd say it's a mostly solved problem, if only because everyone uses their own versions of assemblies. ClickOnce is solid (if you automate the fiddly bits). There's more upfront checks than with Java, but that's more of a trade-off than a positive or negative.

I've been shipping .Net desktop apps for about five years now, I've never had a complaint about installing the framework, it isn't an issue anymore.

Try C++/CLI :) Had that problem recently when I assumed .NET was installed, but it needed a separate C++ runtime for C++/CLI

I think I'll skip that :) One of the reasons I switched to C# was to move away from C++.

Shipping c++ redistributable libraries is a major PITA. I couldn't figure out how to bundle them with a clickonce or wix installer.

It's not just that; everything feels old and fragile when you mess with C++(/CLI); I was amazed I had to write a stupid post-build event just to copy the app.config to the build dir... why is the experience so different from when you use C#? When doing .NET stuff, it would be nice if those things would be the same.

I did this once at a previous job. Was able to bundle all of the installers (including C++ redistributable, driver updates, etc.) into a single installer that ran off a single click, first in a Setup & Deployment project and then ported to Wix. It wasn't fun, but once it worked it saved us a ton of headaches in the field.

I really need to figure out an easy way to bundle the C++ redist's with Wix myself, I've got a PowerShell module I've packaged up along with a MSM containing a vendor SDK it uses. Problem is, said SDK has native components so the VC++2015 runtime also needs to be installed.

I deploy this using Ansible anyway so I am able to just install the C++ runtime separately, but it's a huge pain when I want someone to be able to double click an MSI on their developer machine and have it not work.

That was basically my situation. My project was c# but a vendor exe packaged with it required c++ libs. Never figured out how to bundle it.

Most of the problems 'used to be' the case when .net was still young (like the first 2-5 years). I never see those problems anymore.

List of Microsoft tags among the top-100 tags on Stackoverflow:

  .net, c#, asp.net, sql-server, asp.net-mvc, excel, 
  vb.net, windows, vba, winforms, visual-studio, linq, 
  excel-vba, sql-server-2008, wcf, visual-studio-2010

http://stackoverflow.com/tags

Stackoverflow counters for the above tags over time:

http://apps.axibase.com/chartlab/c1acecc0/4/

I started using .NET in late 2001. I'd done a few years at startups that were using Java and doing all kinds of architecture astronautics involving JavaBeans and great big complicated ways to access config files while ignoring any really hard customer-facing problems. The tools sucked really hard, and I remember it was difficult to find an IDE that didn't simply crash when you fed it 50K lines of Java to debug. Browser plugins OMFG. Working in Java wasn't a whole lot of fun.

Anyway, I joined a new company, started using C#, and one sunny afternoon about three months into my first real project I remember thinking to myself, quite clearly, "Oh thank God, the nightmare is over."

I did some Android work a few years ago, and all the bad stuff came flooding back: The fallen towers of abstraction degenerated into a sea of flag bits. The hideously complicated build and packaging systems. I haven't written any C# in five years or so, so maybe it's just as horrible now (and I've glossed over bad things like DLL hell and the global compilation pre-caching nonsense), but I sure don't enjoy anything based on Java.

Android is worse than standard Java, because many of the APIs seem written by ex-C devs that started to code in Java just before Android got released.

The worst example is how the Renderscript bindings are generated.

I remember starting a project for a Telco in C# before .Net was officially released. It was riddled with issues, but it made it easy to use COM+ as a means to hot swap 'plugins' to the core of the application. This allowed us to distribute one application, and have a configuration dynamically load which modules a user would need based on their role. The web wasn't very capable 15+ years ago, and this allowed for a single base to be maintained and yet shared modules to cut down on repetitive coding. You could do this with COM+ already, but manually working with IQueryInterface over a simple reflections added more complexity than was worth it. And when you needed to, you could easily make calls to the Windows API, so you could still do code injection to get past the parts when the language didn't support yet. And DLL hell was no longer so prevalent. I was told somewhat recently that it's still running in some capacity, which I'm glad of, because I remember stressing over how irresponsible it was to use an untested language and platform for such a project.

Similar experience, my employer at the time, as MSCP had access to an early version of the framework, even before the first Beta versions started to appear on magazine CDs.

We were in the process of migrating our in-house stack (Apache/TCL) to J2EE, cancelled the project before it even started and decided to go .NET instead.

Back then, as Java fan I used to criticise .NET a lot as Java clone like many of us perceived it.

Now 15 years later I have more fun doing .NET projects than Java ones. :)

However I do enjoy both stacks more than any other alternative.

There's so much going on that it's almost making me hesistant about taking on the new strategies like .NET Core or where to go with user interfaces. For the long term, is it better to lock myself into UWP and Windows Store, or reap the benefits with Xamarin?

Much would be easier if UWP was open and DirectX accelerated on Windows and OpenGL accelerated on Linux or macOS, and uploading these apps on Windows _could_ be to Windows Store but wouldn't be so architecturally tied to it. I know there are ways to dodge their store even with UWP apps, but it feels like you're hacking their intented model and on thin ice for whatever will come or change in the future.

I never really liked platforms where application development is tied to distribution methods, especially not when .NET has it in its history to not be that (other than maybe a very slight nudge towards ClickOnce). I felt like a part of the .NET philosophy died with UWP.

I applaud Microsoft for where they have come and their latest developments are intriguing but I see many quite major annoyances remaining. I work almost full time with .NET though, simply because that's where my money is for now. But I'm not touching UWP either at work or at home. It's still also receiving a mixed response at best by developers, from what I've heard. It's like... "OK, so here's this limited UWP app compared to WPF on desktop, because we have to build it on an API with Windows Phone in mind which no one uses and then upload it to this single store out of our control, with the excellent company of scam apps tarnishing our trademark". I feel like this is Microsoft's unfortunate reality of where things stand which they should move from. "How do we best fix these concerns?"

> But why should a web application willingly be tied to a particular web application host?

Performance. ASP.NET wasn't originally tied to IIS - the grand version (back in 2001) was to allow any application to host a website too, that's all in the `System.Web.Hosting` code - along with Cassini for lighter workloads and "IIS Hostable Core" as an analog to today's IIS Express, but that fizzled out in the late-00s only to come back as part of the post-Node trend lately.

This all dates back to 10 years ago: IIS7 introduced a fully CLR-managed request lifecycle which was was aligned with ASP.NET's own lifecycle, so the reasoning goes you might as well let the two become one-and-the-same - there's no point running two separate request pipelines (the webserver's and your runtime framework's) when one will do.

...of course this was back in the day of the "fat" threaded webservers, like Apache and Netscape Server - and remember IIS took it further by adding a kernel-mode component: `HTTP.sys` to get an edge over usermode-only servers. So far I haven't seen any work on reinventing IIS for today's fast and light servers like nginx where all people want to do is serve Node.js applications.

Sorry, edited my post to try stay more focused and less all over the place so what you quote got lost. :) Interesting about Cassini etc, I never knew! I guess then the question rather becomes whether it's worth the performance benefits since lockins and added Windows licenses can be so off putting, but it's becoming at least less of a worry now that you can transition to ASP .NET Core.

There is the Kestrel server, which is used for ASP.NET Core AFAIK, it's multiplatform also, but it's recommended to use a reverse proxy as it isn't fully audited yet

Actually I think that UWP has brought .NET back to its roots, as .NET was originally born as COM+ Runtime.

Also I look forward for sandboxing everywhere, since micro-kernels only got lucky on embedded systems.

Electron + React or React-native is the way to go. You get cross platform out of the box, mobile as well, it is silly easy to work with, hard parts all abstracted (notifications, updating, installers), the biggest dev community on earth and an immense eco system.

The traditional desktop application is dead. In desktop land you have dusty tools, slow and outdated UI frameworks (as in MVVM or worse: UI-in-code) like GTK, XAML, ..., barely any community or components to re-use. Microsoft itself starts to make its products on these new platforms. Visual Studio Code, or Office fabric for instance. Many popular everyday apps that people use without knowing it are Electron based.

We're currently transferring a huge C#/WPF monster into React. The gains are ridiculous. React runs circles around XAML (less code, less boilerplate, faster) while Redux makes handling state simple. And it's a thing of beauty seeing it run everywhere, Windows, Linux, MacOs. Android and IOS as well with few adaptions (React-native) while thanks to Redux the heart of the app is 1:1 portable.

This approach doesn't solve the problem of Electron and NW.js apps being terrible for laptop battery life, but this appears to be something that typical end users aren't terribly concerned about.

On the bright side, React Native for Windows works quite well, and there's even a WPF version of it[1]. React native for macOS[2] worked decently when I tried it, too.

[1] https://github.com/ReactWindows/react-native-windows/tree/ma... [2] https://github.com/ptmt/react-native-macos

I've only brushed over React native for desktop. How was your impression of it, is it worth a try over Electron? How do you handle packaging, notifications, updating, installing?

I mostly agree with you and I'd like to take the leap, but Javascript. I've tried to love it, and Typescript is a big improvement that I use happily. But in the end I'm just always going to be way more productive (especially in large projects) with a modern statically typed language with functional features. That is, C#, Kotlin, maybe F# or Scala.

Really, you're right - for most consumer apps outside of games and graphics, the web stack is hard to beat. Between the devtools and inspectability of the view layer, the fast and interactive nature of development, and the sheer size of the community, there's nothing like it. So I really blame Apple/Google/Msft for neither updating their UI toolkits to keep pace with the web, nor shipping something Electron-like in combination with a CSS framework and nice bindings for Swift/Java/.NET that would allow for development on the respective platforms that really feels and performs native while leveraging web technology in the view layer.

Both of those approaches would have worked, and neither was chosen - so now we have this bizarre situation with no good choices on the desktop. I have high hopes for WebAssembly, and if that fizzles I guess I'll have to make peace with using a language I don't like. At least if I ever want to develop for the desktop again.

Exactly, i have no idea what happened, why all these frameworks were treated like that. XAML, Flex, and many others. Well Google tried to make a bridge with CEF (Chromium embedded framework) which had .net bindings but it was quite slow last time i tried. Not a real UI framework of course.

I come from a .net/C++/C# background, too, and i disliked Javascript strongly back then when it was still a rumor that WPF would go down. But it's in a very different shape today and i mean the language itself, not just the community aspect of it. I write code in it that i would struggle with in C#. Javascript being very close to its JSON backbone and having special operators to mutate variations of it, i miss that in C#. Or dead simple async, caching, networking, it all feels very close to the core. Now where they implement atomics and shared buffers, there are very few things i would miss.

The type system has also gotten better, especially with Facebooks Flow, which is very sound and can detect deeply nested cases.

> We're currently transferring a huge C#/WPF monster into React.

This is a big rewrite, I assume? Any lessons from the transition you'd care to share?

Yes, from scratch. Since it's been more than 2 years of work now it's hard to say there's a lesson to be learned other then, yes, the web is totally ripe. And perhaps that insisting to do things the way we were used to was problematic from the beginning. The web is very different, so are the tools. We are using Webpack + Babel + React + Redux and Node on the server, very happy about it.

I currently work as a Java Dev, but the first language I really learned to use was C#. I don't use it often anymore as I am on a Linux machine at home - though I did try running it with Mono some years ago.

C# remains a pleasant language to use, and feels like it is quite a few steps ahead of Java. I'd strongly recommend that people check it out if they haven't, if only to get a feel of where Java might be in a few years.

e.g: Local variable type inference. This is one of the "small" features that makes C# such a pleasure to use, and I am happy that it is proposed to be in a future JDK.

> I don't use it often anymore as I am on a Linux machine at home - though I did try running it with Mono some years ago.

I'm on Linux at home also, and am loving the combination of .NET Core and VS Code.

I recently coded up a quick ASP.NET Core Web API for a client, which needed to access a MySQL database and an existing SOAP service. I wrote it on Windows using VS 2017, but then out of curiosity I literally just git cloned it on Linux and ran "dotnet restore", "dotnet test" and "dotnet run".

The whole thing worked flawlessly on the first try. All unit tests and integration tests (connecting to real external services) passed, it ran just as quickly, and I was able to debug it in VS Code along with breakpoints, variable inspection etc.

It was never possible to use Mono that effortlessly. Everything required more work just to get running. With .NET Core, platform specificity is the exception, not the rule.

And VS Code is truly a pleasure to use; IMO it's just the right combination of features and performance with a strong plugin ecosystem, which has been missing from Linux.

I might just have to give that a try then, thank you!

Happy birthday .NET I have known you since the start. C# had me straightaway, I was so relieved to stop using C++ lol (just kidding, no I am serious). I remember the early developmentor crash courses we took, before embarking on an "enterprise corporate banking ecommerce platform". Talk about jumping into a new technology at the deep end. We hit all the issues, Dataset serialization across .NET Remoting, Reflection costs, assembly size issues, remembering to strong name the assembly sn -k, and the GAC. Oh and I will never forget the talk on how .NET Remoting WebServices and XML are the future, but at least we could fallback to TCP Binary when things got hairy performance wise!

15 years later its a hell of a platform now!

Happy birthday!

My only complaint back in the day, given Anders Hejlsberg experience, was that we only got NGEN and JIT, but not a full AOT compiler without requiring dependencies to be installed into the host system.

Well, at least .NET Native and xcopy install do finally exist.

I recall Joel Spolsky was worked up about this, too, and wrote an article with the memorable title Please, Sir, May I Have A Linker? Somehow we built a ton of apps and got along without the linker all these years, but it sure would have been nice to save the startup time and dealing with customer machines without the framework installed from the beginning.

I'm confused to what extent xcopy deployment works with .NET Native. The Getting Started article[1] makes the point that the native binaries are sitting there in ilc.out and that you should "Test your app thoroughly," but it does not describe the deployment mechanism there, and double-clicking on the .exe does not work. Are you xcopy deploying the appx file (which is not there in ilc.out)?

[1] https://msdn.microsoft.com/en-us/library/dn600165%28v=vs.110...

The idea with xcopy deployment, is that you still use the JIT compiler, but all required libraries, including the runtime, are packaged with the application.

So assuming you haven't forgotten any library, everything is loaded from there, not from GAC or somewhere else.

This only works for .NET Core.

Ok, I see you didn't mean .NET Native and xcopy deployment work together but both are options now. Thanks for clarifying. I see the UWP app build folder has all the DLLs copied now.

> I recall Joel Spolsky was worked up about this

Much to his credit, this classic post is still up:

https://www.joelonsoftware.com/2000/07/22/microsoft-goes-bon...

Now all the resumes that say '15 years of .NET experience' aren't necessarily lies

I remember my senior year professor talk about this newfangled language from Microsoft called 'C sharp' while we were doing some Visual Basic 6 work. Soon after graduating I had the opportunity to choose a platform for a new web project at my first full time job, and we chose .NET 1.1

Definitely one the best decisions I've ever made. Microsoft: Thank you for .NET.

I remember setting up 4 prototypes on 4 different platforms: sun jvm, adobe flash, dhtml and .net. The last won, mostly because ease of development and fast DirectDraw rendering of many datapoints. Never looked back, best decision in my career.

IMHO C# and .Net platform felt more approachable than the Java ecosystem. Unfortunately when I shifted to Linux I had to leave it all behind. However, it's refreshing to see the effort being put into .Net Core but way too much time has passed and I've invested so much into Python (and more recently Go) that I'm reluctant to switch back.

So congrats Microsoft for giving us this lovely alternative and thanks Jesse Liberty and CodeSmith!

I took a subject at university that included a C# component. It was 2002 so it must have been .NET 1.0. I liked it, it reminded me of Borland C++ for Windows, Delphi, and similar RAD tools that I had played around with. I remember being super confused by boxing at first!

It's really matured well. Great work, and Happy Birthday .NET!

It's grown to become a very pleasant platform and ecosystem to dev in.

It's fairly fuss free for the most part. Good job MS.

I remember back in those early days seeing job requirements that listed 10+ years .NET. Nice to see some people actually have that now.

Why did Microsoft never target any platforms outside of Windows with .NET? (serious question)

Old Microsoft only wanted to sell Windows. There was a guy called Steven Sinovsky who was apparently the main person behind that. When he left, MS went cross platform. See the recent HN thread about Satya Nadella.

Not happy at all! I love the old Visual Studio 6.0 IDE, the new devenv.exe is getting more slower after each version.

Go back to native,Microsoft!

They did.

"Getting Started with .NET Native" - https://msdn.microsoft.com/en-us/library/dn600165%28v=vs.110...

I think the parent comment meant Visual Studio is slowing down with each new release (they switched to WPF for developing it with VS 2010).

I got it, but given that VS is still way faster than any Java IDE I have to use on my hardware, specially Android Studio, I just made that snarky remark.

Also I doubt very much that we could have had Rosyln with VC 6.0 architecture, stuck in C++ and COM.

It's certainly slow at starting up, beyond that I haven't seen a problem.

I'm not sure native is the way forward but I agree that Visual Studio is starting to show its warts. The 2GB memory limit is starting to be a problem for more and more of us. On a long enough timeline I hope to see VS code replace Visual studio

Me too VS 6 and VB 6 were really awesome.

Microsoft was at the tipping point in 1999, then the dotNet thing happened and a lot of failures like dotNet based Shell/Explorer and WinFS for the failed Longhorn what turned into WinVista. Then the WinMobile 6.5 to 7 thing happened. The dotNet Framework seems to be legacy now - right? WinForms is legacy now. Silverlight is legacy. dotNet DirectX APIs are legacy. dotNetCore is the new thing, but in v1. UniversalApp based on C++ API seems to replace WinAPI - correct? Anyway WinAPI is still going strong, and almost all applications are WinAPI based.

Sometimes I would like to go back in time to 1998/99. But the good thing the WWW succeeded (and "The Microsoft Network" failed and original dotNet vision of software as a service got postponed by many years).

Visual Studio is on WPF, so you can forget it. WPF is an abandoned platform. It is a wonder they're still trying though, even their web-based IDE (VS-code) is faster.

Funny, just a few months ago WPF got a few updates in VS 2015, WPF blog was reactivated and BUILD had a few sessions on it.

I have been doing greenfield WPF applications for companies in the life sciences industry in the last three years, and they will not move away from it any time soon.

so time to open source the whole thing? what a nice birthday present that would be! :)

.Net is open source

Be nice if they could open source VB6 though, which hasn't had an update in 19 years.

I'm still using it, which makes me happy and sad at the same time.

That isn't .NET. :)

But yeah, I wish they'd open source VB6 too. There were some fond memories back there. I have some old programs I can't find components for online too, which are somewhere in the old VB6 install. There's play potential, even if I have no real practical need for it.

And it's hard to imagine that open sourcing VB6 would harm Microsoft's business in any way.

Just wanted to say that I too would love to mess about with the VB6 (and previous) code base. I can't see any commercial reasons that could prevent this. Only thing I can think of is that it might give VB6 another lease of life where they want to properly retire it.

Said it before and I'll say it again, I don't think there is anything out there now that was a productive as VB6 development. Rapid Application Development was the buzzword of the day, and it really stood up to the name.

Oh, that would be pretty neat if they would open source VB6 or any previous version. I wrote a bunch of that code (like the VBX interface for example) and it would be fun to see it again.

It would be awesome. I know of some clients that would pay decent money to keep their VB6 apps running, if we had the source I'd happily be able to provide that service. Some of the DCOM+ stuff I wrote back in the day is still used in production as it just works. And it works really well.

VB6 was awesome. Would be great if they could release it as open source.

RAD (rapid application development) of GUI applications was never easier and such a joy then with VB6. I remember I was very sad when they announced their vision for dotNet - it took them additional four years until dotNet was available in v1. In the meantime they lost all developers to HTML and PHP & co. Dreamweaver WYSIWYG was good enough.

Good point. I knew some people that moved to Delphi after VB5, which I always kicked myself for not doing. However, I look back at the apps I worked on and there was nothing there that that would look out of place today. Like any language, you can write messy code and design poor UI, but follow principles such as MVP, separate your data layer and such, it's still a good platform. Having said that, I'd not pick it for a new project today! I've fallen very hard for C#.

I don't really think VB6 has any chance at "another lease on life". It's missing way too many things that are a modern expectation today, and I think it's unlikely that open source contribution would build enough in to make it viable. (Especially if Microsoft didn't accept PRs, so there was no "official" open source project around updating it.)

But for people who have to support VB6 regardless of whether or not Microsoft open sources it, I'm sure it'd be pretty helpful.

We still have stuff out there that runs on COBOL, I have a feeling there will still be some life-dependent VB6 code out there somewhere in 2050.

I don't expect MS to ever open source it at this stage. For many years the biggest source of angst for those of us marooned in VB6 was the fear that our applications would no longer run in the 'next' version of windows and rewrites would be necessary. I don't think that fear is there any longer as each successive release has continued to support them. Now it's just slightly depressing to be working with a tool that was already due an update before the end of the last century.

I think Windows 10 still ships the VB runtime, but I'll go and check. Support I've come across it mainly down to third party components, be it some weird DLL or an ActiveX control that will not behave. A plain vanilla VB6 app that you might get as an ePos system or some internal CRUD tool should work 'just fine'.

Thinking about it, I am going to dig out my old VB6 VM image and have a play. Be interesting to see how many people out there would want support for VB6 apps today.

I heard about some reasons why open-sourcing software is a little difficult when MS open-sourced Windows LiveWriter as Open Live Writer. The reasoning is that a lot of the code/supporting tools that they use have non-permissive licenses and is also reused in other places which makes it an involved process to decouple it from the application. A good example is the Ribbon interface in OLW (which I think Scott Hanselman or someone got rewritten so that it could be open-sourced.).

Don't quote me on this though, because I wasn't a first party member of the conversations.

No, it's not. .net is more than .net core, and it's not 100% open, nor cross-platform.

The .Net Framework CANNOT be cross platform, it contains all of the Windows specific parts. The whole point of the .Net Core initiative is to pull out the OS agnostic parts and to rewrite other parts to be cross platform (e.g. A GDI-free System.Drawing[0]).

The long term plan from what I've read is for .Net Core to eventually form the foundation of the .Net Framework, then the Framework (Windows/GDI+/COM+/etc) libraries with be built on top with other OS-specific libraries being created for other platforms.

The vast majority of the .Net framework is already Open Source[1] including the compiler[2]. What in particular are you missing that you need?

[0] https://blogs.msdn.microsoft.com/dotnet/2017/01/19/net-core-...

[1] https://github.com/Microsoft/referencesource

[2] https://github.com/dotnet/roslyn

I don't really care if it can or cannot be. I just said it's not, at this time. Nobody knows what will happen in 20 or 50 years. As simple as that.

As simple as what? The vast majority of .Net is open source along with the compiler.

sorry i was just making a little joke. my bad. i like .NET in the grand scheme of things.

Was .NET part of the anti-competitive ploy to run Java into the ground ?

Cheers.

I believe you're thinking of J++.

.NET is actually a continuation of J++, which was Microsoft's Java implementation plus their extensions, like delegates, which were also introduced in .NET

To be honest, I don't think the engineers had any ploy to "run Java into the ground", even though the sale folks probably thought about it. They did do their usual "embrace, extend" thing. And it was sort of anti-competitive, but then again the JCP isn't a real standards body given the TCK has to be licensed from Sun/Oracle with whatever conditions they feel like, which is why Apache Harmony didn't survive.

And so I have no interest in defending the moves of Sun wanting to defend what was at that point a completely proprietary and non-standard platform.

Kind of.

"COM+ Runtime"

https://blogs.msdn.microsoft.com/dsyme/2012/07/05/more-c-net...

Microsoft embraced Java at first. There was a moment in which there was a Microsoft JVM.

But Sun Microsystems did not like how Microsoft was engaging Java, so they had a legal battle from 1997 to 2001.

Microsoft licensed some patents from Sun, and diverted its effort into .NET.

C# 1.0 was very much like Java, but over time it evolved into a completely different language focused on market demands.

2.0 which introduced generics (and the partial keyword. code behinds yeesh) was when it REALLY took off.

Then lambdas and async and pattern matching, oh my!

That was J++, .NET was the implementation of COM+ Runtime ideas, which now have gotten back to the roots with .NET Native/UWP and its COM architecture.

"COM+ Runtime"

https://blogs.msdn.microsoft.com/dsyme/2012/07/05/more-c-net...

There was also J#, though it wasn't really anticompetitive. Maybe it was just the opposite, now that I think about it. Microsoft obviously felt that .NET, C#, and the CLR were viable competitors to Java and the JVM, and offered J# as a sort of on-ramp from the Java cowpath to the .NET expressway.

That's not meant as a knock against the Java world now; I just remember .NET being a pleasant place to be back in those days.

J# was only seen as a way to port Java into C#.

I doubt anyone gave it any other use, in fact it was a .NET 1.x language only.

Reply on news.ycombinator.com