ASP.Net Core 1.0 compatibility

[davidetaddeucci]

Any news about the release of Sendgrid C# API libraries compatible with ASP.Net 5.0 (or ASP.Net Core 1.0)?
Just added the reference to the last version of this library on my ASP.Net Core 1.0 using NuGet manager project but there's an error in the dependencies saying that SendGrid API is not compatible with DNX 5.0.

[saluce65]

See issue #146.

[0xdeafcafe]

I wrote a small library for covering a limited usage of the v2 mail send endpoint as we needed coverage at my company. It supports DotNet Core, if you want to use it, it's over here. It would be nice if SendGrid supported DotNet Core on the v3beta branch however.

[davidetaddeucci]

Dear Alex,

thanks a lot for your support.

Unfortunatelt in these days I have opted for an other massive mailing service provider, SparkPost; but I would try also your interesting solution.

Best regards from Tuscany.

Davide

Da: Alex Forbes-Reed [mailto:[email protected]]
Inviato: giovedì 19 maggio 2016 15:26
A: sendgrid/sendgrid-csharp [email protected]
Cc: davidetaddeucci [email protected]; Author [email protected]
Oggetto: Re: [sendgrid/sendgrid-csharp] ASP.Net Core 1.0 compatibility (#221)

I wrote a small library for covering a limited usage of the v2 mail send endpoint as we needed coverage at my company. It supports DotNet Core, if you want to use it, it's over here https://github.com/0xdeafcafe/sendgrid-dotnet . It would be nice if SendGrid supported DotNet Core on the v3beta branch however.

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub #221 (comment) https://github.com/notifications/beacon/AGRiDHXp7EAPr3r7ewuORYi5vGKOERREks5qDGThgaJpZM4Ib1fA.gif

[thinkingserious]

@davidetaddeucci this is definitely on our roadmap, see: sendgrid/csharp-http-client#1

@0xdeafcafe Awesome! Highest of Fives

I'm going to leave this ticket open to make sure we support .NET Core on the v3beta branch too.

Thanks everyone for your support!

[RyanONeill1970]

Can we have a list of action points and get these agreed by the project owners? I can then sign a CLA and work on some bits.

From what I understand, the SendGrid project that handles the API v3 calls only has 3 points that need addressing to turn it into a Portable Class Library that can be used by the different .Net variants.

The Mail project (in the same solution) however has that huge dependency on System.Net.Mail (which will be ported, but they only seem to have started it just a few days back, see https://github.com/dotnet/corefx/issues/1006 ). I suggest splitting the projects so that the API can go fully PCL and be used by .Net core.

If the project owners think this is OK and can split the solution then I can list the points required to convert the API to a PCL based class.

It would mean effectively stopping working on the older Mail project until .Net core catches up with a new implementation of System.Net.Mail.

[thinkingserious]

@RyanONeill1970,

Thank you for the feedback!

So far we have two pull requests that are attempting a solution: https://github.com/sendgrid/csharp-http-client/pulls. Have you checked those out? If so, what do you think?

[RyanONeill1970]

I was talking about the API3 beta3 branch at https://github.com/sendgrid/sendgrid-csharp/tree/v3beta , the branch you pointed to is a lower level one I think (not so strongly typed). However, those pull requests look good. They'll need to be re-done though as I'm sure you are aware, a new beta came out last week which overlapped them. Looks like you have plenty of help anyway, I'll stand back and watch. Thanks

[thinkingserious]

Yes, the pull requests refer to the HTTP client that the v3beta version of
this library depends upon. I'm thinking if we get it right there, making
the necessary changes in this project should be straight forward.

Thanks for your support!

http://www.sendgrid.com
Elmer Thomas
Developer Experience Engineer | Product

On Mon, May 23, 2016 at 9:03 AM, RyanONeill1970 [email protected]
wrote:

I was talking about the API3 beta3 branch at
https://github.com/sendgrid/sendgrid-csharp/tree/v3beta , the branch you
pointed to is a lower level one I think (not so strongly typed).
However, those pull requests look good.

They'll need to be re-done though as I'm sure you are aware, a new beta
came out last week which overlapped them.

Looks like you have plenty of help anyway, I'll stand back and watch.

Thanks

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#221 (comment)

[cleftheris]

Hi all any updates?

[thinkingserious]

@cleftheris

Thanks for checking in!

We have one signed CLA from @PaitoAnderson, but I was hoping to get one for this pull request from @Gekctek also: sendgrid/csharp-http-client#2 so that we could compare notes and possibly merge solutions.

That said, we just took this library out of beta yesterday (along with our 6 others) and we will likely be spending a few weeks ironing out bugs before we come back to enhancements such as this one.

[bdparrish]

@thinkingserious

I am following this update closely. Is there any update for this, so that it can be used with Azure Developer Services?

[yellowsix]

For anyone who just needs the basic functionality of sending email via the SendGrid API from a .NET Core application, it's actually pretty easy to use the REST API directly. The C# API in this library was definitely written by someone who is not a .NET developer... it is very disorienting to use with the weird dynamic type stuff and lack of typical naming for async methods and the such. To actually send an email you only need a few lines of code:

    // you can/should reuse the http client instance for multiple requests, 
    // then Dispose when done with it. I recommend making a singleton class
    // with this client as a member, and registering it in Startup.cs of your ASP.NET Core app, 
    // just as an example
    var client = new HttpClient();
    client.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Bearer", "your api key");
    client.BaseAddress = new Uri("https://api.sendgrid.com/v3/");

    // sending JSON to the API is as easy as a single line of code:
    var response = await client.PostAsync("mail/send", new StringContent(json, Encoding.UTF8, "application/json"));

And to get the json string to send, you can make a little object model on the REST API here:
https://sendgrid.com/docs/API_Reference/Web_API_v3/Mail/index.html

For example, 5 minutes of coding gets you this:

        public class SendGridMessage
        {
            public const string TYPE_TEXT = "text";
            public const string TYPE_HTML = "text/html";

            public List<SendGridPersonalization> personalizations { get; set; }
            public SendGridEmail from { get; set; }
            public List<SendGridContent> content { get; set; }

            public SendGridMessage() { }

            public SendGridMessage(SendGridEmail to, string subject, SendGridEmail from, string message, string type = TYPE_HTML)
            {
                personalizations = new List<SendGridPersonalization> { new SendGridPersonalization { to = new List<SendGridEmail> { to }, subject = subject } };
                this.from = from;
                content = new List<SendGridContent> { new SendGridContent(type, message) };
            }
        }

        public class SendGridPersonalization
        {
            public List<SendGridEmail> to { get; set; }
            public string subject { get; set; }
        }

        public class SendGridEmail
        {
            public string email { get; set; }
            public string name { get; set; }

            public SendGridEmail() { }

            public SendGridEmail(string email, string name = null)
            {
                this.email = email;
                this.name = name;
            }
        }

        public class SendGridContent
        {
            public string type { get; set; }
            public string value { get; set; }

            public SendGridContent() { }

            public SendGridContent(string type, string content)
            {
                this.type = type;
                value = content;
            }
        }

Then you can use JSON.NET to serialize your object as a string:

        public async Task SendEmailAsync(string to, string subject, string fromAddress, string fromName, string message)
        {
            var msg = new SendGridMessage(new SendGridEmail(to), subject, new SendGridEmail(fromAddress, fromName), message);
            try
            {
                string json = JsonConvert.SerializeObject(msg);
                var response = await _httpClient.PostAsync("mail/send", new StringContent(json, Encoding.UTF8, "application/json"));

                // this is just a rough example of handling errors
                if (!response.IsSuccessStatusCode)
                {
                    // see if we can read the response for more information, then log the error
                    string errorJson = await response.Content.ReadAsStringAsync();
                    throw new Exception($"SendGrid indicated failure, code: {response.StatusCode}, reason: {errorJson}");
                }

            }
            catch (Exception ex)
            {
                // example using a fictional object "_logger" that can log exceptions for you
                await _logger.LogExceptionAsync(ex);
            }
        }

In this example, the HttpClient created above is stored as _httpClient in a class that I have for sending emails. Included is some rough example of logging errors, but not failing on an email that can't be sent. Change as appropriate for your situation.

Hopefully that will help some people who don't want to include this library just to send some simple emails from a .NET Core application.

[thinkingserious]

Thank you for the contribution @yellowsix!

[thinkingserious]

@yellowsix if you would like some SendGrid swag, please email us at [email protected] with your mailing address and T-shirt size. Thanks again!

[0xdeafcafe]

@thinkingserious can I get some new SendGrid swag? ;)

[thinkingserious]

@0xdeafcafe of course you can! Just email us with your mailing address and T-shirt size.

[edrohler]

@thinkingserious Are you looking for help from the community on this library? From what it sounds like a wrapper needs to be built for the http calls in v3.

[thinkingserious]

@edrohler,

You are correct. While we will do what we can to make the improvements internally, any help from the community is appreciated and encouraged.

There are many improvements identified (see our issues and pull requests for a start) for the next iteration of this library, including wrappers executed in the form of helpers.

If you are interested, I'm happy to dig deeper with you.

[edrohler]

@thinkingserious I would be happy to help. I use this library for a couple of projects and would like to see it progress.

[thinkingserious]

Thanks @edrohler!

As a first step, could you please submit a signed CLA? https://github.com/sendgrid/sendgrid-csharp/blob/master/CONTRIBUTING.md#cla

Thanks!

[Bartmax]

I just want to add another way of using sendgrid for sending emails only purpose.

You can use MailKit which already supports ASP.NET Core and use SMTP settings as described here:
https://sendgrid.com/docs/Classroom/Basics/Email_Infrastructure/recommended_smtp_settings.html

var message = new MimeMessage();
message.From.Add(new MailboxAddress("John Doe", fromEmail));
message.ReplyTo.Add(new MailboxAddress("John Doe", fromEmail));
message.To.Add(new MailboxAddress("Bart Calixto", toEmail));
message.Subject ="mail subject";

var msg = "mail message";
message.Body = new TextPart("plain") { Text = msg };
using (var client = new SmtpClient())
{
    await client.ConnectAsync("smtp.sendgrid.net", 587, SecureSocketOptions.Auto);
    await client.AuthenticateAsync("user", "pass");
    await client.SendAsync(message);
    await client.DisconnectAsync(true);
}

[clairernovotny]

Ping? What's the status here? It also seems like the use of dynamic on the client makes this API very "undiscoverable". If you're looking for an easy REST wrapper, I would recommend looking at https://github.com/paulcbetts/refit, as it fits the bill very cleanly.

Simply define your POCO types and define an interface that is decorated with the API methods and it does the rest. Much more discoverable that way.

[thinkingserious]

Hi @onovotny,

Thanks for the up vote, you have helped this issue rise in our queue.

If the world stood still, it looks like we would get this done in a few weeks. This project can increase in the queue with additional +1's.

Do you mind opening a new ticket regarding adding POCO types?

[clairernovotny]

@thinkingserious it looks like #246 has all of the POCO's in it, or is it missing some?

[thinkingserious]

@onovotny,

Awesome, that one needed some love. I give your +1 to that ticket in our backlog to help it move up the queue and pinged the author to get that CLA on file.

Thanks!

[clairernovotny]

@thinkingserious curious about your CI process? Not sure why #246 failed, but I noticed you're using xbuild on travis with Mono?

I hate to say it but, xbuild is rarely up to date and is not an ideal way to build/test/run a .NET 4.5 library "accurately."

Http client issues aside, it appears that the best path to get this client with maximum platform support is to target netstandard 1.1 or 1.2. The best way to do that today is with a portable csproj that targets netstandard -- my blog post shows how to do that, but you will need a Windows build agent with VS 2015 Update 3 on it.

Happy to help/review as needed.

[thinkingserious]

@onovotny,

Those tests failed (I think) because at that time we were using an external service (stoplight.io) to create a mock SendGrid server and the variable that held the host URL was in an environment variable only accessible to people on the SendGrid team.

We have since updated that process so that the mock SendGrid server now runs locally in Travis.

With regards to your other comments, do you mind opening a separate issue for that. Perhaps "Improve CI Process" or something similar. Your help would be greatly appreciated! Note that currently, all our development is done the VS Community Edition. Our current thoughts are that we don't want to add any dependencies that would require someone to use a paid version of Visual Studio. Of course, I'd be happy to test this with your direction.

[mbernier]

The plan is to completely get rid of dynamic from the entire library as well as support .Net core.

[fa10]

@mbernier so no support for .NET Core? Wut

[Jericho]

@fa10 StrongGrid is built on top of .Net Standard and therefore compatible with .Net Core

[mbernier]

Oh, PHRASING!!!

The plan is to completely get rid of dynamic from the entire library [AND THEN ADD] as well as support for .Net core.

Rewritten:

The plan is to completely get rid of dynamic from the entire library and then add support for .Net core.

Sorry about that. My english, despite being my only language, is awful.

[Jericho]

@tinchou Thanks for the encouragement. Also, I edited my previous comment based on your feedback to make sure it doesn't come across as a "declaration of war" ;-)

[mbernier]

It should also be noted that we consider @Jericho a good friend and we support and appreciate the work he is doing on StrongGrid. We have been in some AMAZING conversations with him about our own library and his. We share ideas and thoughts, learning from him as we go.

[threevaluelogic]

+1

Just wanted to add my support for this! Sendgrid is my chosen email client and I would love to use it in my .net core solutions :).

