Custom Module DLL Registry Path

Hello,

I have a working Custom Module DLL with the Registry Path 

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Bentley\ProjectWise\10.00\CustomModules\Module_Name]

However, what I really need is an ability for a user to be able to make a registry edit on his own to use the Custom Module WITHOUT Administrator Access.

What I am really asking for is a registry path to be something like

[HKEY_CURRENT_USER\Software\Wow6432Node\Bentley\ProjectWise\10.00\CustomModules\Module_Name]

Is there any such place that ProjectWise looks to load this .DLL?

Thanks!

  • You should be able to create the registry entry if you create an .msi file to install your customization.  You might try http://wixtoolset.org/ 

    Here's  a sample of something I did a while back to create the registry entries:

        <!--****************************************************************************************************-->
        <!--~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Registry Entries~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~-->
        <!--****************************************************************************************************-->
    
        <DirectoryRef Id="BENTLEY.PROJECTWISE.PWPATH">
          <Component Id="$(var.PROJECTNAME)Reg" Guid="81C62924-7788-4D1A-B5E6-9FAEE8B3AE44" KeyPath="yes">
            <RegistryValue Id="PWCCEReg11" Root="HKLM" Key="SOFTWARE\Bentley\ProjectWise\08.11\CustomModules\$(var.PROJECTNAME)" Name="ApplicationMask" Value="1" Type="integer" />
            <RegistryValue Id="PWCCEReg12" Root="HKLM" Key="SOFTWARE\Bentley\ProjectWise\08.11\CustomModules\$(var.PROJECTNAME)" Name="Library" Value="$(var.PROJECTNAME)SQ.dll" Type="string" />
            <RegistryValue Id="PWCCEReg13" Root="HKLM" Key="SOFTWARE\Bentley\ProjectWise\08.11\CustomModules\$(var.PROJECTNAME)" Name="Function" Value="CustomInitialize" Type="string" />
    
            <RegistryValue Id="PWCCEReg14" Root="HKLM" Key="SOFTWARE\Bentley\ProjectWise\08.09\CustomModules\$(var.PROJECTNAME)" Name="ApplicationMask" Value="1" Type="integer" />
            <RegistryValue Id="PWCCEReg15" Root="HKLM" Key="SOFTWARE\Bentley\ProjectWise\08.09\CustomModules\$(var.PROJECTNAME)" Name="Library" Value="$(var.PROJECTNAME)SQ.dll" Type="string" />
            <RegistryValue Id="PWCCEReg16" Root="HKLM" Key="SOFTWARE\Bentley\ProjectWise\08.09\CustomModules\$(var.PROJECTNAME)" Name="Function" Value="CustomInitialize" Type="string" />
    
            <RegistryValue Id="PWCCEReg17" Root="HKLM" Key="SOFTWARE\Bentley\ProjectWise\10.00\CustomModules\$(var.PROJECTNAME)" Name="ApplicationMask" Value="1" Type="integer" />
            <RegistryValue Id="PWCCEReg18" Root="HKLM" Key="SOFTWARE\Bentley\ProjectWise\10.00\CustomModules\$(var.PROJECTNAME)" Name="Library" Value="$(var.PROJECTNAME)SQ.dll" Type="string" />
            <RegistryValue Id="PWCCEReg19" Root="HKLM" Key="SOFTWARE\Bentley\ProjectWise\10.00\CustomModules\$(var.PROJECTNAME)" Name="Function" Value="CustomInitialize" Type="string" />
          </Component>
        </DirectoryRef>
    

    The only place (that I'm aware of) that ProjectWise (via the aaApi_Initialize() function in the SDK) will look, is in the appropriate registry location based on ProjectWise version and "bitness".  You can use the Custom Module Manager during development, but since all the custom modules that I have built, or have seen others build, are 32-bit, then on a 64-bit OS, then these have to be in a location like you first mention.  Of course, in your installer, you need to check to see if the target OS is 32 or 64 bit and target the correct registry location.  

    Answer Verified By: James Kennedy 

  • Thanks for the answer, I will accept this, and then try this for myself. 

    The idea is to be able to allow an install of my custom module, that requires hooking during the drag and drop step, without needing administrator rights. My other custom modules don't require hooking so I can install as I please and call them from an MRR file.

    This one on the other hand has become quite annoying in dealing with installation among the users.

    I know my feedback may not matter much, but the add ons I have written for document uploading and database table management have gone out to many users through a variety of ways of deployment.

    I would suggest there to be an alternate "public" loading path from the bin folder, perhaps a setting in the user's ProjectWise could allow that. I know it's very easy for me to say that and very difficult for you guys to implement.

    Maybe you know of a workaround where I can keep my custom modules and mrr files out of the bin folder of ProjectWise, yet still have them loaded.

  • James,

    As I like to say, "words get in the way".  I'm not 100% sure of what you mean by several of your comments.

    As for "without needing administrator rights", that's an OS requirement, not a ProjectWise requirement, but you have to address it one way or another.  This is similar to having write access to the directories to where you copy your DLLs and MRR files to, that's an OS requirement not a ProjectWise requirement.

    As for "an alternate 'public' loading path", that already exists, you just specify the full path to your DLLs.  If you mean for .MRR files, that's a "WAD" and the .MRR files must be in the ProjectWise "bin" directory or ProjectWise Explorer will not find them on startup.

    Some background..

    "Custom Module" in the PW sense means a DLL that gets loaded by ProjectWise at startup in a specific way.  DLLs loaded when referenced by entries in .MRR files, aren't considered (in the ProjectWise world) to be "Custom Modules". 

    The mechanism to load Custom Modules is defined by the design of ProjectWise and implemented by the function aaApi_Initialize().  That's a "WAD" and it requires entries in the Windows registry in a specific location (based upon version of ProjectWise and "bit-ness"), as well as specific keys, sub-keys and values.  The "public" way of creating those entries in the Windows registry are defined by Microsoft and you can create installation programs to "get around" the requirement of being an OS Administrator to create, modify or delete them.

    As for the location of the DLLs themselves, they can be "anywhere", but the general recommendation is to put them in the ProjectWise "bin" directory for a number of reasons.  If the DLLs are not in the "bin" directory, then you need to include the full path in the .MRR files or in the Windows Registry entries.  However, the only place ProjectWise Explorer will look for .MRR files is in the ProjectWise "bin" directory.

    I suggest that you adopt creating installation packages for your customizations.  Microsoft installer technology allows you to deal with updates and fixes as well as deployment (installation) issues.

    HTHs

  • Hey Dan,

    Thanks for the follow up and providing me more information.

    The major issue as you might have guessed is that I (deployer) of ProjectWise Custom Modules have no real way of getting what is needed into the installation package. If I had control of that then I could easily have my DLL/MRR/Regedits/etc placed in the needed paths, ran, and be done with it. 

    The way I am able to cope right now is to generate requests to system admins to do what they need to do to get the ProjectWise Module up and running. So far this is not too big of a deal, but I predict that in the near future (3 to 4 months) I'm going to be generating large scale requests to get the DLL/MRR/Regedits/etc into place. When that happens I'm sure I'll figure out someway with the admins to get it all deployed, so no big deal.

    I do have an additional question on the MRR File, I assume I can add menu commands via the API right? That way I could avoid needing an MRR file.

    Thanks,

    James

  • Yes, you can add menu items via API calls.  Take a look at the MyMenu sample provided with the SDK.

    As for not being able to get what you need into an installation package, that's what tools like "wix" are for.  You can create a Visual Studio project that builds your installation package, which means you can control what is included, what it does, and how.  Now getting your system admins to accept your installation package (.msi file), that might be an issue, but if they trust you to create valid ProjectWise customization, then why would they not trust you to create a valid installation package?