• Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Blocker Blocker
    • dotnet-sdk-plugin
    • Jenkins 2.332.1 on Win Server 2019

      Does the .Net SDK Plugin support .Net 6?  We have been using it for .Net5 builds, but recently upgraded to .Net6 and I see in some of your docs ".net 5.0" and one place ".net 5.0+".  I looked and .net 6 is listed in your tfm-list.json in GitHub but not sure if that is good enough.  It may be user error on my part, but I cannot figure out what i need to do to include 6 in the .Net SDK dropdown list.

      I think this is contributing to why my build is failing.

          [JENKINS-70251] .Net SDK Support for .Net Core 6?

          David added a comment -

          Well, it turns out this was not the issue that was causing my problems.  I figured out the issue and the build is working.  However, it is working on .Net6 while .Net5 is selected in the SDK dropdown.  I am guessing there have been no changes to the commands, so we are fine, but not sure if you want to add a .net6 option to the list or not.

          Thanks for the plugin!

          David added a comment - Well, it turns out this was not the issue that was causing my problems.  I figured out the issue and the build is working.  However, it is working on .Net6 while .Net5 is selected in the SDK dropdown.  I am guessing there have been no changes to the commands, so we are fine, but not sure if you want to add a .net6 option to the list or not. Thanks for the plugin!

          I'm not entirely sure what you mean. The SDKs listed in the dropdown (or available for use in the tool section of a pipeline) are the ones configured for use in Jenkins (Manage Jenkins > Global Tool Configuration > .NET SDK).
          The SDKs listed in that interface, if you're using the "Install from microsoft.com" option, are the ones advertised by Microsoft (they made a small change in the data format for .NET 7 so until I have time to update the plugin, it might show some odd SDK state info, but that should be easy to ignore). Currently this should run up to .NET 7.0.

          Tim Van Holder added a comment - I'm not entirely sure what you mean. The SDKs listed in the dropdown (or available for use in the tool section of a pipeline) are the ones configured for use in Jenkins (Manage Jenkins > Global Tool Configuration > .NET SDK). The SDKs listed in that interface, if you're using the "Install from microsoft.com" option, are the ones advertised by Microsoft (they made a small change in the data format for .NET 7 so until I have time to update the plugin, it might show some odd SDK state info, but that should be easy to ignore). Currently this should run up to .NET 7.0.

          If it was using a .NET 6 SDK but .NET 5 was selected in the dropdown, then either the SDK configured as ".NET 5" was mislabeled, or there is a problem in the plugin (it /should/ set up the path to ensure the SDK installed by Jenkins appears first).

          On Windows, dotnet.exe often looks at system-level SDKs too even if it's not the system-installed dotnet.exe, and will pick the highest version by default; in such a case, you can check the "Require Specific SDK Version" box when configuring your build step.
          (In general, when using CI it may make sense to just commit a global.json specifying the exact SDK version you expect to be in use for your build. Then builds will not generally break when a newer SDK is installed on the build machines.)

          Tim Van Holder added a comment - If it was using a .NET 6 SDK but .NET 5 was selected in the dropdown, then either the SDK configured as ".NET 5" was mislabeled, or there is a problem in the plugin (it /should/ set up the path to ensure the SDK installed by Jenkins appears first). On Windows, dotnet.exe often looks at system-level SDKs too even if it's not the system-installed dotnet.exe, and will pick the highest version by default; in such a case, you can check the "Require Specific SDK Version" box when configuring your build step. (In general, when using CI it may make sense to just commit a global.json specifying the exact SDK version you expect to be in use for your build. Then builds will not generally break when a newer SDK is installed on the build machines.)

            zastai Tim Van Holder
            dbmcdona David
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated: