.NET Reflector is becoming a paid-for product

As you may already have learned the famous .NET Reflector created by Lutz Roeder almost a decade ago that was always free to use is becoming a paid-for product thanks to Red Gate Software. The decision is confirming the worst suspicions many had when first heard about Lutz's agreement with the Red Gate and has already created a massive controversy in development communities.

For those who do not remember the .NET Reflector was born in the beginning of 2000s and has quickly become one of the must-have tool for every serious professional .NET developer. A large users community has quickly formed around the tool and many great add-ons have been written by inspired developers. Reflector has influenced great many developers' careers and earned community recognition. Scott Hanselman included the program in his "Ultimate Developer Tool List".

The Reflector's success was growing for over half a decade when out of a sudden the original author of .NET Reflector announced about his decision to stop developing the product and give it over to Red Gate Software in August 2008. One part of the agreement was that

...Red Gate will continue to provide the free community version... [of .NET Reflector]

confirmed by James Moore of Red Gate Software but many had skepticism about that part of the agreement from the very beginning.

During the period of Red Gate's ownership there were not many real improvements to the Reflector except for the annoying built-in "time-bomb" feature forcing one to upgrade to the newer version of the product even though the installed version worked perfectly. Some time ago a paid-for "Pro" version was announced with an obvious reason to raise some money for the owner but based on the Red Gate's plea was not successful among developers. One of the suggested explanations for that is that paid-for functionality was not really of any interest (more creativity, please, Red Gate) for professionals and beside there were already free add-ons doing similar things.

So now Red Gate wants to charge $35 for "a perpetual license, with no time bomb or forced updates" for the version 7 that will come out in early March and promises some new features in V7.

Red Gate claims that they need money to "keep .NET Reflector up-to-date and relevant" and cannot do that "without revenue coming in". That may be true for the Red Gate Software but there is a proven recipe for that: how about make the product open source, put it on Code Plex or any other similar location and let the community take care of its relevancy? To make it even more interesting let's make it a challenge: you, Red Gate, charge for your new shiny V7 but give away the previous version to the open source community and let's see which version survives in a few years. I personally have no doubts on the results.

There is a discussion going on about the Reflector's future on Red Gate's user forum. However if you are a professional developer that uses and loves Lutz Roeder's Reflector I encourage you to share your opinion and vote for the Reflector's future right here in my blog on the right side or answer polls on LinkedIn here and here. Please share the poll with your friends and colleagues.

---

UPDATE

Interesting list of open-source alternatives to Reflector on Stack Overflow: http://stackoverflow.com/questions/2425973/open-source-alternatives-to-reflector

To my taste the closest to .NET Reflector user experience is provided by the ILSpy. I am going to try and compare it with the Reflector.

---

Another UPDATE of May 1, 2011
Apparently free Reflector's lifespan is going to end on May 30, 2011. Today I've started my free copy and saw this alert:

---

UPDATE of May 31, 2011
Free version of Reflector is finally dead. Now those who does not want to switch to a paid version has to consider alternatives. A couple of new alternatives include:

JustDecompile

Telerik has recently released a beta version of their new JustDecompile, designed to enable easy .NET assembly browsing and decompiling. While Telerik is not know for free software, this product is featured as being free. According to Telerik, "Unlike Open Source alternatives, Telerik JustDecompile benefits from a dedicated development team, which is focused on continuously improving the product in line with your feedback. Telerik is recognized as one of the leading providers of .NET development tools and JustDecompile will benefit from our years of experience in the field."

dotPeek

JetBrains, an author of an extremely popular ReSharper Visual Studio add-in, has recently released a beta version of the dotPeek which is another new and free .NET decompiler with search features from JetBrains. dotPeek has gone public for the first time on Wednesday, May 11, as JetBrains opened an Early Access Program (EAP) that implied regular publishing of pre-release builds. According to JetBrains they are going to keep the product free.

---

Final Thought

JetBrains dotPeek has become my tool of choice for the time being. It's functional, free and being updated frequently. For those who also uses JetBrain's ReSharper starting version 6 the dotPeek functionality is built-in and available through the Navigate/To Decompiled Source menu.

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.

Automatically compress embedded JavaScript resources with Microsoft Ajax Minifier

Recently Microsoft has announced yet another useful addition to an ASP.NET developer tool belt: Microsoft Ajax Minifier, a tool that enables you to reduce the size of a JavaScript file by removing unnecessary content from it. Clearly this is an extremely useful tool and the ASP.NET development community has gladly embraced it (just google it up to see a lot of positive responses). The tool indeed works very well and there have even been a number of articles comparing it to other well-known JavaScript compression tools that proved its quality. So there are no doubts whether to use the Minifier or not.

