This is a reposting of an article I originally wrote on my Developing for Dynamics GP blog.
Today, I had a support case that was asking about errors when importing a package via Customization Maintenance (Microsoft Dynamics GP >> Tools >> Customize >> Customization Maintenance). The partner was unable to find an explanation of the errors on the Internet and so I thought I would explain what the errors mean and provide some best practices to avoid these issues in the future.
The error messages (shown in the screenshot below) included:
- Microsoft_Dynamics_GP Reference F:Program FilesMicrosoft DynamicsGPDynamics.vba: Error in loading DLL
- SOP Blank Invoice Form Modified Report Unable to resolve reference to Format ‘DiscountPercent’ by Report ‘SOP Blank Invoice Form’
The first message “Error in loading DLL” can be caused when a reference is made to a DLL file that cannot be found in a particular path, is not loaded on the machine or is not registered (with regsvr32.exe). It can also be caused when a reference is made from one VBA module (Dynamics GP product or dictionary) to another VBA module and the installation folder for the Microsoft Dynamics GP application is different. In our case the package was exported from a system with GP installed in the F:Program FilesMicrosoft DynamicsGP folder, but the target system is installed in the default C:Program FilesMicrosoft DynamicsGP folder.
The second message “Unable to resolve reference to Format” can be caused when a custom format has been manually added in the report writer and used on a report. The issue is that formats are not included in packages and so the format does not exist on the target system. In our case the format ‘DiscountPercent’ does not exist on the target system.
To fix the first issue, the reference between the VBA modules would need to be recreated manually on the target system using the Tools >> References… menu from the Visual Basic Editor. Another “unsupported” option is to use Notepad to edit the package file to change the path for the references to the correct path. Just do a find and replace on the path mentioned in the error message to change it to the correct path. If this was a DLL related issue, we would also need to make sure the DLL file was installed and registered on the target system.
Note: If editing the path in a package with Notepad, the blackslashes need to be doubled up as a single backspace is used as an “escape” character. For example: C:Program FilesMicrosoft DynamicsGPDynamics.vba should be C:\Program Files\Microsoft Dynamics\GP\Dynamics.vba in the package.
To fix the second issue, we could look at the “missing” format in the source system and manually add it to the target system before importing the package. We could also look at using one of the existing built in formats rather than creating a new one. We could change the format used and export the package from the source system again.
The Best Practices
So what are the best practices to avoiding issues like this causing problems. Here is a list that should help:
- Export References as individual packages. This way the references can be imported separately on the target system. Any that fail can be fixed by using one of the methods mentioned above. The benefit of having separate packages is that when one fails it does not prevent anything else from loading, which is what happens when the package contains other resources. Also importing references first on a target system ensures that they are in place before another package references them.
- Don’t export all customizations as a single huge package. There are three approaches to exporting packages:
- Export each resource as a separate package. This is fine for a system with only a few customizations, but becomes unmanageable with a system that has a large number of customized resources.
- Export each customization as a single package including all the related resources. So if a particular modification included a couple of forms and a couple of reports, you can group these as a single package for that modification. This only works if you know what resources belong to which modification.
- Export each Product and Type as a single package. For example all forms from Microsoft Dynamics GP, all reports from Microsoft Dynamics GP, all forms from Project Accounting, all reports from Project Accounting, etc. This way you can import the customizations back and if anything fails you can work with the smaller subset of the customizations to resolve the issues.
- Export packages for all the customizations and back them up. These can be used to restore the customizations by importing them back, if the customization is broken for any reason (“Oh, this little change to the code won’t harm anything…“).
- Backup all the custom forms and reports dictionaries and the *.VBA files. These can be restored if they are damaged or lost for any reason.
- If you are changing any “base resources” (formats, messages, strings, etc.) make sure you record the changes using a macro. This way the changes can be quickly restored if you every need to recreate the custom forms or reports dictionary.
- Backup the backup files from the points above. Another system is good, offsite is better.
Here endeth the lesson.
- How to use core Formats in a 3rd party report dictionary
- VBA – Adding Fields to VBA stops working
- Formats Not Exported to .Package Files (KB 851092)
This article was originally posted on the Developing for Dynamics GP Blog and has been reposted on http://www.winthropdc.com/blog.