Hacker News Reader

Comment by xeromal | Hacker News Reader

Tangentially related but I was impressed with .NET recently. I was recently tasked with tackling an extremely old and proprietary video format that embedded GPS, video, audio, and several other components. The files were huge and just a mess to understand and I eventually found an old player application that was also proprietary.

I decompiled it into C# and stripped the player aspect out of it leaving the code the peeled back the container and allowed me to export MP4 and other pieces. After getting to build into a console application on windows on .net 4 I think I decided to give it a go to upgrade it enough to compile AND run on linux. I upgraded 2x and then updated around 10-15 lines of code that no longer compiled. It was extremely easy considering there were 1000s of lines of code to parse this format. I finally got it running on linux and it only took about a day of full effort. Pretty crazy considering the code I was running was over 10 years old.

View on HN

Backwards compatibility is something they take really seriously in the enterprise world, but something thrown out the window in the rest of the industry.

I would argue that C#/.NET goes just far enough but not too far with backwards compatibility. As seen in the anecdote, manual changes were required. Java, for example, is more likely to 'just work' but I prefer the language designers' approach to C# and making the occasional breaking change to keep the language in good shape. I really appreciate their good taste.

The .Net ecosystem has a lot of great tooling, for sure.

The main issue I have had is if you are trying to get into the .Net Ecosystem without spending money. There are quite good free tools, but you have to figure out what works best for you if you're used to the non-free ones.

I assume instead of Reflector for the decompilation, you used DotPeek?

I've used ILSpy instead of JetBrain's tools for this.

If you're a real OG, you used `ildasm`.

I learned this from Jeffry Ritcher (https://www.amazon.com/CLR-via-C-Developer-Reference-ebook/d...)

A lot of what I know about C# is from his books. I wish every language had someone of his caliber write a book about it.

I think the version of the book I read was "CLR via c#" about 10 years ago

dnSpy was the best

> The main issue I have had is if you are trying to get into the .Net Ecosystem without spending money.

I suggest not trying to do this.

You can certainly make most of .NET8 work with a pure OSS toolchain, but your overall development experience is going to be destitute compared to that of the official tool chain. To be clear - I think paid alternatives, such as Rider are fantastic too, but even so I've had some trouble at the edges with paid 3rd party (Blazor apps, UWP, etc).

At the end of the day, you have to ask yourself about what your hourly rate is. If you are going to spend a 20 hour premium per week bandaging up a "free" .NET toolchain, whereas the official, $100/m stack costs you 1-2 hours, which one actually costs you more? What are your principles worth in terms of your free time?

What would you say is the current best in class toolchain for .NET (assuming I'm running on a ARM Mac)?

Jetbrains’ Rider by a very long shot

Vscode stuff is ok too if you dislike big and featureful ides, but it’s behind rider. dotnet cli to run commands is sufficient until you have very strange builds.

Keep in mind the language has many ways to do the same thing, so rider helps you doing the “modern” things. The base class library is also very vast. Take your time, C# is great but it has a ton of features.

What is the issue with using Visual Studio Community Edition? Or if not on Windows, using VS Code with the plugin. All free.

Wasn’t there some issue with debugger on Non-Windows platforms?

The issue that it is free as in beer but not open source as in MIT.

I think you mean open source as in GPL, given that MIT doesn't force to give the source code, hence why it is beloved for commercial products.

Visual Studio for Mac is discontinued and will be retired next year:

https://learn.microsoft.com/en-us/visualstudio/mac/what-happ...

Right. They rewrote the .NET plugin for VSCode as a replacement. It's reasonable.

Well, the C# DevKit has to fix quite some bugs. I love it but it needs more work.

Rider is absolutely great, give it a try. I have used and continue to use professionally macOS + VS Code/Omnisharp combo and it has been working nicely with Rider serving as an escape hatch for more complicated debugging scenarios, profiling or when you need to step through (possibly decompiled) 3rd party code.

>At the end of the day, you have to ask yourself about what your hourly rate is.

At the end of the day it's a question of how much ROI are you getting. Your hourly rate is irrelevant, when you're just learning a new tech... because when you're hacking/learning the hourly rate is $0.

If you spend 20 hours fixing something that wouldn't occur with the paid toolchain, at what price does it become worth it to skip those 20 hours when they're not directly applicable to what you're trying to accomplish?

When you literally don't have $20 in your account. Then you can spend 100 hours and it's still worth it.

Also, in big corporations, getting approval for spending $20 is as hard as getting approval for $200 or $2000.

Which is why FOSS software took off in big companies, because it's easier for developers to sample things out and then ask for forgiveness instead of asking for permission.

Also, hobbies. It doesn't even matter if you have $20 to spend, or not. Hobbies depending on paid tools are risky.

People underestimate the importance of free tools because they judge from the perspective of their overinflated consultancy rates.

Then again, this sort of decisionmaking is probably why you're a software developer with less than $20 in your bank account.

I don't know... Possibly because your life circumstances made it that?

But hey! Talented people doing their best to break out of poverty is clearly a novel idea to you.

Just because you're not getting paid doesn't mean your time is worthless (or your hourly rate changes).

That's where ROI comes in.

Should I have spent my full income for 3 months on an IDE, vs spending an extra 2 hours with the free tools?

It's not a hypothetical, that was the reality of my life in 2004. I had a lot of extra time, couldn't use it to make money and buying "enterprise grade" tooling wouldn't produce any extra value.

The ROI of an professional grade tool would have been - "you get to sleep extra two hours and have no food for 3 months"

> At the end of the day, you have to ask yourself about what your hourly rate is. If you are going to spend a 20 hour premium per week bandaging up a "free" .NET toolchain, whereas the official, $100/m stack costs you 1-2 hours, which one actually costs you more?

Also the official stack is supposedly supported, which means you can contact Microsoft if you have an issue.

In practice, you get some underpaid outsourced employee in the chat, who is just going to follow their script - so it is more effective to go to Visual Studio feedback or Github, depending on the issue.

I teach for a living, mostly people of poor backgrounds, and a lot of them in the Third World. I understand your argument (and I buy some tools myself), but I can't tell them to use paid tools because the cost may be too high in the local currency and it adds up fast.

VS Code and Omnisharp are unconditionally free (and open source). DevKit and VS Community Edition are free for education scenarios. The arguments made in previous comments don’t correspond to reality.

Thank you!! Good to know.

I use JustDecompile. It's free, last I checked, and it works great.

I used dotPeek. Made quick work of it!

Microsoft has lot of issues but when it comes to Backward compatibility, no one comes close to them. Solid.

Windows is good at it. .NET is not bad, but also not particularly good — compared to the Java side, at least.

The compatibility shims that come implicit with .NET are incredible. In my experience many of the .NET Framework libraries work right out of the box on .NET (Core), even on Linux.

.net core has been able to run .net framework assemblies since around the 3.x days.

not everything is supported so not all assemblies will work, but large parts of the standard library are supported so it's most seemless.

Reply on news.ycombinator.com