We Keep Coding

Cannot connect to Azure ServiceBus with Microsoft.Azure.ServiceBus

I have created a very simple console application that connects to Azure ServiceBus and sends one message. I tried the latest library from Microsoft (Microsoft.Azure.ServiceBus) but no matter what I do I just get this error:
No connection could be made because the target machine actively
refused it ErrorCode: ConnectionRefused
I have tried exactly the same connection string in Service Bus Explorer and it does work just fine. Moreover I connected without problems using the older library from Microsoft (WindowsAzure.ServiceBus).
var sender = new MessageSender("endpoint", "topicName");
sender.SendAsync(new Message(Encoding.UTF8.GetBytes(JsonConvert.SerializeObject("test"))));
I tried with .NET Framework 4.6.2 and Core, same exception. I suspect there may be some differences in the default protocol that these libraries use, but I could not figure out that for sure.
P.S. Have tried the example from Microsoft docs but result is still the same exception

The old client supported ConnectivityMode using TCP, HTTP, HTTPS, and AutoDetect. ServiceBus Explorer is using AutoDetect, trying TCP first and then failing over to HTTPS, regardless of the TransportMode you were using (SBMP or AMQP).
With the new client this has changed. TransportMode now combines both options and offers Amqp (AMQP over TCP) or AmqpWebSockets (AMQP over WebSockets). There's no AutoDetect mode. You will have to create your clients and specify TransportType as AmqpWebSockets to bypass blocked TCP port 5671 and instead use port 443.

It seems that the documentation is lacking a lot on how to connect using HTTPS (Amqp over WebSockets) but after some help from Sean Feldman in the accepted answer I managed to connect. Here is the code that I used if someone is interested:
var tokenProvider = TokenProvider.CreateSharedAccessSignatureTokenProvider(
"RootManageSharedAccessKey", // SharedAccessKeyName
"SomeToken");
var sender = new MessageSender(
"sb://mydomain.servicebus.windows.net/",
"topicName",
tokenProvider,
TransportType.AmqpWebSockets);
Or a variant that let's you have the whole connection string in one piece
var builder = new ServiceBusConnectionStringBuilder("YouConnectionString");
var tokenProvider = TokenProvider.CreateSharedAccessSignatureTokenProvider(
builder.SasKeyName,
builder.SasKey);
var sender = new MessageSender(
builder.Endpoint,
"TopicName",
tokenProvider,
TransportType.AmqpWebSockets);
It is actually possible to use ConnectionString directly but then it has to be augmented to use the right protocol.
var sender = new MessageSender("TransportType=AmqpWebSockets;Endpoint=...", "TopicName")
Or the version that allows to embed EntityPath into the ConnectionString
var connectionBuilder = new ServiceBusConnectionStringBuilder("EntityPath=MyTopic;TransportType=AmqpWebSockets;Endpoint=...")
var sender = new MessageSender(connectionBuilder);

I was having the same issue but his worked for me
var clientOptions = new ServiceBusClientOptions();
clientOptions.TransportType = ServiceBusTransportType.AmqpWebSockets;
client = new ServiceBusClient(connectionString, clientOptions);
sender = client.CreateSender(topicName);
// create a batch
using ServiceBusMessageBatch messageBatch = await sender.CreateMessageBatchAsync();

Named pipe wrapper, usage over network

I have an working implementation of how two form applications and use named-pipe-wrapper v1.5.
Connection like this on server:
server = new NamedPipeServer<string>("named_pipe_test_server");
Connection like this on client:
client = new NamedPipeClient<string>("named_pipe_test_server");
now i have my server on another computer, same network.
how do i adress this.
I want to type like,
client = new NamedPipeClient<string>("//192.168.100.2//named_pipe_test_server");
is this possible ? in this case, what is the syntax ?

You can use the NamedPipeClientStream(String, String) overload to specify the name of the remote computer.
client = new NamedPipeClientStream("192.168.100.2", "named_pipe_test_server");

