Corrupted applicationHost.config file in IIS 7

IIS7 stores its parameters in an XML file, located typically at C:\Windows\System32\inetsrv\config\applicationHost.config. This is a nice solution as every parameter is clearly readable. Unfortunately, there are still some bugs (maybe in IIS 7, but some problems with anti virus programs have also been reported) and this file may be corrupted.
What to do when this file is truncated? Reset it and loose all of your settings?
Luckily IIS makes a backup each time you make a change. All those versions are stored in the folder C:\inetpub\history\. All you have to do is to copy a former applicationHost.config file into the C:\Windows\System32\inetsrv\config\ working directory.

WPF is all about Panels

Have you noticed how most applications' windows behave badly when it comes to adapt their dimensions to content or screen size? When you resize a window, only the center resizes and the other elements (toolbars, menus, ...) remain unchanged. Most popups have fixed size. It is true for local applications and also for HTML pages. HTML is supposed to be flexible and adapt its layout to content, but in real life, it is really difficult to control how HTML behaves. Apart from fixing elements' size, the result is unpredictable.

Fortunately today we have XAML, and the numerous Panels. Panels are in my opinion the most important contribution to complex application screens. But not every panel is equally useful. Forget about Canvas, which is the old fashioned way of placing element giving coordinates. It is all but flexible. Even the Grid panel that represents a table of cells is not as flexible as my favorite: the DockPanel. It fills up the window space starting from borders, and leaving the center for the main content. Be sure to fully understand how each kind of panel behaves, to be able to choose the correct one. Other useful panels are StackPanel, WrapPanel, ...

Panels come with another important notion: min/max width and height. Instead of fixing a column width, set its MinWidth value. It ensures that it will not render too thin if empty. Avoid at all cost fixing Width or Height, as you never know on what screen your application will be displayed. Test your interface with few or plenty of data, on tiny or huge screens. It should look great in every situation. Panels make it possible.

WCF on Vista raises an AddressAccessDeniedException

I was trying the example from the excellent book by Michele Leroux Bustamante about WCF, and cound not start them getting the exception AddressAccessDeniedException on ServiceHost.Open().
The solution is to start a console as an administrator (right click on the cmd.exe icon and select "Run as administrator") and execute:
netsh http add urlacl url=http://+:8080/ user=username

• The + is a wildcard for any domain

• 8080 is the port I used for my WCF services, use your own

• username is the user you logged in with, and can be preceded by DOMAIN\username

The problem happens only on Vista (and probably on Windows Server 2008) and not on former systems.

WPF is the future of HTML

I think that all the demos that can be found about WPF and Silverlight are wrong. They are showing how you can make funky animations, include videos and gradient colors everywhere.
But we are professionals and what our clients need is a powerful and robust client, so let's make classical layouts with normal checkboxes and tabbed screens. Nobody needs 3D interfaces where you have to scratch your head to guess how to use it.

Former HTML interfaces were poor and fragile, mixing many languages and standards. How to validate an e-mail input control? Add a server-side validation after postback or use Ajax? Or write a custom JavaScript? Do it on control blur or on keypress? Depending on the context, one of these solutions may do the job so you end up mixing all of them.

With WPF and XBAP, everything is clear. Keep all the client logic on the client, and in the same language as the rest of your code: C#. If you need some info from your database, call a remote procedure using a Web Service. Designing a perfect interface has never been easier: use panels wisely and drop your controls. Bind the numerous events to your actions and the result is there.

I intentionally did not talk about Adobe Air, which is having a similar approach to the light client problem. It is clearly promising and the example you can find on the Internet are much better and mature than those of WPF. However, even if Flash will keep its advance compared to Silverlight, the fact that Adobe Air uses JavaScript and the efforts Microsoft put into WPF makes me think that it is the right choice to make for most client developments.

COMException when opening WebApplication project

I recently go the following error while opening a Visual Studio solution: "System.Runtime.InteropServices.COMException". Not very explicit, is it?

I found a page in VisualStudio feedback explaining that this is a bug in Visual Studio 2008, that should be corrected "in the next release"...

The explanation is that VS is trying to locate your Web Application in IIS. Look into your project file *.csproj in the <WebProjectProperties> section, the searched URL is indicated in the <IISUrl> tag.

The solution is simple: in the <UseIIS> tag change "True" to "False" and your project will open like a charm.

Form'n'Field jQuery plug-in published

After long nights of fine tuning and restructuring, the first public version of the Form'n'Field plug-in for jQuery is available.

It helps JavaScript developers to handle client-side forms by giving access to field values in real types and not only strings as returned by DHTML. Why should the value of a checkbox be a string? Isn't it more natural that it is a boolean?

The same applies to listboxes. I often generate listboxes when item names are labels and item values are IDs from by database. Why would I have to convert those IDs from and to strings? I want them to be integers, and that's what the Form'n'Field plug-in does.
But what is the most advanced feature about this plug-in is how extensible it is. You can add your own input type (like a date input with pop-up calendar) easily. Or your complex data type (a JavaScript structure) can be associated with any existing input and handle type conversion and validation.

This plug-in is currently in production in my organization, and I hope that people will understand its value and constructively participate in its development.

Structuring JavaScript libraries: modularity

JavaScript pop up calendar is a common need, so why does none of the libraries I found match my needs. With Ajax are we often adding an "auto suggest" feature, so why isn't there a library that works in all the situations like auto complete, JavaScript dropdown lists and on-the-fly search boxes?

The answer is simple, all those libraries try to conceal the apparently contradictory needs that are generalization and customization.

We need to generalize to have calendar functions that can be used in all the situations without any modification. To achieve that we strip from the library all the features that are specific to a given case. We end up having a library that does almost nothing, like simply returning days of a month organized in a 7 days × 6 weeks grid.

We need to customize to have calendars displaying week numbers, allowing date range selection or time picking. To achieve that we add the features, and for each of them a flag that we can activate or not, allowing us to enable the feature only when needed. We end up having a library continuously growing, with numerous parameters and difficult to maintain.

The JavaScript language allows easy integration of multiple libraries with the notions of callbacks and object oriented programming.

The idea is simple: define core features and write separate libraries for each of them. Define the data structure that will allow communication between them. Define simple default behaviors for features that can be overridden with additional plug-ins.

If you use only the core library, you have a simple set of features easy to understand and with few parameters. You can plug more features if you need them. You can rewrite your own plug-in - and only this one - if it does not exactly meet your needs.

For a calendar, the code feature is to display a date grid. The data structure is a date value, with flags indicating if a date range is selected. The additional plug-ins could be week number information, enabling selection of a month or a year, adding a second calendar for range selection, allowing time picking.

Each of these plug-ins is obviously small, easy to maintain and debug. You reduce the amount of code to download to the client if you don't use all the features.

A common mistake is mixing HTML rendering with internal logic. Avoid that at all cost, and eventually make the render engine a plug-in.

Creating modular libraries may seem more complicated at first look, but forcing you to think of the structure before you start will make your ideas clearer and you will actually reach your goal faster.