Missing check-in

An opinion I encounter relatively often is that a disadvantage of isolated development environments of Dynamics AX is in the fact that if one developer forgets to include an object in version control, the application doesn’t work and doesn’t compile in other development environments. So I’ll probably surprise many people by the statement that I consider that, on the contrary, an advantage.

Let’s take an example – let’s have class A using class B. If only class A is in version control, the application built from this version won’t compile because it refers to missing class B. It will all work in the original development environment, because class B is still there.

So what’s the difference between shared and distributed environments?

From version control perspective – none. The object is simply absent in the version and this version can’t be successfully built.

But there is a difference in Dynamics AX – the shared environment behaves in the same way as the environment of the original developer, i.e. it contains a version not existing in version control, including class B. Therefore the code will compile (you get only a Best Practice error) and everything will work unless you correctly build the application from version control. At the best, it will be on the same day in a night build, in the worse case, it will be some time later, e.g. when you want to create a branch in version control or to reconstruct a collapsed development environment (and you realize that it can’t be done).

In short, errors must be detected as soon as possible and shared environments cover up this type of error. This is not a critical problem and night builds solve it quite effectively, but I surely wouldn’t describe error hiding as an advantage.

I’ve heard one more argument about this topic: “We always copy layers anyway, we never build directly from version control”. That sounds almost like: “Of course we use version control. We just don’t care if we have any objects in it”. 🙂


  1. Amen to that!

    I’ve spent a lot of time defending isolated development because most of the functional people do not see the advantage 🙂
    So this is by far the best argument that encourages that approach.

    Another one is for developers that need to debug code running in CIL. When the attach the debugger to the AOS process, all of the other developers can just go out for a coffee when the code hits the other developer’s breakpoint…

    kind regards,

  2. I really like these posts about TFS, keep them coming. Might cover up some issues myself soon by reviving my blog 🙂

    You have a best practice check in AX 2012 for validating if a cross-referenced object exists which is used by a method. See \\Classes\SysBPCheckMemberFunction\checkUseLocalObjects() for an example.

    I believe the VCS check-in classes can be extended, so when specific object types are checked in from the AOT, we could update the cross-references and validate all connected objects if they exist in the TFS repository or if they are listed in the current list of pending objects being checked in.

    This way we would be able notify the developer working in the isolated workspace that he is potentially missing objects.

    We have not yet implemented and tested this approach, so no hands-on experience yet if the xref update considerably slows down the check-in process or not, but in theory this can help with the problem mentioned above.


Comments are closed.