Checking in references to other models

As you might be aware, sometimes you need to add a reference to other models in your own models. You do this by going to Dynamics 365 > Model Management > Update model parameters, selecting your model, and checking the box for the model you want to reference.

Addinf references to a model

For example, here you see references added for FiscalBooks, GeneralLedger, Ledger, and Measurement. (A full discussion of references is too much for this blog post, though!)

I discovered, to my surprise, that even experienced developers sometimes don’t know how to check in these changes. If code that requires the reference is checked in, but the new reference is not, the build breaks with potentially mysterious and hard-to-diagnose errors!

How do you check in changes to references? You need to check in the DESCRIPTOR file for the model. It will be an XML file named after the model, and it will be in \AOSService\PackagesLocalDirectory\<ModelName>\Descriptor; it might excluded by default, and you need to make sure to include it in your changes. For example, if you add a reference to a model named “Czar Extensions Model,” you want to see something like this in your pending changes for the check-in:

Pending changes with Descriptor file

I hope this helps. May all your builds be “green”!


Doing a code merge when a VAR/ISV has renamed an object

This is probably general to Visual Studio (or any other development tool and source control), and not specific to Dynamics 365 for Operations; but after it ate up several hours of my life figuring out why a build wasn’t working, I thought I should share.

What might be unique (or at least more prevalent) in our world of Dynamics 365 for Operations is the need to do a “code merge” from multiple ISVs or VARs. Chances are it will become almost routine for you, and unless Visual Studio gets better at it, after a few months you’ll be routinely promoting changes that aren’t automatically picked up in “Pending Changes.”

Unfortunately, if you get used to promoting both adds and deletes all over, you might miss that renames should be treated specially. You might inadvertently end up with two copies of the object in source control, one with the old name and one with the new name… and, unless you’re sharper than me (certainly possible!) you’ll spend a lot of time puzzling out why your build won’t work but your local compile does, even though your source seems synched. (But, you might eventually notice, the names in your Application Explorer don’t match your file names…!)

Anyway, the meat of the matter is: make sure to watch out for renames, and promote them by highlighting the relevant “delete” and “add” together, right-clicking, and choosing “Promote as Rename.”

Promote as Rename


And as a tip ┬áto those working for an ISV/VAR: try to avoid renaming objects once they’ve been checked in, and pass along warning if you do. Maybe your client will have no problem if you don’t… but there’s a chance you’ll be saving them a long night if you do!