Best Practice for Reusing Functionality and DAC Fields from Another Customization

​@bihalivan15   The recommended approach would generally be to make the first customization a dependency of the second customization, rather than duplicating the DAC fields or functionality.

If the second customization needs to access DAC extensions, graph extensions, or other functionality introduced by the first project, you can reference the first customization's assembly/project and build the second customization against it. This keeps the shared functionality in one place and avoids maintaining duplicate code.

Another option, especially if the functionality is going to be reused across multiple customization projects, is to move the common DAC extensions and business logic into a shared customization library/assembly and have the individual customization projects reference that shared library.

I would avoid copying the DAC fields or implementation from one customization into another, as that can lead to duplicate definitions, upgrade issues, and maintenance problems.

The best structure depends on whether the first customization is always going to be deployed together with the second one. If they are independent/customers may deploy them separately, I'd lean toward a shared library or common customization layer. If the second customization will always depend on the first, treating the first project as a dependency is usually simpler.

Hi ​@bihalivan15 ,

Is the DAC field/functionality conceptually common to both customizations?

• Yes → Move it into a shared/common customization package and let both projects consume it.
• No, B is an extension of A → Make B dependent on A.
• Only a small amount of code is shared → Dependency on A may be simpler, but avoid copying the DAC extension.
• Large amount of common code → Consider a shared customization/library architecture.

The key principle is: don't duplicate DAC extensions or business logic merely because they are currently implemented in another customization project. Keep ownership of the shared DAC fields/functionality in one place and make the dependency explicit.

Hope above helps!!

Hi ​@bihalivan15,

Is the first customization project compiled into a DLL? If not, I would recommend considering that approach if the functionality is intended to be reused by other customization projects.

You can compile the shared functionality from the first customization into a DLL and then reference that DLL from the other customization projects. This allows you to reuse the existing code and DAC extensions/fields without duplicating the definitions or implementation.

You will also need to make sure that the customization projects are "published in the appropriate order" rather than simply "set the level of first customization before the second," since the exact deployment mechanism can vary and the important concept is that the dependency must be available before the dependent customization is built/published.

This approach has a few advantages:

• Avoids duplicating code and DAC definitions across customization projects.
• Provides a clear dependency between the customizations.
• Makes it easier to maintain common functionality in one place.
• Allows multiple customization projects to consume the same shared functionality.

The main consideration is version management. Whenever you make changes to the first customization, you should recompile the DLL and make sure that any dependent customization projects are rebuilt against the updated DLL. The updated DLL also needs to be included/deployed wherever the dependent customization is deployed.

If the shared functionality is expected to be reused by several customization projects, I would consider creating a separate common/shared customization DLL library containing only the reusable DACs, DAC extensions, graph extensions, helper classes, and other common functionality. That is generally cleaner than making Customization B depend directly on Customization A, because A may contain unrelated functionality that B doesn't actually need. The individual customization projects can reference that library rather than having one customization project depend on another unnecessarily.

Also, keep in mind that if the shared DAC fields are added through DAC extensions, the dependent customization should not redefine those fields. It should simply reference and use the existing DAC extension from the shared DLL.

This gives you a cleaner dependency structure and makes the customizations easier to maintain and upgrade.

Hope this helps.

​@KrunalDoshi For what reason?

​@darylbowman I did not follow the question?

For what reason would you recommend that the package being depended upon be compiled?

​@darylbowman,

The main reason I recommend compiling the package being depended upon is to make sure that Project B is referencing a compiled, consistent version of Project A.

For example, if Project A is compiled and its DLL is referenced by Project B, Project B is effectively built against that particular version of Project A. If you subsequently make changes to Project A—especially changes to DACs, DAC extensions, method signatures, or other public members—and update the DLL without rebuilding Project B, Project B may still have been compiled against the previous version of the assembly. This can potentially result in compilation issues, missing members, or unexpected runtime behavior depending on the changes.

Hopefully able to answer your question.

The terminology you’re using indicates you’re assuming both projects are being compiled. If neither project is compiled, it’s definitely true that changing A could be a problem for B, but I would argue it’s something that would be caught when publishing, not something that would hit you out of nowhere, and a problem that could be handled with version control just as easily as compiling.

That's a fair point. I may have been too specific in my terminology around compiling both projects.

My main point was that, if Project A is being compiled into a DLL and Project B is consuming that DLL, I would want to make sure that B is using the same version of A that it was developed/tested against.