[thinkingserious]

Thanks @threevaluelogic, I've added your vote to our queue.

[losolio]

+1!

[thinkingserious]

Thanks for the vote @losviko! Added.

[dwdickens]

+1

[garethrampton]

+1

[thinkingserious]

Thanks @dwdickens,

This issue is currently now under development :)

[kshyju]

I am waiting for this. 👍 .

[thinkingserious]

Hello Everyone,

I have pushed the support for .NET Core to the v9beta branch. The SendGrid library now targets .Net Standard and no longer has the dynamic dependency.

First, HUGE thanks to @Jericho, @0xdeafcafe, @Gekctek and @PaitoAnderson for their feedback and code contributions! More HUGE thanks to everyone on this thread for their patience and feedback!

In the Solution (in the v9beta branch) you will find two example projects, one using .NET Core and one using .NET 4.6. There are also Unit Tests (more like Integration Tests), but they only work in Visual Studio (I specifically have tested with the 2015 Community Edition) in Windows 10. I also uploaded a hidden Nuget package and tested the following configurations:

• .NET Core in Visual Studio Community Edition 2015 Windows
• .NET 4.5 in Visual Studio Community Edition 2015 Windows
• .NET 4.6 in Visual Studio Community Edition 2015 Windows
• .NET Core in Visual Studio Mac
• .NET 4.5 in Visual Studio for Mac
• .NET 4.6 in Visual Studio Mac

