Wednesday, 15 December 2010

ASP.NET (IIS) broken after installing updates

It looks like the recent Microsoft updates broke ASP.NET / IIS on my development machine.  Trying to launch any website hosted on my local IIS server returned a 500 error and the following error message: 

Calling LoadLibraryEx on ISAPI filter "C:\Windows\Microsoft.NET\Framework\v4.
0.30319\aspnet_filter.dll" failed 

And checking the event log just returned a similar error message: 

ISAPI Filter 'c:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet_filter.dll' could not be loaded due to a configuration problem. The current configuration only supports loading images built for a AMD64 processor architecture. The data field contains the error number. To learn more about this issue, including how to troubleshooting this kind of processor architecture mismatch error, see http://go.microsoft.com/fwlink/?LinkId=29349. 

After doing a bit of digging around on the web, the solution to this problem was to simply re-register IIS using the following command: 

c:\Windows\Microsoft.NET\Framework64\v4.0.30319>aspnet_regiis -r 

Everything then thankfully burst back into life!

Tuesday, 14 December 2010

Beware of Automapper modifying protected fields

I've just spent a good couple of hours trying to debug what appeared to be a corrupt session in NHibernate.  The unit tests would work, isolating the NHibernate code causing the problem worked, but within the application when calling Session.Save() the code always complained about a corrupt session.  Finally after much investigation and head scratching the problem was traced to an earlier call to AutoMapper.   This code was mapping an ID in the source to a UserID in the target - which had been correctly defined in the mapping file and worked without any problems.  What I had missed however was that AutoMapper was mapping the source ID to the "protected" target ID which NHibernate was using as it's entity key.  When using the entity directly you can't change the ID as it is protected (so it can safely stay under the control of NHibernates).  However automapper obviously uses reflection so passes the "protected" status of the property and in doing so was breaking referential intergity.  In the end all that was needed was to update the mapping to ignore / use destination value for the mapping of ID on destination.  Problem Solved.