3 ms·

While I'm happy to hear this on one level, as it likely means that .NET Core is finally going to be approaching some levels of stability that allow it to be use

While I'm happy to hear this on one level, as it likely means that .NET Core is finally going to be approaching some levels of stability that allow it to be used in earnest for production usage, I'm somewhat dismayed. There's still a lot of things missing from it that the 4.X full framework version had, and this feels like it is the door slamming shut on hopes that existing code could be seamlessly upgraded without a lot of rework. Time will tell how many existing libraries are fully ported to Core. For the foreseeable future, I expect that I'll still have to be working with the legacy framework, as there are so many SDKs that I require to interface with different products that will never receive the investment to bring them in line.

mumblemumble 7y ago
FWIW, the decisions on what not to port that I'm aware of seem to make sense. WCF, for example: Its a legacy technology that is also horribly complex and never really took off. It was never really a good solution if you wanted cross-platform RPC, and therefore has a userbase that doesn't overlap much with the people they're trying to attract with .NET Core. If you're trying to migrate to .NET Core in order to go cross-platform, you probably want to be migrating off of WCF, anyway. And if that's not true of you. then .NET Framework 4.8 probably still suits your needs, anyway.
- WorldMaker 7y ago
  Worse than that, too, was that WCF tried to be an "all worlds" solution, so it was an okay-not-great RPC toolkit, and an okay-not-great REST API toolkit, and an okay-not-great IPC toolkit, (and it tried to be a terrible P2P communications toolkit for several years), and so forth. Replacing WCF won't be easy in a lot of cases not so much because there's a lot of WCF-specific code, but simply figuring out where on the flowchart of possible concerns to migrate to: Were you using WCF for RPC? Try gRPC, unless you really need SOAP support or worse WS-* support (I'm sorry) and then, uh, good luck. (Though SOAP libraries for .NET Core do exist and turn up in search results, depending of course how far down the WS-* rabbit hole you need to go.) Were you using WCF for REST API? Try ASP.NET directly now instead of indirectly. Need client tools support? Take a look at Swagger (now aka OpenAPI) to replace WCF's odd extensions to SOAP's WSDL for REST APIs. Or maybe look into GraphQL (or less commonly Falcor) if you want something really new and wild. (Were you using WCF for P2P communications? That hasn't been officially supported since Vista and whoops.) WCF was actually pretty well built for exactly this sort of migration (the focus on interface-first design, data contracts, etc; in some cases it's just writing interface implementations where there were none before), and even the most WCF heavy applications were far more about fiddly giant bits of config files than actual code specific to supporting WCF. I really do think that half the challenge in migrating away from WCF has more to do with figuring out which tool (or tools, given you might have been using WCF for multiple things) to migrate to, as much as any actual code migration.

mumblemumble 7y ago

FWIW, the decisions on what not to port that I'm aware of seem to make sense. WCF, for example: Its a legacy technology that is also horribly complex and never really took off. It was never really a good solution if you wanted cross-platform RPC, and therefore has a userbase that doesn't overlap much with the people they're trying to attract with .NET Core. If you're trying to migrate to .NET Core in order to go cross-platform, you probably want to be migrating off of WCF, anyway. And if that's not true of you. then .NET Framework 4.8 probably still suits your needs, anyway.

WorldMaker 7y ago
Worse than that, too, was that WCF tried to be an "all worlds" solution, so it was an okay-not-great RPC toolkit, and an okay-not-great REST API toolkit, and an okay-not-great IPC toolkit, (and it tried to be a terrible P2P communications toolkit for several years), and so forth. Replacing WCF won't be easy in a lot of cases not so much because there's a lot of WCF-specific code, but simply figuring out where on the flowchart of possible concerns to migrate to: Were you using WCF for RPC? Try gRPC, unless you really need SOAP support or worse WS-* support (I'm sorry) and then, uh, good luck. (Though SOAP libraries for .NET Core do exist and turn up in search results, depending of course how far down the WS-* rabbit hole you need to go.) Were you using WCF for REST API? Try ASP.NET directly now instead of indirectly. Need client tools support? Take a look at Swagger (now aka OpenAPI) to replace WCF's odd extensions to SOAP's WSDL for REST APIs. Or maybe look into GraphQL (or less commonly Falcor) if you want something really new and wild. (Were you using WCF for P2P communications? That hasn't been officially supported since Vista and whoops.) WCF was actually pretty well built for exactly this sort of migration (the focus on interface-first design, data contracts, etc; in some cases it's just writing interface implementations where there were none before), and even the most WCF heavy applications were far more about fiddly giant bits of config files than actual code specific to supporting WCF. I really do think that half the challenge in migrating away from WCF has more to do with figuring out which tool (or tools, given you might have been using WCF for multiple things) to migrate to, as much as any actual code migration.