OpenSSL became publicly known (unfortunately) for the wrong reasons. Their development team got the typical backlash that System Administrators usually get: if everything is working fine nobody cares, as soon as something bad happens everybody loses their mind. I'm obviously talking about the Heartbleed bug. Before Heartbleed was found, it was estimated that 61% of all Apache servers used OpenSSL to handle TLS/SSL connections. As soon as it was found a lot of people freaked out. Successfully using this exploit could allow an attacker to read a target server memory, extract its private key and ultimately mount a man-in-the-middle attack . On the other hand, OpenSSL development team consisted of 11 contributors and a budget of less than $1 million a year (most of it from donations). In a world where even large Corporations, with almost unlimited resources, consistently release buggy software, a team of eleven developers should be allowed to make a few mistakes.
The first step of any robust development workflow relies on a structured and well-defined build process. Having a manageable build process can spare your development team from wasted time, headaches and unnecessary complexity. If you're handling a handful of projects with low compilation overhead, this particular topic might be irrelevant to you. Today's article is mainly targeted for those who must work with multiple projects, of different kinds (Web applications, Scheduled tasks, Console applications, Mobile application, database script, so on) and deploy multiple artifact types.
Here's another quick tip for anybody interested in protecting sensitive information declared on your Web application web.config. In this example I'm going to use Windows Data Protection API (DPAPI) to encrypt connection strings and session state SQL connections string on all web.configs found under 'C:\inetpub' (default location for web applications running on IIS).
These days it might be a bit uncommon to find anybody creating new SOAP (Simple Object Access Protocol) web services. However that does not mean SOAP web services are dead. Due to public perception, Software companies avoid mentioning components that might be considered "old" (or not trendy). In a highly competitive market, where companies keep fighting for the best Developers, referencing older technologies might throw some candidates off. Still, that does not mean components developed with "older" technologies do not require maintenance.