ASP.NET Profile Compilation- Mystery Solved!

ASP.NET will kick off a little profile thingy when it finds a <property> section. It appears to go into the ASP.NET Temporary Folder. It seems to be a private method in ProfileBase that loads this.

Some errors that happen:
Sometimes deleting the <property> section and readding it works. This happens all the time for all sorts of reasons, not just profile related, but dynamic compilation and shadow assembly related.

ProfileCommon not available- this is supposed to be compiled either at design time, run time or sometime. It fails to work in a variety of circumstances.

Precompiled apps can have problems with the ProfileBase class
Ambiguous reference errors- can happen when App_Code.Compiled or PrecompiledApp.config exist or fail to exist and ProfileCommon gets compiled twice.
Similarly copying the bin of the new version into the bin of the old is bad. You get a blended set of .dlls
Deleting files in ASP.NET Temporary Files sometimes works.

Interestingly, all the above don’t seem to be addressable by writing a custom provider. It doesn’t seem possible to override the settings part, where it reads web.config and starts trying to create that problematic ProfileCommon.

Conclusion
It turned out to be a dll that was referencing a native dll that wasn’t on the PATH. The profile was just triggering a compile. The compile then check references for everything in the \bin\ folder, even if the profile or invoked page isn’t using it. Oddly, this doesn’t happen on every single page, so there are some code paths where ASP.NET doesn’t feel the need to recompile every !@#$@!#$ thing in the world. This, I suppose is good or else we’d see pathalogical compile churning.

I diagnosed this by watching the list of assemblies that were getting loaded in Visual Studio while the debugger was attached. If it couldn’t load symbols or if it was obviously a COM dll, I considered it a candidate and finally narrowed it down to a SMO library, which happens to have non-managed dependencies.

You think you’re doing tier architecture or business objects, but its just super pipelines and ziggurats.

Superpiplining. Methods that call methods that call methods do not magically add value along the way.

If one tier is bad, two tiers is better, why not n tiers (or layers), I mean, literally an infinite number of tiers, each adding zero value along the way. I call this patter “Super Pipelining” Super pipelining makes dependency tracing a pain. A typial super-pipelined application will still put all authorization, validation, calculations in the UI and pass System.Data or SqlClient objects back and forth the super pipeline.


class Customer() {
public void AddCustomer(Dto customer){ (new CustomerBusinessObject()).AddCustomer(); }
}

class CustomerBusinessObject() {
public void AddCustomer(Dto customer){ (new CustomerBusinessLogicObject()).AddCustomer(); }
}

class CustomerBusinessLogicObject() {
public void AddCustomer(Dto customer){ (new CustomerBusinessLogicDomainObject()).AddCustomer(); }
}

class CustomerBusinessLogicDomainObject() {
public void AddCustomer(Dto customer){ (new CustomerBusinessLogicDomainScenarioDatabasePersistenceObject()).AddCustomer(); }
}

class CustomerBusinessLogicDomainScenarioDatabasePersistenceObject() {
public void AddCustomer(Dto customer){ (new CustomerBusinessObject()).AddCustomer(); }
}

Ziggurat. A class that inherits from a class that inherits from a class that inherits from a class where the middle classes and the base don’t do anything. The classes in the middle do not magically make your code better.


class BusinessObject: BaseObject {}
class BaseObject: BasementObject{}
class BasementObject: UndergroundObject{}
class UndergroundObject: UbberBasementObject{}
class UbberBasementObject: SuperDuperBasementObject{}
class SuperDuperBasementObject: AceOfBaseObject{}
class AceOfBaseObject: China{}

Posted in c#

System.TypeLoadException: Method ‘CreateObject’ in type ‘Microsoft.Practices.EnterpriseLibrary.Validation.Instrumentation.ValidationInstrumentationListenerCustomFactory’ from assembly ‘Microsoft.Practices.EnterpriseLibrary.Validation, Version=3.1.0.0, Culture=neutral, PublicKeyToken=21a151ab59c9591d’ does not have an implementation.

I got the following error when using Enterprise Library 3.1. It mean it can’t find the reference to ObjectBuilder or it is resolving to the wrong version in GAC. So to use VAB, you need Common, ObjectBuilder and the VAB assembly. If not that then check this link.

System.TypeLoadException: Method ‘CreateObject’ in type ‘Microsoft.Practices.EnterpriseLibrary.Validation.Instrumentation.ValidationInstrumentationListenerCustomFactory’ from assembly ‘Microsoft.Practices.EnterpriseLibrary.Validation, Version=3.1.0.0, Culture=neutral, PublicKeyToken=21a151ab59c9591d’ does not have an implementation.