I created a mrr that adds a new top level menu to ProjectWise and a dll that provides some simple functionality and state-checking for the menu. Basically, if the user is in the correct group they can launch a standalone application.
The mrr is pointing to the correct dll and functions. I know this because it works perfectly on my computer and have tested it on a coworker's computer as well. We both have visual studio and the ProjectWise SDK installed.
When I deploy the dll and the mrr to the projectwise/bin of a user, the top level menu appears as is desired. However, the problem is that the menu items in the top-level menu do not work. The state-checking isn't denying the user access and when clicking to launch the standalone application nothing is launched. After reviewing the documentation, I believe this should be possible by just deploying the dll and mrr, but it isn't working.
I'm not sure what I'm missing here and appreciate your help!
"Pictures would help!" What do your entries look like in the .mrr file, etc.?
I suspect that it "works" on your box because ProjectWise Explorer can find the DLL and load it. I suspect that it doesn't work on other boxes because the .mrr file either has no path for the DLL or the path isn't where the DLL is.
The "best practice" is to put your custom modules in the "bin" directory where ProjectWise Explorer is located AND not specify a path in the .MRR file. If no path is specified for the DLL in the .MRR file, then ProjectWise Explorer assumes that the DLL is in the same directory as pwc.exe. Since you mention that this works on two machines that both have Visual Studio installed, then I suspect that you have the path to your debug directory specified in the .MRR file, but I could be wrong since I'm just guessing.
There could be other reasons as well, but this is the most common one. Post detailed information about the contents of your .MRR file as well as which Windows directories you are placing your DLL and MRR files into, etc.
This is one of the many topics covered in the PW SDK training class that I teach from time to time. A common developer "solution" is to always create your .MRR files without a path, and then in your post-build events, copy the .MRR and DLL files from your source/debug directories, to the ProjectWise "bin" directory and then you don't have to remember to modify the .MRR file that you eventually deploy to machines without Visual Studio or your source on them.
HTHs
Here's a snapshot of one of the mrr entries. The rest are similar to this one.
I have been placing the MRR and the DLL in the same folder (the ProjectWise "bin" directory) so this should not be the issue. It is specifically the C:\Program Files (x86)\Bentley\ProjectWise\bin folder.
I'm assuming that you are using a version of ProjectWise CE. Looking at your .MRR file, the next most common reason why a command "doesn't work" is because it hasn't been exported from the DLL, but since you said that it works from two machines (with VS on them), obviously then you would have had to export those functions for them to work on those machines.
So, perhaps something different about the machines where it works and where it does not? What about dependencies? What version of Visual Studio are you using? Somethings VS will use some dependencies that are not necessarily on the end user's machine.
One common programmer's error is to build and test C++ code in Debug mode, and then deploy it to machines that don't have those "special" debug DLLs on them. That could be the reason. Did you build a Release version for the machines that don't have VS on them?
Also, sometimes it is a difference between the OS user running the software or the ProjectWise user who is logged into the datasource. And sometimes the OS itself. What OS is being used for these machines?
Can we assume that the OS user running ProjectWise Explorer has read access to the DLL in the ProjectWise bin directory?
What about your code's logic? You mention " if the user is in the correct group they can launch a standalone application". Well, is the user in the correct group who is running on the machine where your customization doesn’t work? Does your code provide any error messages or other feedback if the user isn’t allowed the command?
If you post your code for the GenCmd_LaunchPlanVault” function, and its state function, then perhaps I might spot something. If this is “sensitive” code, you can send me a private email and let me know where I might be able download a copy of these functions, and I’ll try to take a look to see if there’s something obvious.
Otherwise, I don’t have an explanation for why it works on two machines (with VS) and not on other machines.
Answer Verified By: Jacob Henkel
What method are you using in your menu function to launch your application, and how are you invoking the application? I saw one case a while back where the method being used required elevation to execute the application (I just can't recall what that method was unfortunately). There was no error feedback nor a visible request to elevate, it just appeared not to do anything. It worked for me because I had admin rights on the machine I was using, whereas the user trying to use my DLL did not have the same privileges.
To expand on Dan's point about dependencies, if you are using MFC in your code and you have your project set to compile using shared MFC library, you would need to install a proper SxS supporting MFC DLL on the other machines that do not have VS installed. The easiest way to eliminate that overhead and potential pitfall is it to compile the project to include (not share) the MFC library. It will increase the size of your DLL, but it would certainly simplify your client install setup if you are using MFC, and eliminate that as a possible cause of the problem.
The issue was that I was building the dll in Debug mode. After switching it over to build and deploy in Release mode the user computer had full functionality in the menu. Thanks for the help!