Hello,
OS: Win XP.
Here is my situation. I have a browser based application. It uses ASP.NET. Programmers can build custom controls for ASP.net (aspx) in the form of DLL files.
Previously, our architecture was HTML/XSL -> aspx -> proprietary middle tier -> aspx catches response from middle tier in XML format -> xsl.
Our "Systems Engineer Senior" has decided to spawn DLL files from all of our XSL pages (many of which have duplicate names) upon building a new instance of the website and have the asp.net pages (ASPX) call a custom control via the DLL. New architecture: HTML/XSL -> aspx -> proprietary middle tier -> aspx catches response from middle tier -> aspx page invokes a custom control imbeded in a DLL file. The custom control acts as a substitute for the XSL page.
This has created a "known issue" in which ~200 DLL naming conflicts occur and, thus, half of our application is broken.
I think a solution to this problem is that, thankfully, we're generating the names of the DLLs and linking them up with our application dynamically. Therefore we can do something kludgy like generate a hash and append it to the end of the DLL file name when we build our website, then always reference the DLL that had some kind of random string / hash appended to its name.
Aside from outright renaming DLLs, is there a way to have multiple DLLs with the same name register for one application? All these DLLs are "wrapped" in an application that hosts the web site, not registered. I think the answer is "No, only between different applications using a special technique." Please confirm.
Another question I have on my mind is whether this whole idea is a good practice -- converting our XSL pages (which we use in mass -- every time a response from our web app occurs) into DLL functions that are called by an ASPX page as a "function" to do what the XSL page did in the first place, when before the ASPX page was just sending an XML response to an XSL page.