4 ms·

I've recently been working with a C# app that's based on a nearly out of support .net 3.X version I think. It's fully inherited from a tech partner, but we have

I've recently been working with a C# app that's based on a nearly out of support .net 3.X version I think. It's fully inherited from a tech partner, but we have free reign to modify it as needed. I was excited to try and port it from a Windows only older .net app to .net core 6, but unfortunately too much of it doesn't have a simple to port to equivalent in .NET 6 and it would require us to completely rewrite it. This is all because it's a SOAP client, so I'm happy to forgive Microsoft for not spending too much time there. We don't have any control over that part either. It's the only thing in our entire infrastructure that runs on Windows and costs multiples of just about anything else we've got running, because of the Windows license. Huge bummer. We did get it streaming our data into BigQuery though, so that was cool to see work so well even on an older code base. I think at this point my last real major gripe with .NET is Visual Studio. I've used it on and off over the years, but every time I get back into it, it's just so much mental overhead to try and understand how the hell things are organized. It's like jumping into an ice bath coming from JetBrains/VS Code land. Just really unpleasant, but I don't think I'll be able to get away from it with this older C# code base. Somewhat unrelated. I really wish Microsoft would improve the install/packaging story for their C++ build tools on Windows. Trying to guide your IT department on how to install specific compiler versions to get TensorFlow/PyTorch and more importantly other less popular Python packages that require you to build from scratch on Windows has been a nightmare for so long. It's one of the things I mostly singularly dread dealing with. I really wish we could just enable the dev/compiler tool chain support without requiring admin credentials and have it be fully automated instead of trawling around the nightmarish Microsoft downloads site.

ivraatiems 4y ago
> I think at this point my last real major gripe with .NET is Visual Studio. I don't understand - what's stopping you from using JetBrains Rider? I use it and I work on some pretty ancient .NET projects from time to time.
- sylens 4y ago
  Not everybody's company is going to pay for a license if they already are licensing Visual Studio for everyone. As an individual, I only have a little bit of time to tinker with personal projects, and while I like C#/.NET so far, I'm not yet at the point where I feel comfortable paying for Rider's subscription. So I'm also mostly using VS2022 Community and VS Code (on macOS) so far. Hoping to eventually get to a point where paying for Rider becomes a no brainer.
pathartl 4y ago
There's always Rider which works very well for .NET stuff. For older applications, I would consider Mono or WINE if you really want to run it on Linux. We are experiencing the same scenario where we have an application that was built on .NET 4 over 10 years ago and there's a couple of packages we rely on that will not work on .NET 5/6. We have a rebuild planned, but it will be a large overhaul.
hnra 4y ago
SOAP as in WCF? If so then there is now a WCF port out now: https://github.com/CoreWCF/CoreWCF https://github.com/CoreWCF/CoreWCF
- int_19h 4y ago
  More likely, SOAP as in ASP.NET (old one), which has been around since .NET 1.0. Few people remember these days, but the reason why .NET is called .NET is because it was pitched as "all about web services" back when XML and SOAP was the new hotness.
mook 4y ago
> I really wish Microsoft would improve the install/packaging story for their C++ build tools on Windows. Not sure if this is what you mean, but vs_installer.exe supports command line arguments like --add, so you should be able to craft a giant command line for IT to copy. Used it for work for the NodeJS equivalent of your use case.
- jasomill 4y ago
  You can avoid the giant command line by providing a configuration file exported from a “known good” install: From the installer GUI on a machine with the correct set of components installed, click the “More ▼” button, then choose “Export Configuration” and follow the resulting prompts. Alternatively, the installer’s “export” command-line operation does the same thing. To use the resulting config file, either supply its path using the “--config” option to the installer’s “install” and “modify” command-line operations, or apply it from the GUI by clicking “More ▼” and choosing “Import Configuration”. This is also handy in non-IT deployments to quickly replicate an existing VS install on a new machine. Incidentally, even if you are going to go with the “giant command line” approach, the export mechanism is an easy way to figure out a valid set of component IDs to supply on said command line, though it doesn’t necessarily generate the smallest set of component IDs able to produce a given configuration, due to the presence of workload IDs and the fact that component dependencies are automatically installed, even if unspecified.

ivraatiems 4y ago

> I think at this point my last real major gripe with .NET is Visual Studio. I don't understand - what's stopping you from using JetBrains Rider? I use it and I work on some pretty ancient .NET projects from time to time.

sylens 4y ago
Not everybody's company is going to pay for a license if they already are licensing Visual Studio for everyone. As an individual, I only have a little bit of time to tinker with personal projects, and while I like C#/.NET so far, I'm not yet at the point where I feel comfortable paying for Rider's subscription. So I'm also mostly using VS2022 Community and VS Code (on macOS) so far. Hoping to eventually get to a point where paying for Rider becomes a no brainer.

pathartl 4y ago

There's always Rider which works very well for .NET stuff. For older applications, I would consider Mono or WINE if you really want to run it on Linux. We are experiencing the same scenario where we have an application that was built on .NET 4 over 10 years ago and there's a couple of packages we rely on that will not work on .NET 5/6. We have a rebuild planned, but it will be a large overhaul.

hnra 4y ago

SOAP as in WCF? If so then there is now a WCF port out now: https://github.com/CoreWCF/CoreWCF https://github.com/CoreWCF/CoreWCF

int_19h 4y ago
More likely, SOAP as in ASP.NET (old one), which has been around since .NET 1.0. Few people remember these days, but the reason why .NET is called .NET is because it was pitched as "all about web services" back when XML and SOAP was the new hotness.

mook 4y ago

> I really wish Microsoft would improve the install/packaging story for their C++ build tools on Windows. Not sure if this is what you mean, but vs_installer.exe supports command line arguments like --add, so you should be able to craft a giant command line for IT to copy. Used it for work for the NodeJS equivalent of your use case.

jasomill 4y ago
You can avoid the giant command line by providing a configuration file exported from a “known good” install: From the installer GUI on a machine with the correct set of components installed, click the “More ▼” button, then choose “Export Configuration” and follow the resulting prompts. Alternatively, the installer’s “export” command-line operation does the same thing. To use the resulting config file, either supply its path using the “--config” option to the installer’s “install” and “modify” command-line operations, or apply it from the GUI by clicking “More ▼” and choosing “Import Configuration”. This is also handy in non-IT deployments to quickly replicate an existing VS install on a new machine. Incidentally, even if you are going to go with the “giant command line” approach, the export mechanism is an easy way to figure out a valid set of component IDs to supply on said command line, though it doesn’t necessarily generate the smallest set of component IDs able to produce a given configuration, due to the presence of workload IDs and the fact that component dependencies are automatically installed, even if unspecified.