Laden...

AzureDevOps - Job verwendet nicht die globale .NET-Core Version

Erstellt von scoKi! vor 5 Jahren Letzter Beitrag vor 5 Jahren 1.391 Views
scoKi! Themenstarter:in
90 Beiträge seit 2009
vor 5 Jahren
AzureDevOps - Job verwendet nicht die globale .NET-Core Version

Hallo zusammen,

ich möchte eine ASP.NET-Core Anwendung über meinen Buildserver (tfs2017) erstellen lassen. Während dem

dotnet restore

wird allerdings nicht die globale .NET Core-Version verwendet, was wiederum zu einem Fehler führt. (Der Fehler ist hier nicht relevant)

(die verwendete .NET Core Version habe ich in global.json hinterlegt)

Während meiner Recherche bin auf den o.g. Task gestolpert, welchen ich allerdings nirgends finden kann. Auch die Suche über den Marketplace brachte kein Ergebnis.

Meine Frage lautet nun:
Wie kann ich auf meinem Buildsystem meine .NET Core Anwendung erstellen? Ist der Weg über den o.g. Task der richtige?

Danke + Grüße

Kumatin tanaki - Grabt den Klappstuhl aus!

scoKi! Themenstarter:in
90 Beiträge seit 2009
vor 5 Jahren

(anbei noch das Bild bzgl. dem Marketplace)

Kumatin tanaki - Grabt den Klappstuhl aus!

16.807 Beiträge seit 2008
vor 5 Jahren

Ein Task ist der richtige; aber .NET Core SDK muss natürlich mit der/den richtigen Version(en) auf dem Build Agent installiert sein.
Das scheint mir hier nicht der Fall zu sein.

PS: man sollte den Restore nicht mit .NET Core, sondern mit NuGet machen.
NuGet geht besser mit Credentials und der NuGet.config um, was bei einem Build Server wichtiger ist als bei einer lokalen Entwicklung.

Hier mein YAML Snippet dazu. Kann man natürlich auch als Task umsetzen, wenn man noch kein YAML nutzen kann.

resources:
- repo: self

variables:
  BuildYAML.NuGetVersion: 4.7.1

  - task: NuGetToolInstaller@0
      displayName: "NuGet use $(BuildYAML.NuGetVersion)"
      inputs:
        versionSpec: $(BuildYAML.NuGetVersion)

  - powershell:   |
      Write-Host "Build ID: $(Build.BuildId)"
      Write-Host "Build BuildNumber: $(Build.BuildNumber)"

    displayName: "Build Info"

  - task: NuGetCommand@2
    displayName: "NuGet Restore"
    inputs:
      restoreSolution: '**/*.csproj'
      feedsToUse: config
      nugetConfigPath: NuGet.config

  - task: DotNetCoreCLI@2
    displayName: ".NET build"
    inputs:
      projects: '**/*.csproj'
      arguments: '--configuration $(BuildConfiguration) --no-restore'

Sprich: NuGet macht den Restore und build erfolgt ohne Restore.
Das spätere Test / Publish erfolgt anschließend ohne erneuten Build.

scoKi! Themenstarter:in
90 Beiträge seit 2009
vor 5 Jahren

Es ist die korrekte Version vom .NET Core SDK installiert. (siehe Anhang)

Hier noch der Inhalt von meiner global.json

{
    "sdk": {
        "version": "2.1.402"
    }
}

Kumatin tanaki - Grabt den Klappstuhl aus!

16.807 Beiträge seit 2008
vor 5 Jahren

Wozu brauchst Du denn ".NET Installer", was hast Du denn genau vor?
zum Build, Test und Publish brauchst Du nur den .NET Core Task bzw. NuGet für den Restore. Evtl. versteh ich auch Dein Problem nicht....? 🤔

scoKi! Themenstarter:in
90 Beiträge seit 2009
vor 5 Jahren

... es läuft jetzt... Ein Neustart vom Buildserver war nötig damit die korrekte SDK-Version gefunden werden konnte 😭

Mein Problem war dass wohl mit der falschen dotnet.exe gearbeitet wurde. Dieses Fehlverhalten konnte ich allerdings nur im Buildagent feststellen, denn lokal (auf dem Server) hat alles wie erwartet funktioniert.

Ich glaube ich hatte auch einen Denkfehler, denn der .NET Installer-Task ist -glaube ich- nur für hosted Agents. (das macht ja auch irgendwie Sinn)

Danke

Kumatin tanaki - Grabt den Klappstuhl aus!

16.807 Beiträge seit 2008
vor 5 Jahren

Nein, der Installer ist für die SDK Installation; wo spielt weniger eine Rolle.
Auf dem Agent ist es nun mal so, dass jede Phase isoliert abläuft. Und wenn der Agent kein entsprechendes SDK hat, dann kann das isoliert damit installiert werden.

Verwendet man also den Hosted Agent, dann kann man sich immer temporär seine Umgebung bauen; diese wird nach der Phase aber verworfen.
Das macht bei einem Self Hosted natürlich wenig Sinn.