Shashwat Chandra

When there is requirement  to send email in SharePoint , developers usually use

                          Microsoft.SharePoint.Utilities.SPUtility.SendEmail(web, false, false, emailId, MailSubject, htmlBody);

due to the fact that this class automatically uses the default SMTP configuration settings of the SharePoint.

Developers avoid using System.Net.Mail.SmtpClient class to send emails because they need to have the SMTP configuration before using this class. However they can use the below code snippet to automatically detect the SMTP settings with the help of SPWebApplication.

                            System.Net.Mail.MailMessage message = new System.Net.Mail.MailMessage();

                            message.IsBodyHtml = true;

                            message.Body = html;

                            message.From = new System.Net.Mail.MailAddress(SPContext.Current.Site.WebApplication.OutboundMailSenderAddress);

                            SPOutboundMailServiceInstance smtpServer = SPContext.Current.Site.WebApplication.OutboundMailServiceInstance;

                            System.Net.Mail.SmtpClient smtp = new System.Net.Mail.SmtpClient(smtpServer.Server.Address);

                            message.To.Add(emailId);

                            message.Subject = "Test";

                            smtp.Send(message);

A major drawback of using SPUtility.SendEmail is of its character limitation of 2048 per line which strips out the content of the Email after sending while System.Net.Mail.SmtpClient does not have  any such limitation.

The source code for several key .NET libraries is now available for debugging purposes. They are not "open source" in the sense you can do anything you want with them, instead there is a strict "look but don't touch" license known as the Microsoft Reference License. Even still, they should be an immense resource to .NET developers.

Scott Guthrie announced that Microsoft intended to release the .NET source code back in October. Since then we have not heard much with everyone's attention split between Visual Studio 2008 and the various post-release libraries still under development.

The source code is only available via Visual Studio 2008's integrated debugging features, and then only for the paid SKUs. Hobbyists using VS Express or a third-party editor will not be able to download the files.

Once you follow the instructions in Shawn Burke's Blog, stepping through Microsoft's source code is just as easy as looking at you own. You can also look at the source code directly for classes you have already seen, but this requires digging through the symbol cache.

The namespaces included in the initial release are

• System
• System.CodeDom
• System.Collections
• System.ComponentModel
• System.Data
• System.Diagnostics
• System.Drawing
• System.Globalization
• System.IO
• System.Net
• System.Reflection
• System.Runtime
• System.Security
• System.Text
• System.Threading
• System.Web
• System.Web.Extensions
• System.Windows
• System.Windows.Forms
• System.Xml

It’s wrong to stereotype people. It isn’t wrong, however, to recognize classifications of the team members you deal with every day. Many of the types of techies identified below may seem familiar to veteran IT managers. My ideas on how to work effectively with each type follow the descriptions.

This information originally appeared in the article “Tame these 10 types of techies,” by Patrick Andrews.

#1: Human Bottleneck

These techies either demand to do all the coding, or never finish their work, or both. Impress upon them that quality is often the opposite of perfectionism. Also, feed them small, well-defined tasks and praise any competent output that is on schedule.

#2: Bright Green

These straight-out-of-college developers like the new, cool technology. They tend to over-engineer by exploiting all the bells and whistles of the development environment — even when it’s inappropriate. These green techies often rely on their planet-size intellects to help them get back on schedule in predelivery all-nighters. Introduce them to colleagues who recently were Bright Green but learned the hard way to focus on deliverables.

#3: Tried-But-Untested

The mantra of these techies is, “Hey, we’ve got a whole testing team, why should I worry about checking my code?” It’s a guarantee that these specimens will cause you grief, so it’s essential to pull them up short. You’ll be doing them a favor in the long term.

#4: Techno-Babbler

Their code doesn’t work because they “need” something. These techies spend too much time in newsgroups and fail to realize that overusing jargon is not a sign of adulthood. Require these techies to give an acronym-free, from-first-principles explanation of project results to management.

#5: User-Loser

These techies consider many client questions stupid and deem the client worthy of a verbal flame. This often leads to the client not doing business with your company in the future. If your developers have contempt for “suits,” try introducing a “dress-up Wednesday” — and keep them away from outside phone contact.

#6: Task Farmer

As your self-appointed deputy, this type of techie assumes that the project plan is only a guideline and that it’s acceptable for team members to swap roles and tasks without asking you. Clarify that although their suggestions are welcome, you’re the one who carries the weight of the project.

#7: Under the Radar

This colleague has a tendency to generate maximally obscure code. This is usually a way to hide inelegance of implementation and to secure employment by preventing any other developers from working on his or her input. A curative strategy is to make the techie responsible for technical mentoring of a demanding Bright Green team member.

#8: Winging-It Commander

This type of techie’s curriculum vitae says they’re proficient in Java, SQL, and Perl, but their lines of code are sparse and curiously primitive. This techie will also place unusual demands on other team members to help “debug” their deliverables. Projects can’t accommodate this level of on-the-job training. Encourage team members to be honest about their technical comfort zones by offering them appropriate training opportunities.

#9: Prima Donna

These characters simply won’t tackle mundane tasks. And if you suggest that they have to adapt existing code, there’s always a performance of operatic proportions. Make it clear that they’ll work for the technical author for a month if this nonsense persists.

#10: Gender Agenda

Some developers have trouble working for, or even alongside, colleagues of the opposite sex. Challenge their assumptions by introducing them to a cross-section of your most accomplished colleagues.

Project managers don’t have time to conduct therapy sessions in the course of an already-demanding project. All you can do is recognize team members’ specific ongoing issues and ensure that they don’t damage the work in progress.