Sending email in MVC6? - email

I have tried referencing system.net.mail in various frameworks:
framework: "net451"
dependency: "System.Net.Mail": "1.0.0-rc2-00001"
error: does not support framework
framework: "net46"
dependency: "System.Net.Mail": "1.0.0-rc2-00001"
error: does not support framework
framework: "dotnet5.4"
System.Net.Mail not available
framework: "dnx46"
System.Net.Mail not available
I have also tried using email package MailKit 1.2.21, installed from NuGet.
"net46": {
"dependencies": {
"MailKit": "1.2.21"
}
If I reference MailKit class, error: "The type of namespace cannot be found".
How do I send email in MVC 6?

I have given up with the 3rd party libraryies. I created an Azure storage table, and the websites save their emails to this table. I have a Raspberry Pi in the server room which looks for new emails on the Azure table every 1 minute, pulls them off the table and sends them. There is a library for accessing Azure storage using Linux Python.
Also set up a 3G dongle on the PI and now can send SMS texts from my MVC6 websites as well!
This is far away from the solution I was looking for, but it works.

MailKit does not currently have an assembly specific to net46, but there's no reason you couldn't use the net45 MailKit assembly.
Apparently nuget does not figure this out automatically for you and just reference the net45 assembly, so you'll have to do it manually.
I'll try to make the next MimeKit and MailKit release include net46 assemblies in the nuget package (which will probably just be net45 assemblies in the net46 directory in the nuget), but I'm holding off on making a new release until Microsoft releases dotnet 1.0 rc2.
I've been expecting this release every day for about a month now :(

Related

Any API works like Microsoft.Azure.NotificationHubs and can be used in .NETFramework 4.5.2 project?

I plan to use the Microsoft.Azure.NotificationHubs to push notification through Azure notification hub in backend service of an existed project. However, I found that the project is using .NETFramework 4.5.2. As the document stated, the SDK has dependecy to .NETFramework 4.6.1 or higher.
Since the existed project is already developed well and problems could appear if I upgrade. Any other solutions please?
Due to you don't want to upgrade to .Net Framework 4.6.1 or higher. You can use REST API, create HttpClient in your existed project to send Http Request.
(notificationhubs)REST API methods
You can use HttpHelper in my sample code.

ModernHttpClient Not Compartible with Web Appication Project

i am currently using Restclient to send request via web api for xamarin, it works well with windows and ios but i doesnt work for andriod , i searched and found a nuget package that will help, called ModernHttpClient,so it changes my code from var httpclient = new HttpClient(); to var httpClient = new HttpClient(new NativeMessageHandler()); but when i install it for the web application i keep getting an error stating the package is not compatible with the project. but it installs ok in android,ios and windows. i tried uninstalling it from the web application but i doesnt work in the code unless it appears in all the project.
so i want to find the reason why the package is not compatible with the web appication or a solution to the Restclient request not working on android .
Unfortunately the product page for modernhttpclient on nuget.org doesn't list any dependencies, but changing the domain name of the URL to use fuget.org instead of nuget.org lists monoandroid, monotouch, portable-net45+winrt45+wp8+wpa81, and xamarin.ios10. Therefore, these are the target frameworks that the package supports.
Another way to check what TFMs (target framework monikers) a package supports is to find/download the nupkg and then open it as a zip file, or use NuGet Package Explorer to look for subfolders under lib/.
You didn't say what target framework your web app is using, but this is where things start getting very complicated and I don't understand it very well. .NET Framework TFMs are compatible with other .NET Framework TFMs of lower versions. Similarly .NET Core TFMs are compatiable with other .NET Core TFMs of lower versions. .NET Standard is a whole other complication. NuGet also supports fallback or alternate TFM compatibility, to allow .NET Core apps to use libraries targetting .NET Framework, but it's a best guess and might fail at runtime (maybe it's even possible to fail to compile, I'm not sure, but restore will succeed with a warning). Given you're not getting the warning, but instead an error, it suggests to me that portable-net45 is not compatible with net45 and therefore probably isn't compatible with whatever target framework you're using with your web app (unless your web app is targetting net40 or earlier).
Having said all that, when I was looking at the package to see which frameworks it targets, I saw that the whole point of the package is to use the platform native HTTP stack, instead of Xamerin's HTTP stack on the mobile platforms. Your web app isn't running on a mobile platform, it's running on either .NET Core or .NET Framework, so you shouldn't need the package. I suggest you use #if, #else and #endif to use NativeMessageHandler only on Android and IOS, and then use the default HTTPClient constructor (or use HttpMessageHandler) on other platforms.

Adding a package with pre-release dependencies

Using LINQPad I've added a private feed to Visual Studio Team Services. However one of my packages requires a pre-release package: Quartz.Net in my case. I've ticked Include Prerelease but I think it's getting confused and trying to load the package from my private feed rather than NuGet.
I've tried to work around the issue by loading the package into the local package cache. LINQPad doesn't seem to consider this. Other than uploading these packages into my own private feed, what options do I have? I'm not going to alter my own packages to get around LINQPad's shortcomings.
Note: I've setup the VSTS feed according this question.
Here is what my NuGet feeds look like in LINQPad
Changing the package to pre-release fixes this issue, and add the pre-release packages dependencies to my own feed.
Now LINQPad attempts to add the package. Mind you I now get another error;
"There are no usable .NET assemblies in package
'MyPackage.Common(Prerelease)'
That's down to NET Standard & NET47 support.

How to bring EWS Managed API 2.0 to nuget

As of now the latest version of the Exchange Web Services Managed API is 2.0. The only package on nuget is http://nuget.org/packages/Microsoft.Exchange.WebServices/ which is 1.2.
What is the proper way to bring the latest managed api to nuget? Do we have to request a package from Microsoft? Is it legal to create a package and push it to nuget?
Since there are many Microsoft libs on nuget that have been packaged by 3rd parties, I decided to go ahead and put it up there: https://www.nuget.org/packages/EWS-Api-2.0/

Deploying that utilises .Net Reactive Extensions

Our application utilises Reactive Extensions (Rx). These are normally installed via the downloadable package from Microsoft. However, when we ship our application we supply copies of the dlls (namely System.CoreEx.dll and System.Reactive.dll). There appear to be two versions in the GAC v1.0.2787.0 and v1.0.2856.0. We are referencing a specific one and ship the appropriate versions.
However when the application launches it throws an error dialog which states the Rx Dlls must be installed in the GAC. It also requests the Dlls for the other version of Rx e.g. if you are referencing 1.0.2787 it will request 1.0.2856.0 and vice versa.
Has anyone got around this problem?
The Rx assemblies don't need to be installed into the GAC unless your application's assemblies are installed in the GAC. Does your application need to be installed in the GAC or can it run from the installation directory?
It also requests the Dlls for the other version of Rx e.g. if you are referencing 1.0.2787 it will request 1.0.2856.0 and vice versa
It's unlikely that it's actually requesting across versions of Rx. You might want to double/triple check that your solution (all projects) all reference the correct (and same) version of the Rx assemblies.