Announcements
Hi,
We have a new AX2012 R2 customer with all of their existing customization are in VAR layer.
Apparently, they want to install cumulative update 9.
Hence, in a test environment, we installed the update and need to merge the codes from SYP layer to VAR layer. However, we do not have the license to access VAR layer.
We are thinking to move the customization from VAR layer to USR layer, then merge SYP to USR layer instead.
Is it possible to move objects from VAR layer to USR layer without having to login to VAR layer? If can, how?
Thank you.
Hairul,
1. You will be able to differentiate the code modified by you and the one already existing if you do a compare on the object. Also, I assume you would be tagging your mods for issue/error corrections.
2. Same logic with SYP layer. You can't merge any lower layer into USR. You will just be modifying the objects to resolve errors.
Without access to VAR or CUS layer, your only option would be to move ahead with USR. Provided you manage to obtain VAR license, that would be the best scenario for you.
Standard and custom code already exists in USR layer. Whenever you modify a SYP (or VAR or CUS) method, the whole method is copied to USR layer. This is the very reason why this code merge is needed - your old copy of the Microsoft code is hiding the new changes in it.
That's why it's important to clearly mark your own custom code lines with comments, and name all your custom fields, form controls etc with your own prefix. This way the naming convention and the comments will always tell you if it's your stuff or Microsoft's.
In D365 you will get rid of this issue completely since you can't write "on top" of Microsoft code anymore. Instead you create extensions which can live "side by side" with Microsoft code, and usually don't require any changes when you install new MS versions.
Yes, merging to USR layer could work. But we actually have some concerns.
Our practice all this while is, we put all of our customization in USR layer.
With existing customization in VAR layer, and ours on USR layer, we can differentiate whether a customization is done by previous vendor or us, especially when any issue arises.
At this point, we consider everything in USR layer as our customization. So if we were to merge the SYP into USR layer, it can cause confusion where standard codes and custom codes would coexist in USR layer.
With that in mind, we would like know every possible alternative and see which is the most appropriate for us to proceed.
Ideally, we need to get the license so we can merge to VAR.
But without the access to VAR or CUS layer, can I conclude that our only option is to merge into USR layer?
USR layer would work as well. Technically, it is the same thing i.e. you are moving to a higher layer. As per best practices, you should not have code in USR layer.
You might be able to request the customer if they are able to see CUS layer development codes form MS customer source.
CUS / USR is quite irrelevant.
The options are:
- Merge the conflicts on your customization layer
- Bring code from all lower layers to your customization layer and resolve the conflicts
Some suggestions were given to you in your earlier question: community.dynamics.com/.../client-first-time-open-kernelbase-dll-error
Hi Gunjan,
unfortunately, CUS layer is not accessible as well. We can only log in to USR layer. Is there any workaround?
Hairul,
Moving objects from VAR to USR layer might have implications like changing object Ids. This will be a long and time consuming process which will also need rounds of testing of all customizations from your side and the customer side.
Since they are a customer, they would ahve access to CUSlayer. I would suggest you leave the VAR layer as it is, and resolve any code merge issues ON the CUS layer.
André Arnaud de Cal...
294,118
Super User 2025 Season 1
Martin Dráb
232,866
Most Valuable Professional
nmaenpaa
101,158
Moderator