Errors when importing Customization Maintenance Packages


David Meego - Click for blog homepageToday, 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 Errors

The error messages (shown in the screenshot below) included:

  1. Microsoft_Dynamics_GP  Reference  F:\Program Files\Microsoft Dynamics\GP\Dynamics.vba: Error in loading DLL
     
  2. SOP Blank Invoice Form  Modified Report  Unable to resolve reference to Format ‘DiscountPercent’ by Report ‘SOP Blank Invoice Form’

 

The Causes

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 Files\Microsoft Dynamics\GP\ folder, but the target system is installed in the default C:\Program Files\Microsoft Dynamics\GP\ 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.

The Solutions

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 Files\Microsoft Dynamics\GP\Dynamics.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:
  1. 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.
     
  2. 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.
     
  3. 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.

David

Related articles:

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)

Comments (7)

  1. David, thanks for your post.  I wish the Customization Maintenance window allowed the user to export each object as a separate file, all at once.  So by selecting 10 objects, it would output 10 files all with different names.  It would have to do some de-duplicating of names when there are multiple versions (maybe use resource ID and technical name?), but that would make it a lot easier to put these changes in source-safe.  

    David, you've inspired me to post a product suggestion.  I invite all your readers to vote for it here:

    connect.microsoft.com/…/gp-customization-maintenance-exporting-multiple-files

  2. Steven Vallarian says:

    To add to this, the one we run into all the time on terminal servers is

    "Unable to open customizations dictionary".

    This is caused by one of two things:

    We forgot to rename the addins folder before importing the package

    or

    Someone is still logged into the terminal server and running GP

    We got around the first one by writing a batch file that makes a directory with today's date on it, then copies the contents of the addins folder, the modified forms/reports dictionaries, and all of the vba files. It then renames the addins folder and starts GP. Once we've imported the package, we close GP and the batch file renames the addins folder back to what it needs to be.

  3. David Musgrave says:

    Hi Steve

    I have not heard anything about the addins folder causing issues with importing packages.  Do you have any custom addins created with Visual Studio Tools that access modified forms dictionary assemblies created by DAG.exe?

    David

  4. David Musgrave says:

    Hi Ron

    It would be nice to have the ability to multi-select and then decide how you want to export.  A little like the Exporting ability inside Dexterity. Good idea to add a product suggestion.  That is what I would have told you to do. 🙂

    David

  5. Patrick Roth [MSFT] says:

    The issue of importing packages has been fixed for a long while.  I believe that was a 9.0 issue and fixed in 10.0 if i recall correctly.

  6. Patrick Roth [MSFT] says:

    I should clarify the last response.  To be clear, what I meant to say was "The issue of importing packages _with vstools customizations loaded_ has been fixed for a long while."

  7. David Musgrave says:

    Posting from Mark Polino at DynamicAccounting.net

    msdynamicsgp.blogspot.com/…/errors-when-importing-customization.html

Skip to main content