In named-pipe-server you can specify the server name as the second parameter to NamedPipeClient.
private readonly NamedPipeClient<string> _client
= new NamedPipeClient<string>(Constants.PIPE_NAME,"SPAN24");
You must use the Computer name not it's IP address.
You need to get the source from Github.
https://github.com/acdvorak/named-pipe-wrapper
The second parameter is not available in the Nuget package.

C# send email using implicit ssl

Is there any library preferable free that can be used in order to sens email using implicit ssl protocol. My hosting provider support ssl emails ... but standard .net email client cannot handle that.

Use the TLS port (ie 587) rather than the SSL port. I had the same issue for months until I found this solution.
Sending email in .NET through Gmail

System.Net.Mail does support "explicit SSL" (also known as "StartTLS" - usually on port 25 or 587), but not "implicit SSL" (aka "SMTPS" - usually on port 465).
As far as I know, explicit SSL starts from an unsecured connection, then the STARTTLS command is given and finally a SSL secured connection is made.
Implicit SSL, on the other side, requires that the SSL connection is set up before the two parties start talking.
Some servers (like gmail) accept both, so you simply need to set EnableSsl to true and send to the right port. If your server does not support explict SSL, though, this "simple way" is not an option.
I'm also still looking around for a general solution for using System.Net.Mail with implicit SSL, with no luck so far.
Anyway take a look at this article, it may give you some insight.
[edit: #Nikita is right, fixed port numbers to avoid confusion]

You may still be able to use the deprecated System.Web.Mail.MailMessage API (and set its "http://schemas.microsoft.com/cdo/configuration/smtpusessl" option, for explicit SSL/TLS):
System.Web.Mail.MailMessage mailMsg = new System.Web.Mail.MailMessage();
// ...
mailMsg.Fields.Add
("http://schemas.microsoft.com/cdo/configuration/smtpusessl",
true);
Alternatively, if you can, you could run something like stunnel locally to establish an SSL/TLS tunnel from your localhost to your SMTP server. Then, you would have to connect normally (without SSL/TLS) to the tunnel's localhost end as your SMTP server.

Try to check AIM (Aegis Implicit Mail) on https://sourceforge.net/p/netimplicitssl/wiki/Home/

As one of options, our SecureBlackbox includes SMTP component which works via both implicit and explicit SSL and supports different authentication mechanisms (including SASL, NTLM etc).

AspNetEmail supports Explicit SSL and Implicit ssl
http://www.advancedintellect.com/download.aspx

You can use AIM (Aegis Implicit Mail) to send email through implicit SSL:
First install the package: Install-Package AIM
Then Use the sample code to send email
class Mail
{
private static string mailAddress = "{you email address}";
private static string host = "{your host server}";
private static string userName = "{your user name}";
private static string password = "{your password}";
private static string userTo = "{to address}";
private static void SendEmail(string subject, string message)
{
//Generate Message
var mailMessage = new MimeMailMessage();
mailMessage.From = new MimeMailAddress(mailAddress);
mailMessage.To.Add(userTo);
mailMessage.Subject = subject;
mailMessage.Body = message;
//Create Smtp Client
var mailer = new MimeMailer(host, 465);
mailer.User = userName;
mailer.Password = password;
mailer.SslType = SslMode.Ssl;
mailer.AuthenticationMode = AuthenticationType.Base64;
//Set a delegate function for call back
mailer.SendCompleted += compEvent;
mailer.SendMailAsync(mailMessage);
}
//Call back function
private static void compEvent(object sender, AsyncCompletedEventArgs e)
{
if (e.UserState != null)
Console.Out.WriteLine(e.UserState.ToString());
Console.Out.WriteLine("is it canceled? " + e.Cancelled);
if (e.Error != null)
Console.Out.WriteLine("Error : " + e.Error.Message);
}
}

Sending email using Smtp.mail.microsoftonline.com

The context:
We’re a small company that does not have an Exchange Server (or anyone dedicated to it) yet we still need to have/send emails.
We’ve decided to use Microsoft Online Services (MOS)
The Objective:
We have a web server (Windows Server 2003 R2 with IIS 6.0) and have deployed a C# ASP.Net MCV application.
The web application needs to send emails each time a user creates an account.
According to the documentation we need to use port (587) and make sure Transport Layer Security (TLS) enable. In addition, the FROM address being used must be of type “Authoritative” which it is when I double check via the Microsoft Online Administration Center
The code:
The C# code I have should be trivial and is the following:
SmtpClient server = new SmtpClient("Smtp.mail.microsoftonline.com");
server.Port = 587;
server.EnableSsl = true;
server.Credentials = new System.Net.NetworkCredential("xxx#domain.com", "123abc");
server.UseDefaultCredentials = false;
MailMessage mail = new MailMessage();
mail.From = new MailAddress("xxx#domain.com");
mail.To.Add("johndoe#domain.com");
mail.Subject = "test subject";
mail.Body = "this is my message body";
mail.IsBodyHtml = true;
try
{
server.Send(mail);
}
catch (Exception ex)
{
throw ex;
}
The error:
I’ve created a simple winform application with the above code to test the sending of emails…
I’ve tested the winform application locally on my computer (Windows XP) and on the Server.
In both attempt, I keep receiving the following error message:
The SMTP server requires a secure connection or the client was not authenticated. The server response was: 5.7.1 Client was not authenticated.
After Googling for a while I still haven’t found the reason why…In addition, most of the answers I’ve found are making a reference to the Exchange Management Console which we don’t seem to have (or installed) hence why we are using Microsoft Online Services…
Questions:
1) As a paying customer of MOS, my initial understanding is that I shouldn’t have to install (or have) an Exchange Management Console on our server…in fact, this should be completely irrelevant in order to achieve my task.
2) I’ve also tried enabling TLS inside our IIS 6.0 but to no avail…
3) We are grasping at straws here because what we seem to do looks like something amazingly trivial…
4) Should we simply abandon the idea of using MOS’s SMTP server and use another one? Such as Gmail’s ? If so…then why bother paying a monthly fee for MOS?
If any one has any help/advice that can help me shed some light on this, that would be great!
Sincerely
Vince
WOW…I believe we’ve found the culprit!!!
By commenting this line of code:
//server.UseDefaultCredentials = false;
Everything started to work!
I’m now able to send emails inside and outside our domain…
What puzzles me the most is that, according to the documentation, the default value of this UseDefaultCredentials property is set to false
So…when I manually set it to false it doesn’t work but when I comment the line (which also set’s it to false because of its default value) it works!
If this is a known issue or if anyone has an answer for that, I’d be curious to know!

