Set up local SMTP for your .NET development environment on Windows 7

If you are developing a .NET application that sends emails then you need a way to do that without needing to actually send emails out. On Windows 7 with IIS 7 installed you can easily configure a local SMTP service that will intercept all the SMTP sessions initiated in your code and successfully emulate sending the outbound email by saving it as a text file in a folder on your local hard drive. This is extremely convenient and allows you to keep working on your code without interruption even when you are not connected to the Internet.

To achieve that just add a few lines in your application's .config file (could be web.config or app.config). Here is an example of such a configuration:

<system .net="">
  <mailsettings>
     <smtp deliverymethod="SpecifiedPickupDirectory">
        <specifiedpickupdirectory pickupdirectorylocation="c:\smtp">
     </specifiedpickupdirectory></smtp>
  </mailsettings>
</system>

After adding such a configuration every time your application sends an e-mail using a .NET framework built-in SmtpClient.Send method a new file with the .eml extension will appear in the configured folder.

You can open a file with any text editor like Notepad++ for example or you can use this free EML Viewer to improve viewing experience.

Re: Can architecture emerge from continuous refactoring?

Recently I've been asked this question "Can architecture emerge from continuous refactoring?" and since this topic is very close to what I do professionally I wanted to share my thoughts about it.

What is software architecture?

I see software architecture as a parallel to a traditional architecture: it consists of knowledge about everything that is required to build a successful software product as in to successfully construct a building. In a context of a particular project architecture eventually results in a team vision and a set of documents that guide the team towards the successful completion of a project and achieving the goal. From this point of view it is obvious that if the goal itself or any of its dependencies and prerequisite are not envisioned and well defined then a team simply will not know where to go and never reach the point of success.

Can software architecture emerge successfully from continuous small refactoring?

Often there is some legacy software in place and there is not enough time to redo the whole project from scratch so the only way is to apply small refactoring steps in order to make software better from the architecture standpoint.

Hence software architecture can and should emerge successfully from continuous small refactoring. For me this is not a theory but a proven fact since that is what most of my job as a Software architect consists of: I am orchestrating my development team to apply continuous changes and refactoring to the code base in order to shape the architecture into the right direction.

Factors of success and failure of a re-architecture project

The main reason for success is for a team to be persistent and consistent on the way and for an architect to have a complete vision, fully understand the final state of the re-architecture process and the way of the architecture transformations.

Opposite to the above when an architecture transformation is not a priority target and a team is not given enough time to work on the necessary changes then the new architecture will not emerge. It's not a "rocket science" and it's exactly the same process of achieving a goal as in any other human activity.

Some other reasons of re-architecture failure could be lack of the architectural vision, poor management, lack of architecture transformation understanding but I don't consider those to be the primary reasons bur rather the missing prerequisites for a re-architecture project.

Lessons learned on the way

Even though it's somewhat useful to learn from mistakes but I'd rather learn from successful implementations since what you can learn is a way to actually achieve the success.

Re-architecture methodologies

Some people are convinced that using a right tool will guarantee the success and therefore focus on comparing and selecting the "best of the best" methodology. Lately the "agile" word became very popular in regards to that.

From my experience any agile method is just a tool that may or may not help depending on a use case. Agile for me in this context is only a synonym of "continuous, persistent and consistent" way of moving towards a project's target. Whatever method is embraced by a team will work for me as long as it allows a successful completion of a project.

How to set programmatically a value of a watermarked TextBox via JavaScript - Update

Some time ago I've published an article How to set programmatically a value of a watermarked TextBox via JavaScript about some specifics of working with a text input box decorated with a TextboxWatermark Ajax Extender control from the Ajax Control Toolkit library. The technique described in the article has proven useful for a number of developers so when the new release of the Ajax Control Toolkit has recently been announced I've decided to update the article to cover some of the braking changes in Ajax Control Toolkit components.

Ajax Control Toolkit changes

One of the most significant changes in the recent Ajax Control Toolkit release that affected everything is renaming namespaces and control names. Most of the JavaScript classes in the ACT has been moved into Sys.Extended.UI and some of them renamed.

Correspondingly the AjaxControlToolkitTextboxWrapper class that is crucial for the technique described in this article is now called Sys.Extended.UI.TextBoxWrapper and this is a breaking change. Most if its methods haven't been renamed and this is a good news however the new way of using the wrapper has been introduced.

Below are the code examples demonstrating how to write the code correctly with the new version of the ACT.

First we need to acquire an instance of the Sys.Extended.UI.TextBoxWrapper class for our textbox control and this is the newly introduced technique compared to the previous version of the ACT:

// get the instance of a textbox element
var textBox = $get(textBoxId);
// use the get_Wrapper static method of the TextBoxWrapper class to get the instance of the wrapper for the textbox
var wrapper = Sys.Extended.UI.TextBoxWrapper.get_Wrapper(textBox);

In the code above first I assume that the ACT is present so I don't have to check that Sys.Extended.UI namespace is defined. Secondly the code above is safe even if the textbox is not watermarked: the get_Wrapper static method will always return the instance of the TextBoxWrapper; the new instance will be created if the textbox is not watermarked.

Now we can set or get a value of the textbox using the instance of the TextBoxWrapper:

// get the textbox value
var oldValue = wrapper.get_Value();
// set the textbox value
wrapper.set_Value(newVlaue);

Conclusion

In a nutshell there are two major changes introduced in the new ACT release that affect the coding technique described here: the name of the textbox wrapper class has been changed; and now it's not required to check whether the textbox is watermarked to use the technique above.

Leveraging Visual Studio JavaScript IntelliSense.

One of the most useful features of the Visual Studio 2008 and Visual Studio 2010 is JavaScript IntelliSense that allows developers write JavaScript code faster, with fewer errors and reduce learning time of some JavaScript frameworks. Many developers already enjoy its power when code JavaScript with Microsoft ASP.NET Ajax framework and jQuery. However many developers are still not familiar with that tool and even less developers realize that it can also be used with their own code.