We were building a mail class used by SharePoint solutions that leverages the SmtpClient class because SPUtility.SendEmail() is too limited in some ways:
- It doesn’t send attachments.
- It contains a max of 2048 chars per line, although this can be circumvented by adding line breaks (‘\n’).
More about those limitations over here: https://sharepointdragons.com/2012/05/21/sputility-sendemail-limit/
However, we did want to use the SSOM to determine the SMTP server that should send the e-mail messages for us. We could do it like so:
System.Net.Mail.SmtpClient smtpClient = new System.Net.Mail.SmtpClient(objWeb.Site.WebApplication.OutboundMailServiceInstance.Server.Address);
But in this case, we went for this solution:
SPAdministrationWebApplication.Local.OutboundMailServiceInstance.Server.Address;
This resulted in the following method implementation in our custom SharePoint library is a class called Manager:
public string GetSmtpServer()
{
return Microsoft.SharePoint.Administration.SPAdministrationWebApplication.Local.OutboundMailServiceInstance.Server.Address;
}
Very simple. Then, we decided we needed to add some unit testing. If you have VS.NET Ultimate, you can consider using Microsoft.SharePoint.Emulators. We gave it a spin and weren’t that happy with it. At some point, we had to uninstall the package, switch the project to x86, install the emulator again, and switch back to x64, and more stuff like that. But apparently it can be done, according to: http://writeabout.net/2014/06/21/spemulators-available-on-nuget/ , so don’t let us stop you from checking it out!
Then, we were considering other Mocking frameworks (Typemock Isolator, JustMock, Microsoft Fakes) and decided to go with Fakes because of monetary reasons. We then added a unit test project ( VS.NET 2012 > Add > New Project > Unit Test Project), added a reference to our custom SharePoint libary, right-clicked it and chose Add Fakes Assembly.
If you want to know more about Fakes, check out http://msdn.microsoft.com/en-us/library/hh549176.aspx . Basically, it allows you to replace methods and properties during run time with your own implementation.
Because our custom SharePoint library uses the SPS 2013 SSOM it’s built for 64 bit, which required us to change the unit test project to 64 bit too (right-click unit test project > Properties > Build > Platform target: x64). That is not all, you also need to set the Test processor architecture to 64 bit, like so: VS.NET 2012 > TEST > Test Settings > Default Processor Architecture > X64.
When that is done, the unit test project is able to call the SharePoint custom library and we were able to create a shim for our GetSMTPServer() method., which goes something like this:
[TestMethod]
public void GetSmtpServerReturnsFakeName()
{
using (ShimsContext.Create())
{
MyLib.Fakes.ShimManager.AllInstances.GetSmtpServer = (@this) => { return ”mySMTPServer”; };
Manager man = new Manager();
// returns mySMTPServer
string smtpServer = man.GetSmtpServer();
}
}
SharePoint Dragons 