If you use ISVs that ship netmodules or DLLs, a developer trying to “get latest” in Visual Studio might get errors, telling them that they cannot overwrite existing DLLs. The error might read something like “Access to the path … is denied.” There are a few ways to solve this problem.
If you use ISVs that ship netmodules or DLLs, they can be a little tricky to merge, build, and distribute to multiple developers. Besides making sure that you “include” all the right files when you first check in their models, if you later check in changes when the ISVs ship them, this can cause problems for other developers.
A developer trying to “get latest” in Visual Studio might get errors, telling them that they cannot overwrite existing DLLs. The error might read something like “Access to the path … is denied.” Here’s an example I get when I try to get a DLL from the ISV Avalara:
There are a few ways to solve this problem:
(1) Stop Services
I keep a batch file that I can “run as administrator” to do this, or you can manually do it in Sevices. (A second batch file changing “NET STOP to “NET START” can restart them.)
NET STOP "MR2012ProcessService"
NET STOP "DynamicsAxBatch"
NET STOP "Microsoft.Dynamics.AX.Framework.Tools.DMF.SSISHelperService.exe"
NET STOP "W3SVC"
(2) Stop IIS Express
If stopping services isn’t good enough, you might need to stop IIS Express, which Visual Studio automatically launches every time you start it. It isn’t a service, though; you need to close it from a little tray icon. Right-click it and choose “Exit.” You’ll probably need to restart Visual Studio before you can debug again.
(3) Advanced “get”
Do an “advanced get” and be sure to click the checkbox to overwrite existing files.
(4) Delete & Get
A final desperate move, after stopping the services and IIS Express, is to outright delete the files (via Windows Explorer) that it refuses to overwrite. Then it might let you get them since it doesn’t need to overwrite them.
Did these tips help? Do you know an easier way, or something I missed? Let me know in the comments!
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.
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:
I hope this helps. May all your builds be “green”!
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.”
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!