4 ms·
If the author reads HN comments - findings like these are probably better to be submitted at https://github.com/CoreWCF/CoreWCF https://github.com/CoreWCF/CoreW
by neonsunset 1y ago
If the author reads HN comments - findings like these are probably better to be submitted at https://github.com/CoreWCF/CoreWCF https://github.com/CoreWCF/CoreWCF instead
(although I have no idea how active CoreWCF owners are w.r.t this)
- shagie 1y ago... and https://github.com/CoreWCF/CoreWCF/discussions https://github.com/CoreWCF/CoreWCF/discussions
- eterm 1y agoThanks. In my experience the CoreWCF team are fairly active, but I didn't want to bother them until I can understand if this is a problem with CoreWCF. This might also be a problem WCF client, which is maintained by others elsewhere in a different repo: https://github.com/dotnet/wcf https://github.com/dotnet/wcf for the nuget package version. But this might just be how WCF is designed. I'll try a version of this within .NET Framework, but even that might change depending on whether it's via IIS or started via ASP.NET Core, and whether it uses the built in System.ServiceModel or the nuget version. ( You can probably tell I'm a bit frustrated with MS for making a bit of a mess in the way they hurried away from .NET Framework especially with respect to WCF. )
- neonsunset 1y ago> Thanks. In my experience the CoreWCF team are fairly active, but I didn't want to bother them until I can understand if this is a problem with CoreWCF. It may not be necessarily a problem but, ideally, the less users have to care about gotchas and knowing how to exactly use the API the better. There are some constraints to this but chances are at least documentation can be improved. Plus, especially if there are not that many issues, it signals interest and active usage.