N
noJedi
Guest
We have a build server that is failing because of SOMETHING... but running nuget from command line on build server for a handful of test projects (dotnet core and framework) return:
None of the projects in this solution specify any packages for NuGet to restore
Where as when running from TFS the log output is more akin to ... connect ETIMEDOUT 117.18.232.200:443
but does seem to depend on what version of nuget Restore we try (selecting "0.*" and advanced and trying various permutations provide a range of things from
[command]C:\Windows\system32\chcp.com 65001
Active code page: 65001
##[error]connect ETIMEDOUT 117.18.232.200:443
##[section]Finishing: NuGet restore **/*.sln
to similar lookijng:
Nothing to do. None of the projects in this solution specify any packages for NuGet to restore.
C:\Program Files (x86)\NuGet\nuget.exe restore -NonInteractive e:\_work\15\s\src\TestProj.sln -Verbosity Detailed
NuGet Version: 3.5.0.1938
MSBuild auto-detection: using msbuild version '14.0' from 'C:\Program Files (x86)\MSBuild\14.0\bin'. Use option -MSBuildVersion to force nuget to use a specific version of MSBuild.
Nothing to do. None of the projects in this solution specify any packages for NuGet to restore.
So my question(s) is:
Given we are restricted to TFS2017 and NO INTERNET FROM BUILD SERVER - I'm trying to figure out a SANE workflow for developers to build and use nuget, without requiring them to construct insane (brittle) scripts or processes for adding nuget packages in 47 different places and then (invariably) getting something wrong and spending weeks trying to figure out why dsomething that builds on their workstations wont work in the build server... given info here Overview of Hosting Your Own NuGet Feeds - we are okay with either package manager or local feeds, but we need to understand where/how to source things from dev machines in order to INIT/PUSH (or whatever) whatever packages that are finalized (because a dev machine will undoubtedly have 1000's of packages that are just experimented with and never used... although I THINK we currently have the space to accommodate this its always a consideration.)
a) are there any guidance docs on this?
b) is there a VS way of "checking in"/managing packages to a centralized feed/local directory?
Is this/these the only/recommended way to do this?
There's no way to include packages in TFS "by the sln/ide" somehow? Since I'm VERY used to seeing \packages\<all the packages active and old versions> and \packages.config in the solution folder mostly, I'm no longer sure how this works in VS or "which cache" is the RIGHT source anyway!
Its not rocket science to "get the files there" (nuget appears to be simple and robust structure and implementation wise) as long as you can
(a) find the package(s) you want and
(b) get it/them into the location/folder structure that the SLN/Project/TFS/MSBuild is expecting when it goes "looking for missing package referneces and can't find them in the SLN/Build working folder... (eg: Nuget Restore step, or "SOMEHOW" in a "library/reference" folder that is part of the "SRC" when the build server checks stuff out to build on an nuget.org isolated server...
The main bits I need answers/advice on is:
-- this is not the profile you're looking for --
Continue reading...
None of the projects in this solution specify any packages for NuGet to restore
Where as when running from TFS the log output is more akin to ... connect ETIMEDOUT 117.18.232.200:443
but does seem to depend on what version of nuget Restore we try (selecting "0.*" and advanced and trying various permutations provide a range of things from
[command]C:\Windows\system32\chcp.com 65001
Active code page: 65001
##[error]connect ETIMEDOUT 117.18.232.200:443
##[section]Finishing: NuGet restore **/*.sln
to similar lookijng:
Nothing to do. None of the projects in this solution specify any packages for NuGet to restore.
C:\Program Files (x86)\NuGet\nuget.exe restore -NonInteractive e:\_work\15\s\src\TestProj.sln -Verbosity Detailed
NuGet Version: 3.5.0.1938
MSBuild auto-detection: using msbuild version '14.0' from 'C:\Program Files (x86)\MSBuild\14.0\bin'. Use option -MSBuildVersion to force nuget to use a specific version of MSBuild.
Nothing to do. None of the projects in this solution specify any packages for NuGet to restore.
So my question(s) is:
Given we are restricted to TFS2017 and NO INTERNET FROM BUILD SERVER - I'm trying to figure out a SANE workflow for developers to build and use nuget, without requiring them to construct insane (brittle) scripts or processes for adding nuget packages in 47 different places and then (invariably) getting something wrong and spending weeks trying to figure out why dsomething that builds on their workstations wont work in the build server... given info here Overview of Hosting Your Own NuGet Feeds - we are okay with either package manager or local feeds, but we need to understand where/how to source things from dev machines in order to INIT/PUSH (or whatever) whatever packages that are finalized (because a dev machine will undoubtedly have 1000's of packages that are just experimented with and never used... although I THINK we currently have the space to accommodate this its always a consideration.)
a) are there any guidance docs on this?
b) is there a VS way of "checking in"/managing packages to a centralized feed/local directory?
Is this/these the only/recommended way to do this?
There's no way to include packages in TFS "by the sln/ide" somehow? Since I'm VERY used to seeing \packages\<all the packages active and old versions> and \packages.config in the solution folder mostly, I'm no longer sure how this works in VS or "which cache" is the RIGHT source anyway!
Its not rocket science to "get the files there" (nuget appears to be simple and robust structure and implementation wise) as long as you can
(a) find the package(s) you want and
(b) get it/them into the location/folder structure that the SLN/Project/TFS/MSBuild is expecting when it goes "looking for missing package referneces and can't find them in the SLN/Build working folder... (eg: Nuget Restore step, or "SOMEHOW" in a "library/reference" folder that is part of the "SRC" when the build server checks stuff out to build on an nuget.org isolated server...
The main bits I need answers/advice on is:
- whats the process (especially in dotnetcore, but really any VS project - since everything seems to be "use package restore" afaik) for KNOWING/GETTING the required Nuget packages referenced in a project that will be needed at build time? (my guess is everything that's not part of a .Net SDK... but again HOW to KNOW this?)
- whats the best/most manageable way to maintain this "listof references -> build server" process in day to day development/checking-in...? Is it just "c:\users\name\appdata\local\nuget\*.* ->xcopy -> \\someshare\writeonlyfordevelopers-to-just-add-copies-of-their-nuget-caches" and get all developers to contrib to this all the time... remembering to do this when additions of new packages are done...?
-- this is not the profile you're looking for --
Continue reading...