in

ASP.NET Weblogs

This Blog

Syndication

Lists/Forums/Etc.

Samer Ibrahim's Blog

The Samer I Warrior on battles with .NET

May 2004 - Posts

  • Odd behavior in ASP.NET

    So after wasting about an hour and a half debugging why in the world I kept getting an invalid cast exception, I discovered a quirk in the way ASP.NET loads assemblies.  Apparently, the .NET framework loads everything in the \bin directory that even looks like a DLL.  For example, if you have a file called DLL_ the framework will load it anyway.  Why the hell it does this I don't know!!!  It's not even a DLL for God's sake!

    Now you might be wondering why in the world I have a file called DLL_ sitting in my \bin directory but that's easy to explain.  Sometimes I want to use a different compilation of a DLL that might contain something like more debugging code, for example, in my ASP.NET application.  So instead of moving or overwriting the old version or recompiling my application or even changing which version is redirected to what other version in the config file, I simply change the old DLL to DLL_ or something of the like and drop the new DLL in the \bin directory along side of it.  Seems harmless and should work and in fact it does when .NET isn't being stupid and just loads DLLs. 

    I spent all this time trying to figure out this problem, changing the code I was debugging over and over again, and when I finally said what the hell let me see what the code base is for DLL which contains the class I'm trying to cast to, I saw that it was <Path>\SomeAssembly.DLL_.  This is a bug as far as I'm concerned.  And as far as I can tell, there is simply no application for this type of behavior so I'll just call it retarded.

    By the way when I say ASP.NET, I'm working with SharePoint specifically.

  • More Training... this time on SharePoint

    So after my complaining about SharePoint documentation you might be wondering how to get some good SharePoint training.  Well the answer is pretty clear cut.  You get training from Barracuda.NET, a company run by Ted Pattison and Jason Masterman both former DevelopMentor guys.

    I've been going through their training now but it's clear that they not only wrote a very good training program but are determined to answer all your questions even if that requires offline research.  I think this is a quality that is very admirable and is one reason I feel you'll get your money's worth.

    Personally my only problem with the class is I think the pace is too slow but I think that has to do with the diversity of the talent pool within the class.

  • AssemblyResolve event of an AppDomain

    I got a comment from a gentleman by the name of Anthony DeRosa asking for more details relating to how to load an assembly from a network location from my earlier post regarding the GAC.  So even though I found that this is addressed elsewhere when I googled for it what the heck another entry won't hurt anyone.

    Let's start with the Assembly.LoadFrom method which most people are familar with.  One can easily load an assembly from a network location just using that method alone which may solve most people's problem.  But what if you want to be able to only load the assembly from a location if the .NET framework can't find it on it's own or you need some other algorithm to locate assemblies.  Little known to most people, beyond just the simple probing and checking of the GAC that .NET does, there is an event fired before the framework gives up on loading your assembly.  The event is AppDomain.AssemblyResolve.  You can subscribe to that event and do a simple Assembly.LoadFrom from a location known to you or even do some fancy loading of your own based on some system you engineer.  There are also TypeResolve and ResourceResolve events in the AppDomain that let you handle those aspects of resolving the various dependencies of an AppDomain.

    Of course if you are loading an assembly off the network you need to make some CAS changes.

    Just Googling for resources I found these:

    Also just as an FYI, there is also a ModuleResolve event of an Assembly.

More Posts