Unfortunately, I can not get the tests running on Travis CI, any help there would be appreciated.

Before I push the v9beta branch to Nuget as a beta release, there is one more task, the update of the Mail Helper, which is the next item on our list. Please see that thread for updates. It is likely that I will publish the new interface there for feedback within the next few days.

With Best Regards,

Elmer

[aKzenT]

Are there any news on when there will be a beta or non-beta version on Nuget available? Thank you!

[thinkingserious]

@aKzenT,

I expect a beta to be released by early next month at the latest. Since our backlog is dynamically prioritized and based on several variables, I can not promise an exact date. That said, this issue is currently our top priority.

[kierenj]

@thinkingserious Would you perhaps mind posting again here when it's available please? I'm subscribed to this thread & don't know where else to monitor!

[thinkingserious]

@kierenj,

I'm planning to release a beta to Nuget this week based on the current v9beta branch. I'll post here when that goes live :)

Thanks!

[thinkingserious]

Hello everyone,

BIG thanks to all of those that have contributed on this thread, we greatly appreciate your patience and support!

The v9beta branch has been pushed to Nuget as a prerelease for testing. Please give it a spin and let us know what you think :)

The main updates are:

• Removed dynamic dependencies
• Added support for .NET Standard 1.3
• Updated the Mail Helper for better UX/DX

