Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ambiguous type exception with AspNetBuildManagerTypeManagerTypeHandler #695

Open
wants to merge 1 commit into
base: dev
Choose a base branch
from

Conversation

ddprince-pro
Copy link

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:
image

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

… compiled at runtime. This fixes a bug where the resources are found in both the web site assembly and the global resources (ambiguous type exception).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant