[Bug]: NetNamedPipeBinding doesn't work with longer addresses which used to work in Net48

[dhankapo-BH]

Duplicate ?

• I have searched issues/discussions and did not find other issues/discussions reporting this bug.

Product version

1.4.0-preview1

Describe expected behavior

NetNamedPipeBinding doesn't work with longer addresses which used to work in Net48.

If the address is "net.pipe://localhost/7545/00000000-0000-0000-0000-000000000000/00000000-0000-0000-0000-000000000000/CheckTest1/CheckTest2/CheckTest3/CheckTest4/CheckTest5/CheckTest6/IContract1".

The corewcf service starts without any errors, but when any client tries to connect to this service, an exception is raised on the client side saying no endpoint found.

Ideally the service ,

1. Should listen on endpoints with longer addresses.
2. Should not say that it is listening on those endpoints when it is not.
3. Service should throw exceptions if address validation is failing due length check.
4. Client should throw proper exceptions that why the endpoint was not found.

Describe actual behavior

NetNamedPipeBinding doesn't work with longer addresses which used to work in Net48.

If the address is "net.pipe://localhost/7545/00000000-0000-0000-0000-000000000000/00000000-0000-0000-0000-000000000000/CheckTest1/CheckTest2/CheckTest3/CheckTest4/CheckTest5/CheckTest6/IContract1".

The corewcf service starts without any errors, but when any client tries to connect to this service, an exception is raised on the client side saying no endpoint found.

Which binding

NetNamedPipe

security

None

Which .NET version

.NET 6

Which os platform

Windows

Code snippet used to reproduce the issue

net.pipe://localhost/7545/00000000-0000-0000-0000-000000000000/00000000-0000-0000-0000-000000000000/CheckTest1/CheckTest2/CheckTest3/CheckTest4/CheckTest5/CheckTest6/IContract1

Stacktrace if any

Endpoint not found

[mconnew]

This is a bug in the code here: https://github.com/CoreWCF/CoreWCF/blame/main/src/CoreWCF.NetNamedPipe/src/CoreWCF/Channels/PipeHelpers.cs#L106

You can work around this by using the (currently incorrect) AppContext switch of Switch.System.ServiceModel.UseSha1InMsmqEncryptionAlgorithm and set it to true. There are two bugs here, one is the switch name is wrong, the other is the algorithms are the wrong way around, it's using SHA1 by default instead of SHA2. So setting the app context switch to say to use SHA1, it will actually use SHA2 and will work.

The code needs to be replaced with this. I'll get this fixed in the next release:

        internal const string UseSha1InPipeConnectionGetHashAlgorithmString = "Switch.System.ServiceModel.UseSha1InPipeConnectionGetHashAlgorithm";
        internal static bool s_useSha1InPipeConnectionGetHashAlgorithm = AppContext.TryGetSwitch(UseSha1InPipeConnectionGetHashAlgorithmString, out bool enabled) && enabled;

        private static HashAlgorithm GetHashAlgorithm()
        {
            if (s_useSha1InPipeConnectionGetHashAlgorithm)
            {
                return SHA1.Create();
            }
            else
            {
                return SHA256.Create();
            }
        }