J'ai un serveur Windows sur lequel j'ai installé et restauré mon projet de base dotnet avec succès (au moment où j'avais une connexion Internet sortante sur le serveur). Cette instance de l'application fonctionne désormais correctement.
L'accès Internet sortant a été révoqué dans le cadre de la politique du centre de données. Cependant, j'ai un accès VPN et Bureau à distance. Maintenant, j'essaye de cloner mon projet de travail dans un dossier séparé et de créer une autre instance (sur un port différent).
Mais lorsque j'utilise dotnet run sur mon nouveau dossier de projet (tout le contenu à l'exception de quelques paramètres est identique), j'obtiens cette erreur:
$ dotnet run C:\Program Files (x86)\dotnet\sdk\2.2.102\NuGet.targets(114,5): error : Unable to load the service index for source https://api.nuget.org /v3/index.json. [C:\xxxx\xxxx\xxxx.csproj] C:\Program Files (x86)\dotnet\sdk\2.2.102\NuGet.targets(114,5): error : A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond [C:\xxxx\xxxx\xxxx.csproj] The build failed. Please fix the build errors and run again.
3 Réponses :
D'accord. Comme cela arrive habituellement, j'ai eu la solution après avoir posté la question sur SO.
Crédits: https://blog.bigfont.ca/ dotnet-restore-without-an-internet-connection /
Voici un bref:
dotnet nuget locals all --list
dotnet restore --source C:\Users\bigfo\.nuget\packages\ dotnet build --no-restore dotnet run --no-restore
Ensuite, utilisez l'une de ces sources lors de la restauration dotnet
info : http-cache: C:\Users\bigfo\AppData\Local\NuGet\v3-cache info : global-packages: C:\Users\bigfo\.nuget\packages\ info : temp: C:\Users\bigfo\AppData\Local\Temp\NuGetScratch
une amélioration mineure consiste à utiliser dotnet run --no-build . Puisque vous créez juste avant de courir, vous pouvez réduire un peu le temps nécessaire à votre application pour démarrer. dotnet bin \ Debug \ serait encore plus rapide, mais vous devrez peut-être dotnet publish et exécuter la dll à partir du répertoire de publication plutôt que le répertoire de construction.
Une alternative à la solution que vous avez découverte est de créer un fichier nuget.config qui supprime toutes les sources nuget:
<configuration>
<packageSources>
<clear />
</packageSources>
</configuration>
De cette façon, vous ne besoin d'utiliser des arguments de ligne de commande spéciaux pour restaurer ou construire.
Je pense que je l'ai essayé plus tôt, mais cela n'a pas fonctionné. Je vais essayer à nouveau.
Vous pouvez essayer de restaurer votre solution ou projet avec NuSave . Il est destiné à une utilisation hors ligne.
Vérifiez ma réponse ici: https://stackoverflow.com/a/41094054/2156569
pourquoi la construction ailleurs et l'exécution de binaires pré-construits sur le serveur est-elle indésirable?
Dans ce cas précis (quand il n'y a pas d'Internet), je voudrais être sûr du code source à partir duquel un binaire est construit, de sorte que regarder les traces de pile d'exception sera plus facile. Si je construis quelque part, le code source et les binaires peuvent rapidement se désynchroniser, surtout si j'ai plusieurs versions simultanées. Probablement, une numérotation serrée des versions sur les binaires peut aider, mais pour l'instant, je pense que la construction sur le serveur fonctionne bien pour moi. Si le serveur a Internet, nous construisons l'automatisation en effectuant un git pull sur le serveur. Donc, même ici, construire sur un serveur semble être la meilleure option.