MSBuild target should be different when running in Azure DevOps pipeline












0















I have it defined for MSBuild to run unit tests and metrics after build:



<Target Name="AfterBuild" DependsOnTargets="RunUnitTests;RunCodeMetrics;StageFiles"/>


but if the build is run from Azure DevOps (a.k.a. VSTS), tests and metrics are defined as separate steps. How would I define targets based on where MSBuild is going to run?










share|improve this question























  • If you're in VSTS I would tend to use the built-in tasks for running tests instead of hiding it all within a single msbuild script. The built-in task automatically harvests the test results back into the build information for easy viewing.

    – daughey
    Nov 27 '18 at 21:45











  • Setting that aside, msbuild has a last-defined-wins approach to redefining targets. You could create targets files based on your environment that override certain targets. So on dev you could import dev.targets which defines targets for RunUnitTests, RunCodeMetrics and StageFiles.

    – daughey
    Nov 27 '18 at 21:45











  • Another option might be to run them as separate msbuild steps within the VSTS run. Use the /t:RunUnitTests in one, /t:RunCodeMetrics in another and /t:StageFiles in the other.

    – daughey
    Nov 27 '18 at 21:45
















0















I have it defined for MSBuild to run unit tests and metrics after build:



<Target Name="AfterBuild" DependsOnTargets="RunUnitTests;RunCodeMetrics;StageFiles"/>


but if the build is run from Azure DevOps (a.k.a. VSTS), tests and metrics are defined as separate steps. How would I define targets based on where MSBuild is going to run?










share|improve this question























  • If you're in VSTS I would tend to use the built-in tasks for running tests instead of hiding it all within a single msbuild script. The built-in task automatically harvests the test results back into the build information for easy viewing.

    – daughey
    Nov 27 '18 at 21:45











  • Setting that aside, msbuild has a last-defined-wins approach to redefining targets. You could create targets files based on your environment that override certain targets. So on dev you could import dev.targets which defines targets for RunUnitTests, RunCodeMetrics and StageFiles.

    – daughey
    Nov 27 '18 at 21:45











  • Another option might be to run them as separate msbuild steps within the VSTS run. Use the /t:RunUnitTests in one, /t:RunCodeMetrics in another and /t:StageFiles in the other.

    – daughey
    Nov 27 '18 at 21:45














0












0








0








I have it defined for MSBuild to run unit tests and metrics after build:



<Target Name="AfterBuild" DependsOnTargets="RunUnitTests;RunCodeMetrics;StageFiles"/>


but if the build is run from Azure DevOps (a.k.a. VSTS), tests and metrics are defined as separate steps. How would I define targets based on where MSBuild is going to run?










share|improve this question














I have it defined for MSBuild to run unit tests and metrics after build:



<Target Name="AfterBuild" DependsOnTargets="RunUnitTests;RunCodeMetrics;StageFiles"/>


but if the build is run from Azure DevOps (a.k.a. VSTS), tests and metrics are defined as separate steps. How would I define targets based on where MSBuild is going to run?







msbuild azure-devops azure-pipelines






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked Nov 22 '18 at 9:59









TschareckTschareck

2,23072859




2,23072859













  • If you're in VSTS I would tend to use the built-in tasks for running tests instead of hiding it all within a single msbuild script. The built-in task automatically harvests the test results back into the build information for easy viewing.

    – daughey
    Nov 27 '18 at 21:45











  • Setting that aside, msbuild has a last-defined-wins approach to redefining targets. You could create targets files based on your environment that override certain targets. So on dev you could import dev.targets which defines targets for RunUnitTests, RunCodeMetrics and StageFiles.

    – daughey
    Nov 27 '18 at 21:45











  • Another option might be to run them as separate msbuild steps within the VSTS run. Use the /t:RunUnitTests in one, /t:RunCodeMetrics in another and /t:StageFiles in the other.

    – daughey
    Nov 27 '18 at 21:45



















  • If you're in VSTS I would tend to use the built-in tasks for running tests instead of hiding it all within a single msbuild script. The built-in task automatically harvests the test results back into the build information for easy viewing.

    – daughey
    Nov 27 '18 at 21:45











  • Setting that aside, msbuild has a last-defined-wins approach to redefining targets. You could create targets files based on your environment that override certain targets. So on dev you could import dev.targets which defines targets for RunUnitTests, RunCodeMetrics and StageFiles.

    – daughey
    Nov 27 '18 at 21:45











  • Another option might be to run them as separate msbuild steps within the VSTS run. Use the /t:RunUnitTests in one, /t:RunCodeMetrics in another and /t:StageFiles in the other.

    – daughey
    Nov 27 '18 at 21:45

















If you're in VSTS I would tend to use the built-in tasks for running tests instead of hiding it all within a single msbuild script. The built-in task automatically harvests the test results back into the build information for easy viewing.

– daughey
Nov 27 '18 at 21:45





If you're in VSTS I would tend to use the built-in tasks for running tests instead of hiding it all within a single msbuild script. The built-in task automatically harvests the test results back into the build information for easy viewing.

– daughey
Nov 27 '18 at 21:45













