Configurable deployment of deployable configuration. Part II

Mark Needham (of ThoughtWorks) had a nice post about configuring builds for different environments. Very clean and elegant approach and a great addition to my collection!

Update: and another two about per-user configuration and overriding properties.

The Agile Overdose

Do you follow the Agile Movement? Do you like some of the recent trends?

The problem, I sense, arises from the obvious fact, that more and more dedicated Agilists have moved from an actual development trenches to a coaching and high-level consulting. The agile coach is getting perceived as a spiritual leader, much like a Commissar in the Soviet Army. As such he does not have an assigned delivery, does not code or design architecture, so he uses his idle time to take agile theories off the ground and "develop" them out of the proportions. Inevitably they progress from the more or less fair "Design Up Front is Harmful" to derailed "Requirements are Harmful" and "Don't Let Clients Influence the Project" hallucinations. Pass me that butt, dude! I saw that "Estimations are Harmful" and going to the trip to "Code is Harmful" country!

[Note] If you think, that I am exaggerating then search Google yourself. I had all "practices" linked, but decided to be polite and not to point a finger.

Maybe I am mistaken and those guys are sober. Then, I guess, it's all about money. The community has said whatever it could, news are not so new anymore and a lot of companies, which wanted Agile process implemented, already did so. Now the army of coaches agielistas has to compete for the clients by inventing one buzzy theory after another. Personally, I would like to keep my faith in humanity and believe in the mushroom version.

P.S. BTW, same thing is happening within a blogging community. Quite a few reputed IT bloggers have recently "outgrown" simple development. Didn't you notice that too?

Introverted Programming: The Buzz-Oriented Architecture

It has been a while since the last article of my beloved Introverted Programming series. I consider it inappropriate, so here we go.

What is with all these new and newer approaches, the Service Oriented Architecture, Resource Oriented Architecture, Web Oriented Architecture, File Oriented Architecture, Thick Clients and Thin Clients, RESTful, SOAPless and Quo-Vadis Services? XP, CI, TDD, WPF, WCF, WTF and OMG technologies? Their successes and their failures?

What about a Get-Job-Done Oriented Architecture? I mean - when project was actually delivered, developers got paid and client has managed to not loose his business as a result?

I bet that will make a good line in resume...

Awesome video

No common sense allowed

The summer is over but not quite! You can pick a sense of that, if Agielistas' blogs are getting filled with fundamental ideas and not yet diluted by details, which is inevitable when you get back down the Earth.

It is amazing how resistant software industry is to the common sense. Project after project fail and still people start from the same wrong foot in the same wrong direction, hoping that this time luck will finally turn. Technical debt and understanding software investment as an asset are the best concepts to highlight this misconception.

Would you consider a time, but not lasting quality, as the primary factor for house repairs? Unlikely, especially if it is your primary residence. But "just get things done" is not exception for a software.

Would you borrow without knowing what the conditions are? And find out that interest is 100% payable hourly? But it is OK to take design and coding shortcuts, thus increasing technical debt.

Would you advice surgeon to save time by not washing hands before the operation? As a good professional, he most likely will refuse, even given an order. But developer is expected to cut off "luxurious" practices, such as unit testing and refactoring, when times are tight.

Construction industry has eventually learnt, at a great cost, that there are some practices, which better obeyed, than skipped. Software industry is still young to come to similar realization. Collapsed building makes the news, while collapsed software project is easier to swipe under the carpet. Of course, the culprits will be found and fired. And will lead another project somewhere else.

Encrypting sections of the Web.config file - the Continuous Integration way

The following algorithm is not the easiest way to protect your web.config (unlike this solution). There are few advantages, though. First, we can replicate an RSA key container between multiple servers in a Web farm, thus providing a scalable solution. Second - we can automate encryption and container distribution with Continuous Integration. Developers can enjoy a readable web.config file while CI script will take care of encrypted production version.

1. Add the following section to the root of the <configuration> node:

<configProtectedData defaultProvider="MyRsaProvider">
 <providers>
    <clear />
    <add name="MyRsaProvider"
        type="System.Configuration.RsaProtectedConfigurationProvider, System.Configuration, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL"
         keyContainerName="MySiteKeys" useMachineContainer="true" />
 </providers>
</configProtectedData>

Intellisense or Resharper may complain about keyContainerName and useMachineContainer attributes - don't believe it, they just comfused.

2. Now we can create the RSA container and make it exportable:

aspnet_regiis -pc "MySiteKeys"-exp

3. Next step is to encrypt a selected web.config sections:

aspnet_regiis -pef "connectionStrings" "c:\MySite\WebUI" -prov "MyRsaProvider"

The same way you can encrypt connectionString, system.web/membership, AppSettings and any custom configuration section.

Make sure that string attribute values in the encrypted sections (including the configProtectedData) are not split on several lines. The aspnet_regiis tool will try to reproduce the carriage return symbols and encode them:

It is not affecting the application execution in any way, but looks weird and confusing.

4. Save the above key to xml file in order to export it from your local PC to the WebServer (UAT or Production)

aspnet_regiis -px "MySiteKeys" "c:\mykeyfile.xml" -pri

-pri option enforces both private and public keys to be exported thus enabling encryption and decryption.

5. Now you have encrypted web.config file and key xml files. The first part - the deployable package creation, is done and your application is ready to be deployed to the web servers.

For the next two steps - deployment and permissions settings, the Continuous Integration script should be executed under account with admin privileges.

Import the key container on WebServer servers:

aspnet_regiis -pi "MySiteKeys" "c:\mykeyfile.xml"

To make Continuous Integration script more defensive, you can clean the container first. The task will attempt to remove key container, failing if container wasn't found, so it should be made fail-tolerant (failonerror="false" for NAnt script).

aspnet_regiis -pz "MySiteKeys"

Be careful to not run this task locally on the container source machine :).

6. Grant an access to the key container to the ASP.NET account

aspnet_regiis -pa "MySiteKeys" "DOMAIN\USER"

If, like me, you are never sure, what identity the ASPNET process runs under - test it by adding this code to any of your ASP.NET pages:

Response.Write(System.Security.Principal.WindowsIdentity.GetCurrent().Name)

Building a Web 2.0 Portal with ASP.Net 3.5

That's a lot of numbers so it can give you an impression that this is another very specific story about the hottest technologies of today. Well, it is. You can pick up most modern buzz words, put them in the resume and sound profound and sophisticated on job interviews.

There is more, though. Clever code shows up depths of a traditional ASP.NET, which you supposed to know at least for a last couple years to consider yourself a good ASP.NET developer. So, naturally, I found some stuff new for me.

And what is even better - the book guides you through framework building step by step, explaining every decision, tradeoff and implications of each choice made or rejected. It is rare and thorough overview of evolving architecture in a progress. Invaluable if you ask me, especially if you deprived a privilege to observe truly good architects in their natural habitat - a live project.

For a first glance check the live example, it is awesome.