The question however is how to use it. Microsoft Ajax Minifier package does include a set of documentation that explains how to use the tool and even discusses a couple of usage scenarios. Unfortunately the way I wanted to use the Minifier is not covered in the documentation and for some reason I haven't found useful information on the Internet too so I've decided to do some research and share my findings with the community.

So how would I like to use the Minifier? Here are the requirements:

1. I want to automatically compress embedded JavaScript resources in any project of my web application solution.
2. I want the compressed JavaScripts have the original names so I don't have to change the references in HTML mark-up.
3. I want the compression to be done only when I switch to the Release mode in Visual Studio. When I am in the Debug mode I want all the JavaScript files to be uncompressed for easier debugging.
4. I want compressed JavaScript files never overrides the original JavaScript files and I don't want to keep the compressed JavaScripts so whenever I modify my JavaScript code the compressed resources are always up-to-date.

I believe that the requirements above describe one of the most common web application solution configuration so if there is a way to achieve them it would be very useful.

Can I achieve the requirements above with the Microsoft Ajax Minifier? The answer is yes. The solution is kind of obvious: since the Microsoft Ajax Minifier includes an MSBuild task I just need to modify a project file where I have embedded JavaScript resources that I need to be compressed to include the Microsoft Ajax Minifier build task. It does not sound complicated and below is the solution which is simple indeed. Just include the following XML in your project file right before the closing </Project> tag (in most cases):

<!-- Minify all JavaScript files that were embedded as resources -->
<Import Project="$(MSBuildExtensionsPath)\Microsoft\MicrosoftAjax\ajaxmin.tasks" />
<PropertyGroup>
<ResGenDependsOn>
MinifyJavaScript;
$(ResGenDependsOn)
</ResGenDependsOn>
</PropertyGroup>
<Target Name="MinifyJavaScript" Condition=" '$(ConfigurationName)'=='Release' ">
<Copy SourceFiles="@(EmbeddedResource)" DestinationFolder="$(IntermediateOutputPath)" Condition="'%(Extension)'=='.js'">
<Output TaskParameter="DestinationFiles" ItemName="EmbeddedJavaScriptResource" />
</Copy>
<AjaxMin SourceFiles="@(EmbeddedJavaScriptResource)" SourceExtensionPattern="\.js$" TargetExtension=".js" />
<ItemGroup>
<EmbeddedResource Remove="@(EmbeddedResource)" Condition="'%(Extension)'=='.js'" />
<EmbeddedResource Include="@(EmbeddedJavaScriptResource)" />
<FileWrites Include="@(EmbeddedJavaScriptResource)" />
</ItemGroup>
</Target>

What this script does is when the solution configuration is 'Release' it finds all the project embedded resource files with the extension '.js' and creates their compressed versions with the same names in the intermediate output folder where they are picked from later by the build process.

A few tips

As you may have noticed the Microsoft Ajax Minifier MSBuild task is referenced from the default folder where it was copied to by the installer. If you want to reference it from a different location, for example if you have a shared development environment and want to have similar setting for everyone, just copy two files ajaxmin.dll and ajaxmintask.dll to another location and include the <UsingTask> tag (below) instead of the <Import> tag in the script above:

<UsingTask TaskName="AjaxMin" AssemblyFile="$(MSBuildProjectDirectory)\..\Build\AjaxMinTask.dll" />

The presented script performs so called 'Normal Crunching' (see the Ajax Minifier documentation) of the JavaScript code which already does a pretty good job that is good enough in most of the cases: compression rate is over 50%. If you would like to turn on the 'Hypercrunching' mode (see the Ajax Minifier documentation) you only need to modify one line of the script to include the 'LocalRenaming' option of the Ajax Minifier:

<AjaxMin SourceFiles="@(EmbeddedJavaScriptResource)" SourceExtensionPattern="\.js$" TargetExtension=".js" LocalRenaming="CrunchAll" />

And the last note is: don't use the default Hypercrunching mode or RemoveUnneededCode option with the ASP.NET AJAX Framework as it does not work properly with it.

Using the Microsoft Ajax Library 3.5 with the CDN

Recently Microsoft has announced its Microsoft Ajax content delivery network (CDN) which can significantly improve the performance of any ASP.NET AJAX web application. When it was first announced the CDN was almost useless for the current web applications based on ASP.NET 3.5 since it did not host the Microsoft Ajax library 3.5 and did not support content delivery via SSL. However in a very short period of time Microsoft was able to fix those problems (good job!) and now web applications built on ASP.NET 3.5 can benefit from using Microsoft Ajax CDN.

So how do you make MicrosoftAjax.js file being referenced from the CDN as opposed to the embedded file? Quite easy actually with the help of the ScriptManager control. Add the following declaration to a page (or Master page) where there is a ScriptManager control:

