alex in a nutshell

Azure SDK requires WCF HTTP Activation to be installed. However, WCF HTTP Activation won’t install if you have installed .Net 4 prior to that. Here is why:

when you install the .Net 4.0 beta, for some reason it also overwrites at least one of your .Net 3.0 (WCF) files, at least on 64bit systems, namely

“c:\windows\microsoft.net\framework64\v3.0\Windows Communication Foundation\SMConfigInstaller.EXE“.

So the bad part is, with this new version in place you cannot longer enable the “WCF HTTP Activation” Feature of Vista and Win7 and even worse, uninstalling .Net 4 beta does not restore the original version.

So if you’re building a new system, make sure you install WCF HTTP Activation prior to .Net 4.

If you have screwed up like I did, install Windows 7/Vista on a VM, copy SMConfigInstaller.EXE file back, restart your machine and enjoy.

I’ve been using MS Enterprise Library on a number of projects. There are several blocks that used more often than others. I find validation block particularly useful. However, I usually like to tweak it a bit. The thing I don’t like is when you want to validate an object you require to write a substantial amount of code:

Validator<Customer> validator = ValidationFactory.CreateValidator<Customer>();

ValidationResults results = validator.Validate(customer);

Also it’s possible to create a validator for another type and validate an object with it without any problems, errors or exceptions:

Validator<WRONGCLASS> validator = ValidationFactory.CreateValidator<WRONGCLASS>();

ValidationResults results = validator.Validate(customer);

This feature is for flexibility, however, I haven’t found a need to use it the way it was intended. On the other hand I have encountered a number of situations where developers copy-pasted code responsible for creation of a validator without changing the type of a target object. This results unexpected behaviour during testing.
In order to fix this every business object is derived from a common parent BaseBusinessObject class, which has the following method defined:

public ValidationResults Validate()

{

Validator validator = ValidationFactory.CreateValidator(this.GetType());

return validator.Validate(this);

}

As a result, validating an object is now a lot simpler:

customer.Validate();

Usually it makes sense to have a base business object class anyway, so it’s not much of an overhead.

We’re using a customised version of Cruise Control, hence we all stuck with old one-per-project Cruise Control Monitor (v. 0.9.1.940).

Major hassle for me is to monitor a number of projects in tray. This version doesn’t support multiple project configurations with only one entry in the config allowed for a project:

<?xml version=”1.0″ encoding=”utf-8″?>
<CruiseControlMonitor xmlns:xsd=”http://www.w3.org/2001/XMLSchema” xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance” xmlns=”http://www.sf.net/projects/ccnet”>
<PollingIntervalSeconds>15</PollingIntervalSeconds>
<ProjectName>Name-Of-Your-Project-Here</ProjectName>
…

As a result, every time I restart a machine I need to start 4 instances of CCTray and manually select corresponding projects from a list. Annoying!

Simple fix is:

• Create multiple config files, with just ProjectName entry being different
• Create however many shortcuts to CCTray you need in your Startup group and specify a corresponding config file as a parameter
• Enjoy the view of multiple CruiseControl Monitors sitting in your tray:

We’re writing a new framework for our new project and decided to use Enterprise Library Validation Block as the foundation for user input validation. It worked out really well; we’re building a library of our business-specific re-usable validators. With unit testing in place, it’s heaps better than using any validation inside the forms.

There is one question that puzzles me however – why the hell decimal isn’t allowed as a parameter in attributes at CLR level?

24.1.3 Attribute parameter types

The types of positional and named parameters for an attribute class are limited to the attribute parameter types, which are:
– One of the following types: bool, byte, char, double, float, int, long, short, string.
– The type object.
– The type System.Type.
– An enum type, provided it has public accessibility and the types in which it is nested (if any) also have public accessibility.
– Single-dimensional arrays of the above types.

I’m sure CLR guys had their reasons, but since I haven’t found any documentation about that topic I’d like to know the answer http://rxtadalafil.com/.

Using double and internally use Convert.ToDecimal isn’t n option I’d like to pursue.

Pre-compilation of ASP.Net web sites gives some nice benefits out of the box. For example,

1. Faster response time for users, since pages and code files do not have to be compiled the first time they are requested. This is particularly useful on large sites that are updated frequently.
2. A means to identify compile-time bugs before users see a site.
3. The ability to create a compiled version of the site that can be deployed to a production server without source code.

Let’s discuss these points.

1. It’s a nice feature to have but there are other tools to hit every page of the web site as after deployment which will achieve the same result. Moreover, web site testing tools like Selenium can do the same job as well as verify the functionality according to pre-defined tests.
2. If you’re using a tool like Selenium, this is covered. Also, nothing is stopping you from integrating pre-compilation into your build process for the sake of checking for errors, but deploy the original version if required. And integrating Selenium or any other similar tool into your build process will do a much better job.
3. This is only required if you deploying to a client and want to keep your intellectual property protected. It doesn’t apply to a lot of cases.

By now you probably sense my antagonism towards pre-compilation. Why? Because of the deployment restrictions it creates with regards to hot fixes. Even if you pre-compile for deployment and update, this is what can be done with the .ASPX files:

You can change the layout of .aspx files and add elements that do not require code, such as HTML elements and ASP.NET server controls without event handlers. You can also add new .aspx files, which will be compiled normally on first request.

Which basically mean that you can hot fix a typo in HTML mark up, but that’s about it. No code changes at all!!! Consider this before you implement it in a corporate environment, where every change requires authorisation and deploying the new version of the entire pre-compiled web site is not an option outside of scheduled release process.