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 have a lot of complaints about Microsoft too, but I always complain about things I love. Take my wife, for instance... :)
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. :)
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.
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.
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.
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.
Couldn't agree more: https://dusted.codes/thank-you-microsoft-for-being-awesome
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.
Well, they kind of went all in at the time, even planned to base the next Windows version on .NET.
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.
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.
Join Us: Visual Studio 2017 Launch Event and 20th Anniversary: https://blogs.msdn.microsoft.com/visualstudio/2017/02/09/vis...
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.
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.
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.
.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
Stackoverflow counters for the above tags over time:
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.
The worst example is how the Renderscript bindings are generated.
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.
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?"
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.
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.
On the bright side, React Native for Windows works quite well, and there's even a WPF version of it. React native for macOS worked decently when I tried it, too.
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.
The type system has also gotten better, especially with Facebooks Flow, which is very sound and can detect deeply nested cases.
This is a big rewrite, I assume? Any lessons from the transition you'd care to share?
Also I look forward for sandboxing everywhere, since micro-kernels only got lucky on embedded systems.
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'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.
15 years later its a hell of a platform now!
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'm confused to what extent xcopy deployment works with .NET Native. The Getting Started article 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)?
Much to his credit, this classic post is still up:
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.
Definitely one the best decisions I've ever made. Microsoft: Thank you for .NET.
So congrats Microsoft for giving us this lovely alternative and thanks Jesse Liberty and CodeSmith!
It's really matured well. Great work, and Happy Birthday .NET!
It's fairly fuss free for the most part. Good job MS.
Go back to native,Microsoft!
"Getting Started with .NET Native" - https://msdn.microsoft.com/en-us/library/dn600165%28v=vs.110...
Also I doubt very much that we could have had Rosyln with VC 6.0 architecture, stuck in C++ and COM.
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).
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.
I'm still using it, which makes me happy and sad at the same time.
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.
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.
Don't quote me on this though, because I wasn't a first party member of the conversations.
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.
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.
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.
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 including the compiler. What in particular are you missing that you need?
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.
I doubt anyone gave it any other use, in fact it was a .NET 1.x language only.
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.
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.