<asp:scriptmanager runat="server" enablepartialrendering="false">
  <scripts>
    <asp:scriptreference name="MicrosoftAjax.js" path="http://ajax.microsoft.com/ajax/3.5/MicrosoftAjax.js" />
  </scripts>
</asp:ScriptManager>

What that declaration means is that the script with a name MicrosoftAjax.js which is always automatically referenced by a ScriptManager from the System.Web.Extensions dll now should be referenced from that location: http://ajax.microsoft.com/ajax/3.5/MicrosoftAjax.js.

This is how it is referenced by default:

<script src="/ScriptResource.axd?d=eYUqBJhfSVL41hIDYkBL0tfaps9hoQId_48PydfbcyWH41vNvL68sk-l7P9FLAPz7b4vtI8WkZ-ezAF0b_ZkyG52wt9oUtaQ5ezFfGBr7LY1&t=ffffffffef976216" type="text/javascript"></script>

and after we include the new ScriptReference declaration:

<script src="http://ajax.microsoft.com/ajax/3.5/MicrosoftAjax.js" type="text/javascript"></script>

ScriptManager is even smart enough to automatically reference the debug version MicrosoftAjax.debug.js from the CDN when debugging is enabled in the web.config file:

Web.config:
<compilation debug="true">

HTML:
<script src="http://ajax.microsoft.com/ajax/3.5/MicrosoftAjax.debug.js" type="text/javascript"></script>

So this is clear: we have our MicrosoftAjax.js referenced from the CDN and that improves our web application performance and saves us and the visitors some bandwidth since an internet browser will reuse the same cached copy of the MicrosoftAjax.js from the CDN for different web applications that reference it.

Using the CDN conditionally

What if we only wanted to reference MicrosoftAjax.js from the CDN when the web application is deployed to a production environment and use an embedded version in a development environment? That would make sense in order for the developers to work without having to be connected to the Internet. Once again it can be done but this time we'll need to write some code. We are going to add the MicrosoftAjax.js script reference dynamically depending on the debug value in the web.config file; we only add the script reference when debug="false":

protected void Page_Load(object sender, EventArgs e)
{
  if (!Context.IsDebuggingEnabled)
  {
    ScriptManager sm = ScriptManager.GetCurrent(this);
    sm.Scripts.Add(new ScriptReference 
      {Name = "MicrosoftAjax.js", Path = "http://ajax.microsoft.com/ajax/3.5/MicrosoftAjax.js"});
  }
}

Using the CDN via SSL

Another major case is when our web application has pages that are served via SSL. In this case we want to automatically select the correct CDN URL for the MicrosoftAjax.js. In order to do that we just modify the previous code:

protected void Page_Load(object sender, EventArgs e)
{
  if (!Context.IsDebuggingEnabled)
  {
    ScriptManager sm = ScriptManager.GetCurrent(this);
    sm.Scripts.Add(new ScriptReference 
       {Name = "MicrosoftAjax.js", Path = Request.Url.Scheme + "://ajax.microsoft.com/ajax/3.5/MicrosoftAjax.js"});
  }
}

So that's it for now. Enjoy using the Microsoft Ajax CDN.

Talk about P&P Web Client Software Factory on Toronto Architecture User Group meeting

Developing modular web applications is a popular topic in development communities especially after ASP.NET MVC framework has been introduced by Microsoft. However ASP.NET MVC is not the first and only framework that can help on that way.

I'll be talking about building modular enterprise-class modern web applications with the help of MVP design pattern and Microsoft Patterns and Practices Web Client Software Factory framework on the next meeting of Toronto Architecture User Group on Thursday October 29th. To attend please register online here.

Problem with Internet Explorer 8 Debugger on Windows 7

I continue to evaluate Windows 7 after upgrading from Windows Vista and share some experience (mostly bad of course, so people would not step on the same problem again). As I mentioned before, overall upgrade was smooth and mostly everything works OK. However time to time I stumble upon some really annoying problems that did not exist on Windows Vista and therefore need to be solved for Windows 7 from scratch.

One of the recent problems was Daemon Tools not working on Windows 7 and it was solved by installing Magic Disc. Now there is one more thing: after upgrading to Windows 7 I am not able to use IE8 Debugger. When I pressed F12 the Debugger icon appeared on the task bar but I can not switch to its window: it's not visible.

So obviously I searched over the Internet and luckily there was one post on Stack Overflow (apart from those guessing about a window being outside of the screen) that suggested that there may be some wrong setting in Windows registry. And there are some registry keys related to IE8 debugger! So the solution was to remove WindowsPos, Pinned and UseDevToolsDebugger keys from the [HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\IEDevTools] section. That completely solved the problem.

Unfortunately I can not tell whether those keys existed in Windows Vista and were incompatible with Windows 7 or their values have been incorrectly modified during the upgrade. But after removing them and starting IE8 debugger they haven't appeared again. So probably they are not needed anymore.