looking in Reflector on UseDefaultCredentials property, you can see that it also changes the trasnport.Credentials value, so when you called this property with a false value, it changed the transport credentials to null.
the problem is that you called this property after setting the credentials in the line before that,
it nullified the credentials.
so bottom line, you shouldn't set the credentials and call this property afterwise.

you can try this sample
private void Button1_Click(System.Object sender, System.EventArgs e)
{
try
{
MailMessage myMessage = new MailMessage();
SmtpClient myClient = new SmtpClient("yourserver");
myClient.Port = "587";
myClient.Host = "your server";
myClient.UseDefaultCredentials = false;
myClient.Credentials = new System.Net.NetworkCredential("username", "password");
myMessage.From = new MailAddress("sender");
myMessage.To.Add("recipient");
myMessage.Subject = "Subject email";
myMessage.Body = "body email";
myClient.EnableSsl = true;
myClient.Send(myMessage);
}
catch (Exepiton ex)
{
MessageBox.Show(ex.Message.ToString());
}
}
Bye

5.7.1 is not an authentication issue, but a relay issue. In order to prevent anyone from using your server (or account, as the case may be) the smtp server is configured to only allow mail to users outside your domain if it is comming from an authoritive address. Verify that the address you have listed here
mail.From = new MailAddress("xxx#domain.com");
is the same as the one you are authenticating as. Also, make sure that the domain of the address listed is in the authoritive domains list.

