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"
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".
HTH,Bob
Hi Dan, What are the values for "Application Mask" while registering a custom module. Where can i find a detaild information about this mask value?
Hi Dan, I am able to get values and the aslo the document as giben below.
Is this correct?
Yes, those are the values.
FWIW, you can use the "Custom Module Manager V2" that is delivered with the SDK while developing custom modules, which can be useful to keep track of what you have on your development machine. Please keep in mind that this is a tool for developers, not for "end users", so one of the tasks you will need to take into account for distribution of your customization is to account for the Windows Registry entries that this tool makes for you.
This is a newer version of the original "Custom Module Manager", but the purpose is the same, i.e. to create the necessary Windows Registry entries so that ProjectWise Explorer (or other application) will attempt to load your DLL at startup. Here's a slide from the ProjectWise SDK training that shows the necessary Windows Registry entries:
And just to be clear, here's the function prototype for the initialization function that you need to define as the value in "Function":
And the recommended way to implement it so that it is never called more than once at startup:
Thank you Dan. Is this the custom module manager V2 tool, what you are reffering, as shown in the image below?
You also mentioned that "ProjectWise SDK training". Where can I find the training class for PW SDK? It will be of much helpful. Thank you.