v4.0.0.4 #5
v4.0.0.4 #5
Conversation
AnthonyMusgrove
commented
Jun 2, 2020
AnthonyMusgrove
commented
- Added testing feedback, displays error if error exists, successful if no errors occur
- Added From Name to configuration settings
- Various other improvements
…ow obsolete. Compatibility issues with various email providers should now be resolved. Ignore SSL certificate errors is now a configurable option.
Integrated MailKit/MimeKit and removed obsolete SmtpClient library
…ded 'From Email Name', full error notifications on test fail, success result on test success.
- notification feedback on testing SMTP settings - added From Name - various other improvements
|
Instead of embedding dll's can you just embed the sources of those libraries? |
|
Absolutely mate I will check it out now |
|
So basically I copied the source for MailKit to \MailKit, MimeKit to MimeKit\ and theres about 30 odd other crypto libraries, 3000+ errors so far :) |
|
Having major issues trying to embed just the source for the libraries mate. The libraries are huge and there are so many external dependencies that I'd have to go down the chain and download each of them and embed their source. Am I just doing it incorrectly I wonder? mm :s |
|
I would probably suggest that we remove the System.Net.Mail.dll out of the Emby Core, and (eventually) include MailKit and MimeKit libraries in the core (because it is such an essential changeout), which would eliminate the need for any plugin to embed or include Mailkit or Mimekit dependencies. I wonder if that would be possible? Take for example the scenario where another plugin dev wants to send emails from their plugin -- System.Net.Mail.SmtpClient is now obsolete so no plugins should be using it, let's upgrade the core to natively support MailKit? |
|
It's not building because that code isn't meant to target .net standard 2.0. What runtime are the dll's compiled against? |
The reason I'm asking is because if we can't compile the library against .net standard 2.0, then we have to compile it against the runtimes. And that means two sets of .dll's - one compiled against the .net core runtime 3.0, and the other compiled against the .net framework 4.7. The netframework dll's would be used with the mono runtime, which the plugin would have to detect in order to decide which dll's to use. But embedding the dll's should be the last possible resort. |
|
Hey mate, my apologies for the late response Ill get back to you asap just on road :) |
|
Alright mate, sorry for the really delayed response. MailKit.dll and MimeKit.dll are compiled against standard 2.0. The solution has a different output for almost everything, including standard2.0 which I used in these.
|
|
If you use only the netstandard 2.0 dlls then maybe this will work. But then again, compiling the sources is still best. did you try adding these package references? |
|
As well as these removals: |
