glisibor / elmah

Automatically exported from code.google.com/p/elmah
Apache License 2.0
0 stars 0 forks source link

Build fails without Internet connectivity #388

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?

1. Clone the main repo locally
2. Run build.cmd from the local clone root
3. Disable network adapter so there's no network connectivity
4. Run build.cmd from the local clone root

What is the expected output?

Expect the build to succeed at step 4 even when there is no network connectivity

What do you see instead?

Microsoft (R) Build Engine version 4.0.30319.33440
[Microsoft .NET Framework, version 4.0.30319.34014]
Copyright (C) Microsoft Corporation. All rights reserved.

Build started 10/03/2015 07:21:35.
Project "C:\ELMAH\nugetRestore.proj" on node 1 (default targets).
Project "C:\ELMAH\nugetRestore.proj" (1) is building 
"C:\ELMAH\nugetRestore.proj" (1:2) on node 1 (_UpdateNuGet target(s)).
_UpdateNuGet:
  "C:\ELMAH\tools\NuGet.exe" update -Self
  Checking for updates from https://www.nuget.org/api/v2/.
C:\ELMAH\nugetRestore.proj(35,9): error : The remote name could not be 
resolved: 'www.nuget.org'
C:\ELMAH\nugetRestore.proj(35,9): error MSB3073: The command 
""C:\ELMAH\tools\NuGet.exe" update -Self" exited with code 1.
Done Building Project "C:\ELMAH\nugetRestore.proj" (_UpdateNuGet target(s)) -- 
FAILED.
Done Building Project "C:\ELMAH\nugetRestore.proj" (default targets) -- FAILED.

Build FAILED.

"C:\ELMAH\nugetRestore.proj" (default target) (1) ->
"C:\ELMAH\nugetRestore.proj" (_UpdateNuGet target) (1:2) ->
(_UpdateNuGet target) -> 
  C:\ELMAH\nugetRestore.proj(35,9): error : The remote name could not be resolved: 'www.nuget.org'
  C:\ELMAH\nugetRestore.proj(35,9): error MSB3073: The command ""C:\ELMAH\tools\NuGet.exe" update -Self" exited with code 1.

    0 Warning(s)
    2 Error(s)

Time Elapsed 00:00:00.35

Additional information:

Tested on revision 8971e81fd3c5

Original issue reported on code.google.com by azizatif on 10 Mar 2015 at 6:25

GoogleCodeExporter commented 9 years ago
I think asking NuGet to update itself to the latest version on each and every 
build is somewhat excessive . In fact, would we even want that if some future 
version becomes incompatible? Perhaps NuGet.exe can be added to the tools 
subrepo where external binaries are maintained and where it can be upgraded one 
a need-by-need basis and to known compatible versions. This won't require 
downloading (Hg will take care of that) and perpetual updating, as well as 
patching for proxy issues (see revision 2b868f3d8a7f).

Original comment by azizatif on 10 Mar 2015 at 6:39

GoogleCodeExporter commented 9 years ago

Original comment by azizatif on 12 Mar 2015 at 5:49

GoogleCodeExporter commented 9 years ago
This issue was closed by revision 2454e3908c64.

Original comment by azizatif on 12 Mar 2015 at 6:25