I have a module that needs to be compatible with DNN 5.2 to 7.0. DNN 5.x is compiled against .NET 2.0, DNN 7.0 against v4.0 of the framework. The module references a copy of DNN 5.2 and is now compiled against .NET v4.0.

The module works fine on DNN7 as expected. It also runs on older versions of DNN. However, at one point, there is one piece of code that is not working on the older versions. I have a method that returns the Guid of the assembly:

 private static Guid GetApplicationUid() 
{ 
       Assembly assembly = Assembly.GetExecutingAssembly(); 
       GuidAttribute attribute = (GuidAttribute)assembly.GetCustomAttributes(typeof(GuidAttribute), false)[0]; 
       return new Guid(attribute.Value); 
}

The method fails with an "Index was outside the bounds of the array." exception. The reason for this is that when the module is compiled against a .NET version other than the one the current application is executing against, the assembly reference created by GetExecutingAssembly() is to a temporary assembly rather than the underlying "real" one.

How do I configure the site so that this doesn't happen? Can I use assembly redirection for this? Alternatively (and preferably), is there a way of always getting a reference to the real assembly, even when .NET generates and executes a temporary one, as in this case?

I was surprised too, but it does. Originally, the module was built against 2.0 and yes, then it works for DNN 5 and 6. However, the same issue with the temporary assembly then occurs when running on DNN7. I decided to build it against .NET 4 simply because it solves the problem on DNN7 and I expect that to be the majority platform going forwards. But any solution that works for all versions will do me.