3

I have a Windows server in which I installed and restored my dotnet core project successfully (at the time when I had outbound internet connection on the server). This instance of the application is running fine now.

Now Outbound internet access has been revoked as part of data center policy. I have VPN and Remote Desktop access, though. Now, I am trying to clone my working project into a separate folder and create another instance (on a different port).

But when using dotnet run on my new project folder (all content except few settings are same), I am getting this error:

$ 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.

I checked C:\Users\xxxxxx\.nuget\packages and all required packages are available.

Both projects are running under the same Windows user profile.

I have looked up various Stackoverflow questions on the subject, but all of them talk about a proxy setting, which is not my use case.

How can I prevent dotnet from looking up remote nuget server as all packages are already available in the local cache.

Is building the dll locally and running on server the only option? Cant I build it on my server in offline mode?

user1880957
  • 1,146
  • 3
  • 15
  • 29
  • why is building elsewhere and only running pre-built binaries on the server undesirable? – zivkan Mar 25 '19 at 14:03
  • In this specific case (when there is no internet), I would like to be sure about the source code from where a binary is built, so that looking at Exception stack traces will be easier. If I build somewhere, the source code and binaries may quickly go out of sync, especially if I have multiple simultaneous versions. Probably, a tight version numbering on binaries may help, but for now, I think building on server is working well for me. If server has internet, we do build automation by doing a git pull on server. So even here build on server seems to be the best option. – user1880957 Mar 25 '19 at 22:16

3 Answers3

3

Ok. As it usually happens, I got the solution after posting the question on SO.

Credits: https://blog.bigfont.ca/dotnet-restore-without-an-internet-connection/

Here is a brief:

dotnet nuget locals all --list

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

Then, use one of those sources during dotnet restore

dotnet restore --source C:\Users\bigfo\.nuget\packages\
dotnet build --no-restore
dotnet run --no-restore
user1880957
  • 1,146
  • 3
  • 15
  • 29
  • minor improvement is to use `dotnet run --no-build`. Since you build just before running, you can shave a little time off how long it takes your app to start. `dotnet bin\Debug\\.dll` would be faster still, but you may need to `dotnet publish` and run the dll from the publish directory rather than the build directory. – zivkan Mar 25 '19 at 23:20
1

An alternative to the solution you discovered, is to create a nuget.config file that removes all nuget sources:

<configuration>
 <packageSources>
    <clear />
 </packageSources>
</configuration>

This way, you don't need to use special command line arguments to restore or build.

zivkan
  • 12,793
  • 2
  • 34
  • 51
0

You can try to restore your solution or project with NuSave. It's meant for offline use.

Check my answer here: https://stackoverflow.com/a/41094054/2156569

Dharman
  • 30,962
  • 25
  • 85
  • 135
Elias
  • 449
  • 4
  • 9