Copied to clipboard

Flag this post as spam?

This post will be reported to the moderators as potential spam to be looked at


  • Bart 7 posts 88 karma points
    Nov 29, 2022 @ 15:37
    Bart
    0

    Vendr Backoffice folder missing when deploying with Azure DevOps (Umbraco10)

    Hello,

    Last week I have upgraded our umbraco v9 to umbraco v10 and also installed the Vendr package. Locally this is working perfectly. When deployed to an Azure Web App we get errors when going to the 'Commerce' section or 'Vendr settings' section. The views are missing:

    enter image description here

    When in go to Kudu in the Azure environment I can see the folder App_Plugins/Backoffice is missing.

    enter image description here

    When doing a regular publish from Visual Studio to file system, the 'backoffice' folder is included. Also when deploying from Visual Studio to Azure directly the folder is include. It's only missing when running our deployment pipelines in Azure Dev Ops.

    When looking at the Dev Ops logs I can see it is creating some folders, but the backoffice folder isn't there:

    enter image description here

    I am not quite sure if this is an issue related to umbraco/vendr or to the Dev Ops pipeline, but maybe someone ran into the same issue. To give as much information as might be relevant I added the yaml file as well.

    The yaml file for deploying is:

    - stage: Build
      displayName: Build stage
    
      jobs:
      - job: Build
        displayName: Build
        pool:
          vmImage: $(vmImageName)
    
    steps:
    - task: [email protected]
      inputs:
        versionSpec: 
        checkLatest: true
    
    - task: [email protected]
      displayName: 'Restore NuGet'
      inputs:
        command: 'restore'
        restoreSolution: '**/*.sln'
    
    - task: [email protected]
      inputs:
        solution: '**\*.sln'
        msbuildArgs: '/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:PackageLocation="$(System.DefaultWorkingDirectory)/publish_output\\" /p:TransformWebConfigEnabled=False'
        platform: '$(buildPlatform)'
        clean: true
        configuration: $(buildConfiguration)
    
    - task: [email protected]
      displayName: 'Archive files'
      inputs:
        rootFolderOrFile: '$(System.DefaultWorkingDirectory)/publish_output'
        includeRootFolder: false
        archiveType: zip
        archiveFile: $(Build.ArtifactStagingDirectory)/$(Build.BuildId).zip
        replaceExistingArchive: true
    
    - publish: $(Build.ArtifactStagingDirectory)/$(Build.BuildId).zip
      displayName: 'Publish files'
      artifact: drop
    
       - stage: TestDeploy
         displayName: Test Deploy stage
         dependsOn: Build
         condition: succeeded()
    
        jobs:
       - deployment: TestDeploy
        displayName: Deploy to Test
        environment: 'Test'
        pool:
          vmImage: $(vmImageName)
    
        strategy:
          runOnce:
            deploy:
              steps: 
              - task: [email protected]
                inputs:
                  archiveFilePatterns: '$(Pipeline.Workspace)/drop/$(Build.BuildId).zip'
                  destinationFolder: '$(Pipeline.Workspace)/drop/$(Build.BuildId)/extracted'
                  cleanDestinationFolder: true
                  overwriteExistingFiles: true
    
              - task: [email protected]
                displayName: 'Deploy to Azure'
                inputs:
                  ConnectionType: 'AzureRM'
                  azureSubscription: $(azureSubscription)
                  appType: 'webApp'
                  WebAppName: $(appServiceNameTest)
                  package: $(Pipeline.Workspace)/drop/$(Build.BuildId)/extracted/*.zip
                  enableCustomDeployment: true
                  DeploymentType: 'webDeploy'
    
  • Warren 3 posts 94 karma points
    Dec 22, 2022 @ 11:02
    Warren
    0

    Hello, yeah I am running into the same issue with other packages such as Contentment and Our.Umbraco.TheDashboard. I think the issue is to do with packages that store assets in Razor Class Libraries. For some reason the [email protected] pipeline task doesn't copy over the files in those packages to the App_Plugins folder like it does with a normal publish.

    This forum comment kinda explains what's going on.

    As for a solution, have you come up with anything yet?

    It seems like most solutions for missing files involve just copying them yourself using the [email protected] task, then doing another deploy task to push the files to your server. I am currently attempting this with an IIS deployment.

    I did notice on this Umbraco 8 Azure Devops guide they are setting a custom publish profile, so maybe there could be a publish setting to use to try and get the build to copy across nuget package RCL files properly.

  • Warren 3 posts 94 karma points
    Dec 23, 2022 @ 11:00
    Warren
    0

    I have found my issue, it might be the same case for you.

    I tried running the MSBuild that the [email protected] task runs locally on my machine to see if I could replicate the issue. I could not, all my package folders inside the App_plugin folder were there.

    My issue was that my /App_Plugins folder was being excluded from source control.

    I think because the Azure pipeline checks out the repository from source control, if those App_Plugin folders aren't present then they won't make their way to the final zip for some reason, even though I'm running the nuget restore task and I can see in the logs that it is retrieving the files for the packages.

  • Kevin Jump 2195 posts 14010 karma points MVP 6x c-trib
    Dec 23, 2022 @ 12:15
    Kevin Jump
    100

    Hi,

    Just looking at the pipeline, i would look at replacing the msbuild task with a dotnet publish one.

    I think underneath they all end up doing very similar things, but i've never had issues using dotnet publish and i wonder if that is wrapping things up that calling the msbuild task directly isn't ?

    domething like

    dotnet publish -c release -o $(System.DefaultWorkingDirectory)/publish_output\\
    

    (but i am very wary of offering support as to what exactly you should put in your yaml files!)

  • Bart 7 posts 88 karma points
    Dec 27, 2022 @ 18:33
    Bart
    0

    Hello Warren & Kevin,

    @Warren, I think the problem you are running into is exactly the same as us. I first couldn't replicate the issue locally as well. But I always had to clean the solution before the problem occurred locally. So running the build command twice seems to hide the initial problem.

    @Keving, we indeed changed our yaml pipeline to use dotnet publish instead of VSBuild task. We still haven't figured out why the VSBuild isn't restoring the targets correctly, but using dotnet publish fixed our issue and we are fine using that as a solution.

Please Sign in or register to post replies

Write your reply to:

Draft