I have couple customization where in some I have the code base and others were published by old employee. I dont have access to those code. Is there a way to combine mine with other just by dll files?
Answer
How to combine Customization where I have codebase for one project but not for another?
Best answer by darylbowman
I’ve seen it in various forms. The pickiest portion of customizations is workflow. Different packages containing workflow affecting the same screen will NOT play nicely together.
Other than that, it may depend how embedded the customizations are to the business. If there’s a good chance you’ll end up discarding some at some point, keep them separate. If they’re hardcore pillars of the system, you could combine them all into one package and write detailed comments. The worst thing is trying to troubleshoot something across multiple packages with extensions to the same graph.
+15Are you asking to combine the Customization Projects or the code?
#1 is easy. #2 is not.
Daryl ⚡Freelance Acumatica Developer (MVP🏆) for hire ⏩ linkedin.com/in/darylbowman
Since the one with no code access has lot of dac and graph extensions I wanted to make a single codebase so its easier for future builds. By other you mean just add the dll file to my customization?
+15Well, assuming both projects have UI customizations as well, it can be tricky to combine projects. There’s a trick that makes it simple, but it doesn’t really sound like that’s what you’re going for.
I’d recommend getting in touch with the old employee and requesting access to the code. You could decompile the dll, but it’s really painful trying to rewrite code out of a dll.
Daryl ⚡Freelance Acumatica Developer (MVP🏆) for hire ⏩ linkedin.com/in/darylbowman
Yeah make sense Thanks for helping,
You know any way to organize my customizations? I have like 10-15 projects some big some small. It keeps getting difficult everytime we need to upgrade the versions. Do i do by screens or modules or anything else?
Ronak Gala
+15I’ve seen it in various forms. The pickiest portion of customizations is workflow. Different packages containing workflow affecting the same screen will NOT play nicely together.
Other than that, it may depend how embedded the customizations are to the business. If there’s a good chance you’ll end up discarding some at some point, keep them separate. If they’re hardcore pillars of the system, you could combine them all into one package and write detailed comments. The worst thing is trying to troubleshoot something across multiple packages with extensions to the same graph.
Different packages containing workflow affecting the same screen will NOT play nicely together.
I agree with
Aleks
Aleks
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.