Hi All,
This is the Second Post in the Series. If you haven't read the earlier post please refer the Index of the Post.
Below are points to Note About Application Merge Utilities, which will help you while Using the related Cmdlets.
Object Types supported by the Application Merge Utilities
The following object types can be merged using the new cmdlets:
• Tables
• Pages
• Reports
• Codeunits
• MenuSuites
• Queries
• XMLPorts
The following object types cannot be merged:
• Dataports
• Forms
• Reports with Classic report sections
So This tool cannot help us with Reports with Classic. This is one challenge that we will have during Upgrade from Version Lower than NAV 2013.
But i would say its still a great tool which should reduce the Upgrade Time Drastically if used correctly. You will find same in Other Post in this series.
Special Handling Required The application merge utilities handle all object types, but some better than others. Also, some parts of some object types require special attention from the tool or from you as described in the following list:
• Application object properties
(Discussed in How to Use - GET & SET NAVApplicationObjectProperty)
Each of the application object properties in the application object files often calls for hands-on handling. You can run the cmdlets with the default parameters values, but you can also overrule the default behavior by setting parameters specific for application object properties, or you can run other cmdlets for post-processing.
Two cmdlets are available specifically for post-processing: Get-NAVApplicationObjectProperty and Set- NAVApplicationObjectProperty.
• Documentation triggers (Discussed in How to Use - Merge NAVApplicationObject)
In each object, the documentation trigger is used for many different purposes. Documentation, of course, but also for tracking changes with date or history semantics built into it. You can use the cmdlets to modify the contents of the documentation section.
• ControlID (Discussed in How to Use - Merge NAVApplicationObject)
Sometimes, developers in-house or external partners create objects in the same ID range as you. This surfaces in the merge process as conflicts and hence as work to do. The application merge utilities provide ways to handle that, depending on your needs and requirements.
• CaptionML
Captions are an integral part of the solution, but when you compare two versions of the same object with two different languages, you will see extensive differences. Microsoft plan to add support for handling captions as part of the application merge utilities in a later version. However, you can choose as a temporary workaround to export captions to an external file during the application merge.
http://msdn.microsoft.com/en-us/library/dn479852(v=nav.71).aspx
Stay Tuned For More.
Regards,
Saurav Dhyani
saurav-nav.blogspot.com
This is the Second Post in the Series. If you haven't read the earlier post please refer the Index of the Post.
Below are points to Note About Application Merge Utilities, which will help you while Using the related Cmdlets.
Object Types supported by the Application Merge Utilities
The following object types can be merged using the new cmdlets:
• Tables
• Pages
• Reports
• Codeunits
• MenuSuites
• Queries
• XMLPorts
The following object types cannot be merged:
• Dataports
• Forms
• Reports with Classic report sections
So This tool cannot help us with Reports with Classic. This is one challenge that we will have during Upgrade from Version Lower than NAV 2013.
But i would say its still a great tool which should reduce the Upgrade Time Drastically if used correctly. You will find same in Other Post in this series.
Special Handling Required The application merge utilities handle all object types, but some better than others. Also, some parts of some object types require special attention from the tool or from you as described in the following list:
• Application object properties
(Discussed in How to Use - GET & SET NAVApplicationObjectProperty)
Each of the application object properties in the application object files often calls for hands-on handling. You can run the cmdlets with the default parameters values, but you can also overrule the default behavior by setting parameters specific for application object properties, or you can run other cmdlets for post-processing.
Two cmdlets are available specifically for post-processing: Get-NAVApplicationObjectProperty and Set- NAVApplicationObjectProperty.
• Documentation triggers (Discussed in How to Use - Merge NAVApplicationObject)
In each object, the documentation trigger is used for many different purposes. Documentation, of course, but also for tracking changes with date or history semantics built into it. You can use the cmdlets to modify the contents of the documentation section.
• ControlID (Discussed in How to Use - Merge NAVApplicationObject)
Sometimes, developers in-house or external partners create objects in the same ID range as you. This surfaces in the merge process as conflicts and hence as work to do. The application merge utilities provide ways to handle that, depending on your needs and requirements.
• CaptionML
Captions are an integral part of the solution, but when you compare two versions of the same object with two different languages, you will see extensive differences. Microsoft plan to add support for handling captions as part of the application merge utilities in a later version. However, you can choose as a temporary workaround to export captions to an external file during the application merge.
http://msdn.microsoft.com/en-us/library/dn479852(v=nav.71).aspx
Stay Tuned For More.
Regards,
Saurav Dhyani
saurav-nav.blogspot.com
Comments
Post a Comment