Ambiguous type exception with AspNetBuildManagerTypeManagerTypeHandler #695
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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:
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