Thank you for more information. I assumed that the assemblies that VS loads will be under a singe directory, from which the App_Web* assemblies would be missing. But apparently VS creates a temp directory for each of the assemblies, so this envisioned way of resolving things would not work.

Yes, the App_Web* assembly is missing from the modules list, because it could not be found&loaded, that is "expected", given what we already know.

Best regards

I am glad it works. Some notes:

1. It looks like that the module paths you have collected are *after* the assemblies were installed in the GAC. That's not really telling much in case we need to resolve it without the GAC in the future - it would have been more interesting to know where those assemblies that got loaded were loaded from when they were *not* in the GAC. And, for the GAC, the different paths you have listed are actually OK - that's how the GAC is structured. But no problem here, I just wanted to clarify.

2. Be aware that after the assemblies are put into the GAC, some things e.g. in Visual Studio will behave differently (and that's why it is not enabled by default in the QuickOPC installer). For example, Visual Studio will not copy the assemblies that are in the GAC to the output folder; which is OK, they are not needed there, because any target project will also find them in the GAC and does not have to have them in the output folder. BUT this assumption no longer holds when the user takes the output folder, thinking that that all necessary files are there, and copies it to a different computer where the assemblies might *not* be in the GAC. So some care need to be taken about "completeness" of the output folder - the customer should know about it.

Best regards

Hello,
well, this is quite an advanced scenario, and one that we have never tried.

Is this problem encountered right on the developer's computer, or is he deploying the ASP.NET control to a separate machine where it is then used in VS ?

Getting details of the exception (call stack, inner exceptions, ...) is usually possible by starting a second instance of Visual Studio and attaching it to the already running VS instance.

It is likely that one of the mixed-mode assemblies (those written in Visual C++) could not be located or loaded. In design mode, Visual Studio loads the assemblies from "who knows where" - I could never understand how precisely that works. So, it is possible (I have seen similar situations) that only the normal (C#) QuickOPC assemblies get copied to the temp location which VS then uses, and not the mixed-mode assemblies (App_Web*.dll). Inspecting the Modules windows while debugging the Visual Studio itself (using the 2nd instance as described above) should give the location where the "normal" assemblies are being loaded from - and then, one shoudl check whether the App_Web*.dll assemblies are also present at the same location.

Does, on the same machine, the same dialog work when *not* in VS design mode? If it does, the problem cannot be in Visual C++ runtime libraries, as they are machine-wide.

Can you (or the customer) try to install QuickOPC and select the "Custom" install, and then, when asked, select to install the QuickOPC assemblies into GAC? It might help. But, be prepared that if it does not help, you will then need to remove them from the GAC to prevent other issues - and that needs to be done either some Microsoft command-line tools, or by uninstalling the whole QuickOPC and then installing it without that choice again.

Best regards