Is there a diagnostic log or other evidence I can look for to determine why a ProjectWise custom module DLL is not loading successfully?
It seems to load successfully when DLLs are stored on local C: drive, but not when stored on a network share folder. One theory we have is that a Windows security setting might be preventing pwc.exe from loading a DLL from a network location.
Also, is there any way to configure/control whether or not (or when) a custom module DLL is loaded by the client application?
Thanks.
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Bentley\ProjectWise\08.11\CustomModules]
Jay,
Can you please post the specifics of your registry entry? i.e. what are the values for Application Mask, Function, and Library?
As for your question about controlling whether or not a custom module DLL is loaded or not, yes you can. In your initialization function, just return IDOK to keep it loaded, returning anything else and it will be unloaded.
Typically it is easier to always load the module, but implement a post login hook to determine what, if anything in the custom module applies to this datasource, this user, this location, etc. Obviously, you can implement whatever rules you want and how to enforce them. Typically I have one or more "global" boolean flags and then check it before attempting some specific command or action to determine if my code should do the custom behavior or just the default.
HTHs
Sure can, though I don't know how it would help.
When at this location, the DLL loads successfully (we see the custom menu items it adds):
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Bentley\ProjectWise\08.11\CustomModules\PWP6_DwgRegister]
"Application Mask"=dword:00000001
"Function"="CustomInitialize"
"Library"="C:\\BV-Users\\Bentley\\PWP6_DwgRegister\\PWP6_DwgRegister.dll"
But when at this location, the DLL does not load (or at least we don't see the custom menu items that the DLL should be adding):
"Library"="W:\\PWP6_DwgRegister\\PWP6_DwgRegister.dll"
I assume that the Windows user running ProjectWise Explorer has access to the file and the path exists. You mention "custom menu items. If you are using an .mrr file, then those get loaded when the menu item is about to be displayed and don't have to be in a "custom module", i.e. the registry entries are not used, as the location of the DLL is in the .mrr file. If you are using the PW APIs available for menus, then it has to be a custom module and have the correct Window registry entries. I've seen this happen when a developer uses a custom module for part of their solution and an .mrr file for the menus. Then when deploying the solution, they only change the path in either the Windows Registry, or in the .mrr file, but miss one or the other location. The recommended approach is to always put the custom DLLs in the ProjectWise bin directory and only provide the name of the file in the .mrr file and/or in the Windows Registry as PWC.exe will always assume that the files are in that location if no path is provided. Yes you have to place the DLLs on each machine, but you have to place the .mrr file on each machine or create the necessary Windows registry entry on each machine, so you have to "touch" each machine either way.
Jay E,
OK, I did a quick test on "my box", a machine running Windows 10 Enterprise, PWCE v10.00.02.203 client, and PWCE SDK v10.00.01.67, using Visual Studio 2010, and I notice a few things.
\\naou11373\SharedDLLDrive\DLLS\MyHooks01.dll
So, not using mapped network drives all that often, and not in this manner, I can't say why it "works" for me and not for you. What OS are the machines running and what version of ProjectWise Explorer and SDK are you using?
You might try using the "network" path instead of a mapped drive and see if that works for you, but it looks like you will have to manually edit the registry and not use the custom module manager x86.
Unknown said:Machine A, Library=W:\PWP6_DwgRegister\PWP6_DwgRegister.dll (network located DLLs) --> load fails
Is the custom module type Native (C/C++) or Managed (.NET) code?
If Managed and attempting to load .NET assemblies you will need to follow Microsoft recommendations and set Assembly trust via CasPol.exe and/or using the application .exe.config <loadFromRemoteSources> property. A typical implementation example is posted here ([V8i VB.NET]Running AddIn from network location.).
For additional debugging of Native and Managed Microsoft .NET assembly load issues consider using one or more of the following helpful tools; listed in order of complexity and verbosity:
HTH,Bob
Unknown said: I Used the control in Windows File Explorer to map drive 0: to a share. However, I cannot browse to drive o: using the custom module manager (x86). A "dir o:\" command at the CMD window prompt doesn't work either!. Windows Explorer does show the share as drive "o:" under "Network locations" and I can browse to it using Windows Explorer.
Just as we have all had to learn and adopt to various Windows security improvements; like: Standard and Elevated, Local Administrator and Trusted Installer - users, Remote Desktop User, Application/OS bitness, Virtualized processes, ...; add one more prominent item elevated in Windows 10 though present since Vista.
Windows 10 "Integrity levels" (see: What is the Windows Integrity Mechanism?) are more strict than previous versions (even though most everything was present since Vista). e.g. If you are an administrator and you map a network drive in Windows Explorer (medium integrity) and the proceed to open an Admin command shell (high integrity) you will not see your "user" (medium integrity) mapped drives. Unless you start a process using Run As Administrator explicitly then child processes are likely to inherit medium integrity levels. You can check your Local Security Authority (LSA) privileges from an appropriate command shell integrity level by running: whoami /priv. Also note that you can use Microsoft Process Monitor (procmon) to help identify most access/permission issues by filtering on "access".