What gets used in the first step I listed is "AppDomain.CurrentDomain.BaseDirectory" (docs.microsoft.com/en-us/dotnet/api/system.appdomain.basedirectory?view=netframework-4.8 ). I suppose that is what you meant.

It might work - please print out the above value from inside the Web app to check if it points where you want it to... and if so, you can try place the Certificate Generator there (and disable the prerequisite boxing).

Regards

I understand the security concerns.

What wanted to say that just installing the UA Certificate Generator wouldn't help by itself. But it should help together with disabling the prerequisite boxing, as per instructions (kb.opclabs.com/How_to_disable_prerequisites_boxing ). Note that the XML fragment will have to go to the .config file for the process - which might the IIS app pool executable.

If you install one of the OPC Foundation setups that include the UA Certificate Generator, QuickOPC should find it.The search is done inside the SDK (which we cannot easily change and is one of the contributing factors to the necessity of all these workarounds). By briefly looking at that algorithm, it looks like that it searches:

1. "Opc.Ua.CertificateGenerator.exe" in the base directory of the current AppDomain.
2. "Bin\Opc.Ua.CertificateGenerator.exe" under the current directory (of the process).
3. Repeats Step 2 for parent directories until the root is reached.
4. "OPC Foundation\UA\v1.0\Bin\Opc.Ua.CertificateGenerator.exe" under CommonProgramFiles.
5. As Step 4 but with " (x86)" added to the CommonProgramFiles directory.

Best regards

What actually happens under the hood is more complicated. It is, in fact, very complicated - outside the scope of this forum. I'll try to simplify it somehow: The QuickOPC needed, in this case, to create an application certificate, which is done by executing the Certificate Generator utility from OPC Foundation. The utility can be installed on the computer - but that would requite you to manually do it. In many common scenarios, we allow this extra step (installation Certificate Generator) of be skipped, by using the "boxing". The boxing can, among other things, "pretend" to the application that certain files exist in certain directories - even if they physically don't. So many times, we can place a binary image, a "virtual" Certificate Generator onto the directory where the OPC UA stack/SDK expects it, and it will be found and executed. But, for executable files to be run, this is not supported when the bitness of the file differs from the bitness of the process. The OPC UA Certificate Generator is a 32-bit app, and therefore when your process is a 64-bit process, the boxing cannot work as described above. In such case, we make one more attempt to avoid the need of preinstall: We try to find a place in the physical file system and make a place a copy of the Certificate generator there. This is done by trying various temporary directories used by the system.

[Edited later: Actually it is not the Certificate Generator that is placed into the physical temp directory; it needs to be in a specific location. What gets placed there are parts of the "boxing" library.]

Under environments with tightly controlled security (like IIS), finding the right directory may fail. What QuickOPC should do, in case it finds that the temp directory exists but cannot be accessed, is to silently proceed to the next directory in the list. There appears to be a bug currently, and that's why you have received the exception. I have made a note and we will fix the bug in the next version. But even if the bug wasn't there, other temp directories are likely to be inaccessible as well, so the boxing attempt will probably fail anyway.

To sum it up, using IIS with OPC UA stack is a challenge. One possible solution is to install the UA Certificate Generator manually (but given the presence of the bug, this won't probably help right now). Other solution is to give the necessary IIS identity access to the temp directory/directories. The first one that QuickOPC currently tries to use is the current user's temporary folder, as returned by the Path.GetTempPath method: docs.microsoft.com/en-us/dotnet/api/system.io.path.gettemppa...d%3Dtrue&view=netframework-4.8 . I believe that "current user" in the IIS context means the identity you selected under the "Process Model" category.

Best regards

Hello.

This appears to be related to prerequisite boxing - see opclabs.doc-that.com/files/onlinedocs/QuickOpc/Latest/User%2...ml#Prerequisites%20Boxing.html .

You can try to:

1. Give the application pool identity access to the path indicated in the exception

System.UnauthorizedAccessException: Access to the path 'C:\Windows\TEMP\bxsdk32.dll' is denied.

2. Disable prerequisites boxing: kb.opclabs.com/How_to_disable_prerequisites_boxing

Best regards