Ambiguous type exception with AspNetBuildManagerTypeManagerTypeHandler

[ddprince-pro]

Hi,

This fix is only intended for version 4.2 update 1 of the Composite C1 CMS, so we will need to adjust the branch accordingly in order to complete this pull request.

We are currently working on a web site with that has this particular version installed of the CMS. We were able to convert from a Website to Web Application, but once this was done, a problem surfaced at runtime with the resources read from the XSLT files. These serves has "Function" inside the CMS and to my understanding are simple "parts" you can attach on a web site.

Each part that were asking for ressources were failing to render due to an error similar to the following:

My first though was that maybe the resources inside the folder "App_GlobalResources" aren't properly configured, so I checked and everything was OK as it's supposed to be:

• The "Custom Tool" is set to "GlobalResourceProxyGenerator"
• The "Copy to Output Directory is configured to "Do not copy"
• The "Build Action" is set to "Content"
• The namespace is rightfully set to "Resources"
• The designer files are there

Everything is normal. I even had created a brand new web application on the side, created the special folder App_GlobalResources, then created a Test.resx file and I obtain the same behavior. On both web applications, the resource type is compiled in both the web site DLL and in the dynamic DLL prefixed with the name "App_GlobalResources[...].dll". You can see that by using DotPeek to decompile the DLL.

I finally found the problem by debugging the Composite C1 solution with the web site I was working on and I found the responsible was the file AspNetBuildManagerTypeManagerTypeHandler.cs. It uses the static class BuildManager to obtain the compiled assemblies of the currently running one and by doing so, does not trap the problem with the ambiguous type. The fix I have done is hackish and really not what I was hopping for, but the only one I can apply. I've created a new project and decided to make it create an assembly name "UpgradePackage". Since Composite.dll has the attribute InternalsVisibleTo to that assembly, I was able to use the internal interface and override the behavior of that class. Then in the file Composite.config, the section named "Composite.Core.Types.Plugins.TypeManagerTypeHandler", I replaced the "AspNetBuildManagerTypeManagerTypeHandler" with my own implementation and it did fixed my problem.

But as you can see, it it far from perfect, so that it why I am proposing this change through a pull request.

Thanks