How can I only trigger patching on specific branches ?

michael's Avatar


11 May, 2019 08:38 PM

Hi there,

I am migrating a project from .NET to .NET standard and have an issue with assembly patching when pull requests are being triggered

See here for the build failing

obj\Debug\netstandard2.0\OSPSuite.BDDHelper.AssemblyInfo.cs(16,59): warning CS7035: The specified version string does not conform to the recommended format - [C:\projects\ospsuite-bddhelper\src\OSPSuite.BDDHelper\OSPSuite.BDDHelper.csproj]
obj\Debug\netstandard2.0\OSPSuite.BDDHelper.AssemblyInfo.cs(19,55): error CS7034: The specified version string does not conform to the required format - major[.minor[.build[.revision]]] [C:\projects\ospsuite-bddhelper\src\OSPSuite.BDDHelper\OSPSuite.BDDHelper.csproj]

It seems that the assembly patching is causing the issue, creating a version that is not valid (if I remove the assembly patching, the build is successful. However we would like to have the build performed also on PR obviously)

This exact same workflow works fine when using AssemblyPatching for .NET 4.5 projects

Is there a way to disable assembly patching on Pull request? I tried to use conditional builds using for: or on: but it did not do anything
I am sure there is a simple way to make it work but I could not find it. I would appreciate any feedback you might have

Thanks for your help,


  1. 1 Posted by Owen McDonnell on 14 May, 2019 06:29 AM

    Owen McDonnell's Avatar

    Sorry for the delay in responding.

    There are plans to support specializing build configuration for PR builds with a for.pull_request construct, but as of yet it's not available.

    There are a few options, in order of increasing "hackey-ness"...

    First, you could simply remove

      do_not_increment_build_number: true
    from your config file, since this is appending the random string to each build, thus preventing legal patching.

    Or you could keep that in and use something like assembly_version: "$(app_version).$(APPVEYOR_BUILD_NUMBER)" in the patching section, though this will result in duplicated packages.
    Similarly, something like this

    version: '$(app_version).{build}'
      - cmd: if DEFINED APPVEYOR_PULL_REQUEST_NUMBER (Set build_number=1) ELSE (Set build_number=%APPVEYOR_BUILD_NUMBER%)

    in the config file could work, but again you'd have duplicated (or overwritten?) packages.

  2. 2 Posted by michael on 14 May, 2019 01:43 PM

    michael's Avatar

    Hi Owen,

    Thanks for getting back to me.
    We'd like to avoid creating incrementing the build number everytime a PR is made if possible. This is a great feature from appveyor and it would be fantastic to be able to use it onwards.

    Following on your suggestions: The only duplicate package I would get would be the one with build number 1 correct? Provided that appveyor does not have issue with multiple packages with the same version (I think it was not working a few years ago) then I should be fine.

    Do you have an ETA for the new for.pull_request construct?

    I'll try your suggestion and let you know


  3. 3 Posted by Owen McDonnell on 14 May, 2019 11:02 PM

    Owen McDonnell's Avatar

    The nuget package will just be overwritten.

    Difficult to give an estimate on that feature since the release of AppVeyor Server was given some priority : )

    You can follow the issue here.

  4. Ilya Finkelshteyn closed this discussion on 15 Jul, 2019 09:01 PM.

Comments are currently closed for this discussion. You can start a new one.

Keyboard shortcuts


? Show this help
ESC Blurs the current field

Comment Form

r Focus the comment reply box
^ + ↩ Submit the comment

You can use Command ⌘ instead of Control ^ on Mac