Setting that aside, msbuild has a last-defined-wins approach to redefining targets. You could create targets files based on your environment that override certain targets. So on dev you could import dev.targets which defines targets for RunUnitTests, RunCodeMetrics and StageFiles.

– daughey
Nov 27 '18 at 21:45





Setting that aside, msbuild has a last-defined-wins approach to redefining targets. You could create targets files based on your environment that override certain targets. So on dev you could import dev.targets which defines targets for RunUnitTests, RunCodeMetrics and StageFiles.

– daughey
Nov 27 '18 at 21:45













Another option might be to run them as separate msbuild steps within the VSTS run. Use the /t:RunUnitTests in one, /t:RunCodeMetrics in another and /t:StageFiles in the other.

– daughey
Nov 27 '18 at 21:45





Another option might be to run them as separate msbuild steps within the VSTS run. Use the /t:RunUnitTests in one, /t:RunCodeMetrics in another and /t:StageFiles in the other.

– daughey
Nov 27 '18 at 21:45












1 Answer
1






active

oldest

votes


















0














I ended up having this Condition in my targets file:



<Target Name="AfterBuild" Condition="'$(AzureDevOps)' != 'true'" DependsOnTargets="RunUnitTests;RunCodeMetrics;StageFiles" />
<Target Name="AfterBuild" Condition="'$(AzureDevOps)' == 'true'" DependsOnTargets="StageFiles"/>


When build is started from cloud, MSBuild argument is added:



/p:AzureDevOps=true





share|improve this answer























    Your Answer






    StackExchange.ifUsing("editor", function () {
    StackExchange.using("externalEditor", function () {
    StackExchange.using("snippets", function () {
    StackExchange.snippets.init();
    });
    });
    }, "code-snippets");

    StackExchange.ready(function() {
    var channelOptions = {
    tags: "".split(" "),
    id: "1"
    };
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function() {
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled) {
    StackExchange.using("snippets", function() {
    createEditor();
    });
    }
    else {
    createEditor();
    }
    });

    function createEditor() {
    StackExchange.prepareEditor({
    heartbeatType: 'answer',
    autoActivateHeartbeat: false,
    convertImagesToLinks: true,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: 10,
    bindNavPrevention: true,
    postfix: "",
    imageUploader: {
    brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
    contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
    allowUrls: true
    },
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    });


    }
    });














    draft saved

    draft discarded


















    StackExchange.ready(
    function () {
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53428319%2fmsbuild-target-should-be-different-when-running-in-azure-devops-pipeline%23new-answer', 'question_page');
    }
    );

    Post as a guest















    Required, but never shown

























    1 Answer
    1






    active

    oldest

    votes








    1 Answer
    1






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    0














    I ended up having this Condition in my targets file:



    <Target Name="AfterBuild" Condition="'$(AzureDevOps)' != 'true'" DependsOnTargets="RunUnitTests;RunCodeMetrics;StageFiles" />
    <Target Name="AfterBuild" Condition="'$(AzureDevOps)' == 'true'" DependsOnTargets="StageFiles"/>


    When build is started from cloud, MSBuild argument is added:



    /p:AzureDevOps=true





    share|improve this answer




























      0














      I ended up having this Condition in my targets file:



      <Target Name="AfterBuild" Condition="'$(AzureDevOps)' != 'true'" DependsOnTargets="RunUnitTests;RunCodeMetrics;StageFiles" />
      <Target Name="AfterBuild" Condition="'$(AzureDevOps)' == 'true'" DependsOnTargets="StageFiles"/>


      When build is started from cloud, MSBuild argument is added:



      /p:AzureDevOps=true





      share|improve this answer


























        0












        0








        0







        I ended up having this Condition in my targets file:



        <Target Name="AfterBuild" Condition="'$(AzureDevOps)' != 'true'" DependsOnTargets="RunUnitTests;RunCodeMetrics;StageFiles" />
        <Target Name="AfterBuild" Condition="'$(AzureDevOps)' == 'true'" DependsOnTargets="StageFiles"/>


        When build is started from cloud, MSBuild argument is added:



        /p:AzureDevOps=true





        share|improve this answer













        I ended up having this Condition in my targets file:



        <Target Name="AfterBuild" Condition="'$(AzureDevOps)' != 'true'" DependsOnTargets="RunUnitTests;RunCodeMetrics;StageFiles" />
        <Target Name="AfterBuild" Condition="'$(AzureDevOps)' == 'true'" DependsOnTargets="StageFiles"/>


        When build is started from cloud, MSBuild argument is added:



        /p:AzureDevOps=true






        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Dec 5 '18 at 15:27









        TschareckTschareck

        2,23072859




        2,23072859
































            draft saved

            draft discarded




















































            Thanks for contributing an answer to Stack Overflow!


            • Please be sure to answer the question. Provide details and share your research!

            But avoid



            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.


            To learn more, see our tips on writing great answers.




            draft saved


            draft discarded














            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53428319%2fmsbuild-target-should-be-different-when-running-in-azure-devops-pipeline%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown





















































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown

































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown







            Popular posts from this blog

            "Incorrect syntax near the keyword 'ON'. (on update cascade, on delete cascade,)

            Alcedinidae

            Origin of the phrase “under your belt”?