What worked for me was what the-dude suggested Send SMTP email using System.Net.Mail via Exchange Online (Office 365) , on changing the email "from" address to be the same as the login for the stmp address
AND
doing what Vince suggested at the end Sending email using Smtp.mail.microsoftonline.com for commenting out "smtpClient.UseDefaultCredentials = false;"

Be sure to double check that your username is correct. It is not necessarily the same as your from email address. For example the from address may be "no-reply#yourdomain.com" but the username could be "mail-svc#yourdomain.onmicrosoft.com" depending no your setup and integration with Azure Active Directory etc.

Why does Request["host"] == "dev.testhost.com:1234" whereas Request.Url.Host == "localhost"

Hi all, I seem to have found a discrepancy when testing ASP.NET applications locally on the built-in web server with Visual Studio 2008 (Cassini).
I've set up a host on my local machine associating dev.testhost.com with 127.0.0.1, since I have an application that needs to change its appearance depending on the host header used to call it.
However, when I request my test application using http://dev.testhost.com:1234/index.aspx, the value of Request.Url.Host is always "localhost". Whereas the value of Request.Headers["host"] is "dev.testhost.com:1234" (as I would expect them both to be).
I'm NOT concerned that the second value includes the port number, but I am mighty confused as to why the HOST NAMES are completely different! Does anyone know if this is a known issue, or by design? Or am I being an idiot?!
I'd rather use Request.Url.Host, since that avoids having to strip out the port number when testing... - Removed due to possibly causing confusion! - Sam

Request.Headers["host"] is the value received from the application that connects to the server, while the other value is the one the server gets when it tries to get the domain name.
The browser uses in the request the domain name entered because that is used in the case of virtual domains. The server reports the one set in the server preferences, or the first one it finds.
EDIT: Looking at the code of Cassini to see if it uses some particular settings, I noticed the following code:
public string RootUrl {
get {
if (_port != 80) {
return "http://localhost:" + _port + _virtualPath;
}
else {
return "http://localhost" + _virtualPath;
}
}
}
//
// Socket listening
//
public void Start() {
try {
_socket = CreateSocketBindAndListen(AddressFamily.InterNetwork, IPAddress.Loopback, _port);
}
catch {
_socket = CreateSocketBindAndListen(AddressFamily.InterNetworkV6, IPAddress.IPv6Loopback, _port);
}
// …
}
The explanation seems to be that Cassini makes explicit reference to localhost, and doesn't try to make a reverse DNS lookup. Differently, it would not use return "http://localhost" + _virtualPath;.

The Request.Headers["host"] is the host as specified in the http header from the browser. (e.g. this is what you'd see if you examined the traffic with Fiddler or HttpWatch)
However, ASP.NET loasds this (and other request info) into a System.Uri instance, which parses the request string into its constituent parts. In this case, "Host" refers to literally the host machine part of the original request (e.g. with the tcp port being in the Port) property.
This System.Uri class is a very useful helper class that takes all the pain out of splitting your request into it's parts, whereas the "Host:" (and for that matter the "GET") from the http header are just raw request data.
Although they both have the same name, they are not meant to be the same thing.

It's a matter of what the w3 specs say versus what the Microsoft Uri.Host property is supposed to contain. The naming does not imply an attempt by MS to provide identical functionality. The function that does include port numbers is Uri.Authority.
With the update you posted, you're still facing the same problem, just examining a different aspect of it. The Uri.Host property is not explicity or implicity stated to perform the same function as the headers that are defined in the w3 specs. In long form, here are some quotes from the Uri.Host MSDN page:
Uri.Host Property
Gets the host component of this instance.
Property Value
Type: System.String
A String that contains the host name. This is usually the DNS host name or IP address of the server.
There's no guarantee that this will match what is in the headers, just that it represents the host name in some form.