Skip to main content

Notifications

Announcements

No record found.

Dynamics 365 Community / Forums / Finance forum / Repository merged back...
Finance forum
Answered

Repository merged back to Main Branch, but fails to build.

Posted on by 452

Hello,

Please forgive and kindly correct any terminology I may mix up in this post.  I'm only a few months on the job and learning day by day without an on staff mentor (Working my way through the Learning catalog for Dynamics 365 Finance developers).  Also, sorry for the long post, but the detail is important I think.

I recently completed some development work in a development branch.  We have a Main / Dev branch strategy for our D365 code management in our Azure VisualStudio.com project.

The work in the development branch included: Custom D365 extension creation and modification.  Two ISV Package updates.  I know not the best to do so many changes at once, but there was a sense of urgency that needed to be met. 

For One of the ISV packages I had issues with too many folders added to source control and was getting \bin and \resource .dll and other files showing up as 'changed' when I think I just wanted to source control manage the source code, not the built artifacts?  So I tried to remove them from source control and re-add the ISV package without monitoring the \bin and \resource folders. This has impact later in this question.

The dev branch work built successfully, and I created a Software Deployable Package (SDP) and saved that to my asset library.  I successfully deployed that SDP to a Separate Cloud Hosted test machine. I also successfully deployed that SDP to our UAT test environment hosted on LCS.

Tests were successful.

I then went to merge the changesets from the development branch into main branch. The change sets related to the cleanup work would not merge. But I brought in the changesets that did work.  To my understanding all folders in the AOS Packages heirarchy with AOT elements and descriptors were included and merged across back to the main branch.

Result: Build on the main branch fails, errors reported were related to the two ISV packages.

Not having time to find the root of the problem I re-imported the ISV code models into the main branch. Build now succeeds.

Visually that all looks like this:

pastedimage1683227835214v1.png

Note while our site has an Azure DevOps project with all the bells and whistles at the Azure DevOps page, it's not really used anymore. What is used is the code branches hosted on our visualstudio.com project. And all my interaction is through Visual Studio on my Dev Tier 1 cloud hosted machine on Azure, and my Build Tier 1 cloud hosted machine on Azure.

Anyway... with all that laid out here are my questions

  1. Was there some set of folders I am missing in source control that resulted in the failure to build?
  2. Did I just try to make too many changes and this kind of problem was to be expected?

Thanks again for reading all this and I hope some in the community have a bit of time to share some help in general or as specific as they have time to share.

Best Regards.

  • Verified answer
    Martin Dráb Profile Picture
    Martin Dráb 228,126 Most Valuable Professional on at
    RE: Repository merged back to Main Branch, but fails to build.

    Yes, I mean that if you add something to source control and later realize that you don't want it there, you can simply delete those unwanted folders or files, instead of removing everything and starting from scratch.

    You technically can include both source code and binaries in source code, but it's not a good idea. It's wasteful, because you can always build binaries from source code. And it would complicate your life, because every build updates binaries and you get pending changes for them.

    By the way, you may be interested in Dynamics 365 Finance and Operations development ALM guide.

  • jt1024 Profile Picture
    jt1024 452 on at
    RE: Repository merged back to Main Branch, but fails to build.

    Hello Martin,

    Thank-you so much for digging into my not so simple question.  

    When you say "If you install a model with source code, it shouldn't (normally) contain bin, reports, resources or XppMetadata, just the folder(s) with a model (models) and descriptor files. But if you do a mistake, no problem - simply delete them from source control."

    I'll try to expand on that to make sure I understand you correctly. Do you mean:

    1. The source code from the ISV in the delivered state should not have bin, reports, resources or xpp metadata. Yes agreed, all I have from this ISV is .axmodel files.

    >>> Question: 2. "But if you do a mistake" - do you mean mistakenly add the \bin, and \resources folders to source control?

    I later read at community.dynamics.com/.../798473 where Nikolaos suggested:

    "You can have anything you want in the source control.

    But these are the ones that you really need:

    - C:\AOSService\PackagesLocalDirectory\YourPackage\YourModel -> entire folder

    - C:\AOSService\PackagesLocalDirectory\YourPackage\Descriptor -> the descriptor for your model (must be added manually to source control)"

    I'm starting to think the Azure DevOps automated way may be better, but we don't have that set up or documented currently.  I'd have to learn how to do that and set it up.

    >>> Question: I think what I'm struggling to understand and am frustrated by it's apparent lack of function - the way I must be using it wrong - is this:

    The branching and merging is supposed to allow for successful work in either branch and allow you to bring back those new pieces of code from a dev branch to your main branch, and this is what I'm trying to master at the moment.  It doesn't help that every resource you go to, even if it's within the D365 Finance realm seems to say "Well you can do whatever you want, you can go with this or you can go with that..."  it can make it difficult to learn. :-( Haha.

    - Jim

  • Martin Dráb Profile Picture
    Martin Dráb 228,126 Most Valuable Professional on at
    RE: Repository merged back to Main Branch, but fails to build.

    It very difficult to discuss, because we don't know what changes you made and what the errors were (on compilation and merge).

    If you install a model with source code, it shouldn't (normally) contain bin, reports, resources or XppMetadata, just the folder(s) with a model (models) and descriptor files. But if you do a mistake, no problem - simply delete them from source control. (The exception is that sometimes extra .NET assemblies are added to bin folder and they need to be add to source control.)

    If it was a binary model, the situation is completely different. There you have no source code and you need the binaries.

    Note that if you create a deployable package in Visual Studio and it works, it doesn't mean that the contents of your Dev branch compiles and works, because you created a package from code on your machine, not from source control. They may be out of sync without you knowing. A safer approach is using an automated build that starts with a clean environment and download code from source control.

    The number of changes isn't a problem.

Helpful resources

Quick Links

Dynamics 365 Community Update – Sep 9th

Welcome to the next edition of the Community Platform Update. This is a weekly…

Announcing Our 2024 Season 2 Super Users!

A new season of Super Users has arrived, and we are so grateful for the daily…

Leaderboard

#1
André Arnaud de Calavon Profile Picture

André Arnaud de Cal... 290,277 Super User 2024 Season 2

#2
Martin Dráb Profile Picture

Martin Dráb 228,126 Most Valuable Professional

#3
nmaenpaa Profile Picture

nmaenpaa 101,148

Leaderboard

Featured topics

Product updates

Dynamics 365 release plans