Paul Hadfield

Over the weekend I went along to the fantastic DeveloperDeveloperDeveloper day held at Microsoft up in Reading.  The quality of the presentations was fantastic and even for frameworks/subjects I was familar with I learnt loads.   For me, the most useful presentation came at the end of the day (just as the brain was beginning to shut down due to information overload).  Simon Sabin (from SQL Know How) presented "Things you should know about SQL as a developer".  
A snapshot of his presentation can be found on his blog, but for me the most enlighten point was the battle between reindexing a table and shrinking a database.   Typically the two feel like they should go hand in hand, but they will in fact fight each other.   Re-indexing a table will create a new copy of the table in question, with the data correctly ordered to reduce fragmentation.  As the original data is just marked as available, the process of re-indexing a table will potentially result in a database growing by…

By default objects mocked using MOQ will handle calls to method / properties that have not been defined, which 99% of the time will be the desired behaviour.  Occasionally however a situation will require that MOQ throws an exception when accessing a undefined method or property.  The MOQ framework provides this functionality via the MockBehavior enum but this can only be set during the construction of the mocked object.  Typically this won’t cause any problems as the mocked objects are created inline but we’ve just encountered a scenario that needed a little lateral thinking as for reusability we have objects that inherit from Mock<>.   These mocked objects already had constructor parameters which (in the short term) we didn’t wish to change so to get around this we created a static property on the mocked object that is then used to inject into the base MOQ constructor.public classMockHttpContext : Mock<HttpContextBase> { staticMockHttpContext() { MockBehavior = MockBehavior.…