Edit and debug content created in Visual Studio

This scenario deals with cases where you created a form or user display using Visual Studio, and then uploaded this form in the Display Editor of the Proficy Client.

Before you begin

Procedure

  1. Locate the required files.
    In order to debug your form, the following files are required:
    • The source code for your forms.

      In this scenario, the source code should be found somewhere on your system; it is not persisted in the Workflow database.

    • The symbol files for the form.

      There is one symbol file for each project you created, and symbol files are needed only for the assemblies that you need to debug into.

      Tip: Symbol files match the file name, but have a .pdb extension instead of .dll, and are found in the same folder where the .dll is built to. As the .dll is rebuilt, so is the .pdb, so these files must match each other in order to debug properly.
  2. Make the .PDB files available to the Client for debugging.
    This can be done in one of two ways:
    • Copy the .pdb files that correspond to the form assembly and dependencies to the My Documents\Proficy Workflow\UI Assemblies\ folder on the machine on which you want to debug the form.
      • When you are finished debugging the form and are ready to run in production again, delete these files from the My Documents\Proficy Workflow\UI Assemblies\ folder; otherwise, the symbol information will continue to be loaded each time the form is loaded.
    • Add the .pdb files as additional files in the Display Editor in the Workflow client. This automatically copies the file to the My Documents\Proficy Workflow\UI Assemblies\ folder for all machines when they try to load this form.
      • When you are finished debugging the form and are ready to run in production again, remove this as an additional file in the Display Editor. Be aware that this file will remain on any client machines that have already downloaded it, so you must also manually delete the file from the My Documents\Proficy Workflow\UI Assemblies\ folder. Otherwise, the symbol information will continue to be loaded each time the form is loaded.
  3. Open the project code using Visual Studio.

    Open the code files you want to debug into and set your breakpoints by clicking in the extreme left margin. Putting a breakpoint in the constructor of your form is a good idea in order to test a breakpoint being hit.

  4. Launch the Workflow client if it is not already running.
  5. In the Debug menu of Visual Studio, select Attach to Process, and then select ProficyClient.exe.
  6. Load the form in the client.

    Generally, you will do this by running a workflow that has this form specified in a form activity. When the form is loaded into the Task List on this machine, you should see your breakpoints being hit in Visual Studio. Alternatively, you can select the form in the navigator, and open it in the Global Viewer. However, in this case no parameters will be passed into your form as they may be from a workflow.

  7. Stop debugging.

    Debugging this form should provide some information about what is going wrong. Before you make any changes, however, you must first stop debugging. Use the Debug menu in Visual Studio to stop debugging, and then make your code changes, save your changes, and recompile.

  8. Reload the assembly.

    Now that the assembly has changed, go to the Display Editor in the Client and upload the new version of the assembly. In addition, if you had added any additional files (including .pdb files), make sure you remove and re-add these to reflect the latest versions. If you had not specified .pdb files in this manner and had only manually copied them to the folder, you must copy them again to the My Documents\Proficy Workflow\UI Assemblies folder if you want to continue debugging.

  9. Remove the symbol files.

    When you are finished debugging, review Step 2 for instructions on removing the .pdb files when they are no longer needed.