Here is what we think needs to be completed before we exit beta:

• A few weeks of iterative improvements based on your feedback and internal testing
• Updated docs (USAGE, USE_CASES, TROUBLESHOOTING, CONTRIBUTING, /examples and the Helper Example)
• Update the auto-generated portions of the tests to use CamelCase function names
• Move from Travis to Appveyor
• Implement SendSingleEmailToMultipleRecipientsAsync
• Implement SendMultipleEmailsToMultipleRecipientsAsync
• Adopt StyleCop

The remainder of our wants for this version will be added to GitHub as issues.

With Best Regards,

Elmer

[0xdeafcafe]

Awesome, can't wait to have a play around with it. One quick Q:

Update the auto-generated portions of the tests to use CamelCase function names

When you say CamelCase, do you mean camelCase or TitleCase?

[thinkingserious]

Hi @0xdeafcafe,

Thanks!

Yes, I mean TitleCase. Then, with StyleCop I hope to avoid such mistakes moving forward. In this particular case it was a matter of me using the wrong function name generator (snake case vs camel case).

[kierenj]

Works a treat for my (admittedly simple) use case, thank you :)

[thinkingserious]

Thanks for taking the time to provide some feedback @kierenj :)

[szykov]

@thinkingserious I just tried and it worked like a charm. Haven't found where I can set an encoding for an email object but it works with Cyrillic out-of-the-box. Also noticed that right now we need to specify PlainTextContent and HtmlContent at the same time. The first idea was that it isn't right, that there had to be overloaded methods for each one, but then I realized that it was done for compatibility reasons if email-client can only work with a plain text only, I believe so, please correct me if I'm wrong.
Anyway, thank you @thinkingserious and SendGrid team for your wok. 🥇

[thinkingserious]

Thanks for taking the time to give it a try and provide feedback @szykov! Also, for the kind words :)

While it's not required to have both plain/text and plain/html, it is highly recommended to include both for maximal delivery (including the case you mentioned). So in this case, we are forcing some best practices via the helper example. That said, I don't think the helper deals with the case where you leave one of those out, so I'll get that fixed.

If you build the SendGridMessage object yourself, you do not need to add both mime types.

[thinkingserious]

@szykov,

I've updated the code to make sure the payload is still building correctly if you leave out the text or html: https://github.com/sendgrid/sendgrid-csharp/blob/v9beta/src/SendGrid/Helpers/Mail/SendGridMessage.cs#L1406

Thanks again for the heads up!