Laden...

Dotnet restore versucht (Standard-)Nuget-Pakete von Private-Feed wiederherzustellen

Erstellt von emuuu vor 4 Jahren Letzter Beitrag vor 4 Jahren 1.609 Views
emuuu Themenstarter:in
286 Beiträge seit 2011
vor 4 Jahren
Dotnet restore versucht (Standard-)Nuget-Pakete von Private-Feed wiederherzustellen

Guten Tag zusammen,

wie der Titel schon sagt verwende ich einen privaten NuGet-Feed (via Github packages) und baue das ganze via Dockerfile.

Im Prinzip funktioniert das auch, sprich der build läuft ohne Fehler durch und der Container wird am Ende erstellt.

Mein Problem ist nur, dass mein privater NuGet-Feed scheinbar als "primärer" verwendet wird. Beim Wiederherstellen der Pakete versucht er also sämtliche Pakete von nuget.org zunächst im privaten Feed zu finden.
Das führt dann zu knapp 400 Warnungen a la> Fehlermeldung:

warning Undefined: NAME_UNKNOWN:Package with name 'dapper' was not found in the package source 'username'

Mein nuget.config sieht so aus:


<?xml version="1.0" encoding="UTF-8"?>
<configuration>
  <packageSources>
    <add key="nuget.org" value="https://api.nuget.org/v3/index.json" protocolVersion="3" />
    <add key="GPR" value="https://nuget.pkg.github.com/username/index.json"  />
  </packageSources>

  <packageSourceCredentials>
    <GPR>
      <add key="Username" value="%Github_UserName%" />
      <add key="ClearTextPassword" value="%Github_Token%" />
    </GPR>
  </packageSourceCredentials>
</configuration>

Wie kann ich umgehen, dass erst im private Feed gesucht wird? Kann ich evtl eine primäre PackageSource angeben?

Beste Grüße
emuuu

2+2=5( (für extrem große Werte von 2)

16.806 Beiträge seit 2008
vor 4 Jahren

Gar nicht, und das ist auch by design so.
Es ist auch vollkommen richtig, dass Du zuerst in deinem privaten Feed suchst.

Sollte es nämlich zufälligerweise ein Paket auf dem öffentlichen Feed geben, das eigentlich vom privaten gezogen werden soll, zieht er sonst das falsche.

In Azure Devops sind die feeds so konfigurierbar, dass der Feed öffentliche Pakete liefert, wenn du selbst kein Paket im privaten Feed hast.
Das geht bei GitHub noch nicht.

emuuu Themenstarter:in
286 Beiträge seit 2011
vor 4 Jahren

Danke für die Info.

Aber schade, habe das Gefühl, dass der Build dadurch ne ganze Ecke länger dauert.

2+2=5( (für extrem große Werte von 2)

16.806 Beiträge seit 2008
vor 4 Jahren

Es ist aber die sicherere und die empfohlene Variante.
400 Warnungen hört sich aber auch nach einer sehr sehr großen Solution an... auch by bdesign? 😉

emuuu Themenstarter:in
286 Beiträge seit 2011
vor 4 Jahren

400 Warnungen hört sich aber auch nach einer sehr sehr großen Solution an... auch by bdesign? 😉

Naja der haut die Meldung für jedes System., Microsoft., usw raus.

2+2=5( (für extrem große Werte von 2)

16.806 Beiträge seit 2008
vor 4 Jahren

Restore fur NetFx oder NetCore?
dotnet cli oder nuget.exe?

emuuu Themenstarter:in
286 Beiträge seit 2011
vor 4 Jahren

Für NetCore, erfolgt im Rahmen eines multi-stage builds, düfte also dotnet cli sein:


FROM mcr.microsoft.com/dotnet/core/aspnet:3.0.0-nanoserver-1809 AS base
WORKDIR /app


FROM mcr.microsoft.com/dotnet/core/sdk:3.0.100-nanoserver-1809 AS build
WORKDIR /src
COPY NuGet.config ./
COPY FM.FireFx.Api/FM.FireFx.Api.csproj FM.FireFx.Api/
RUN dotnet restore FM.FireFx.Api/FM.FireFx.Api.csproj
COPY . .
WORKDIR /src/FM.FireFx.Api
RUN dotnet build FM.FireFx.Api.csproj -c Release -o /app

FROM build AS publish
RUN dotnet publish FM.FireFx.Api.csproj -c Release -o /app

FROM base AS final
WORKDIR /app
COPY --from=publish /app .

USER ContainerAdministrator

EXPOSE 5001


ENTRYPOINT ["dotnet", "FM.FireFx.Api.dll"]

2+2=5( (für extrem große Werte von 2)