|
|
Thank Bog I just bought 1000 shares of a well established supplier of candles in the UK! I'd invest in warm, fuzzy sheep, too, but I'm sure you already have your favorites - for warmth, of course. Wise choice, renewable and organic! 
Will Rogers never met me.
|
|
|
|
|
Barrier boy is for jam or gin? (6)
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
I'm thinking of setting up a private NuGet server for our development department.
TeamCity 2017.1 seems to have NuGet support, but the documentation is confusing, it gives the impression that this is only for self built NuGet packages which are stored with the build artifacts.
Anyone has got any experience with this, can I use it for standard NuGet packages ?
|
|
|
|
|
Where I work we use Teamcity for our own custom built libraries with Nuget packages.
It is possible although I am not on the team which configures the build server - so it is possible but not a very helpful answer... sorry 
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
modified 27-Nov-18 3:35am.
|
|
|
|
|
|
Thanks! useful information, but I'm still wondering how to use standard NuGet packages with TeamCity ...
|
|
|
|
|
Well, this was just some shameless self-promotion 
I'm afraid that my TC knowledge is limited to clicking on the buttons to get my stuff built, so I can't be of more help than this.
kr,
Gaston
|
|
|
|
|
|
On nuget there is a package Nuget.Server (or something like that). It allows you to create your own private Nuget feed very easily.
There is a little bit of documentation on how to use it.
After hosting it, you can use it in the same way as official nuget feed.
You can also automate publishing by adding scripts for that to your CI.
Of course you can also use paid services like MyGet or something.
No more Mister Nice Guy... >: |
|
|
|
|
|
|
RickZeeland wrote: as it needs ASP.NET / IIS (my boss is allergic for that)
You did not mentioned that in your question  and I think that Nuget.Server is easiest solution there.
Anyway I am glad that you found what you were looking for.
Cheers.
No more Mister Nice Guy... >: |
|
|
|
|
|
True, thanks for the input anyway
|
|
|
|
|
I just noticed you can actually purchase NuGet Server[^] for $9 which is a wrapper on the Nuget.Server package and allows you to run it as a Windows service without IIS (it has its own web server)
|
|
|
|
|
Nah, we can get ProGet for free 
|
|
|
|
|
I've been using ProGet for just over a year and I would absolutely recommend. It took away all of the (many, many) headaches we suffered under NuGet.Server.
- Installation/upgrade is a breeze with the installation wizard. Automatically installs/configures SQL server and all dependencies
- Option to run on its own integrated webserver instead of IIS
- Support for many types of packages in addition to NuGet - we've had great success using the extensible UPack format for client application deployment
- Simplified support for NuGet symbols - just push the *.symbols.nupkg to ProGet and it sorts everything out. No need to push the regular nupkg file to one place and the symbols file to another place.
|
|
|
|
|
We use Proget as well - as long as we still don't have Tfs /Azure DevOps.
So far So happy with it. Once the symbols didn't work anymore after changing to .net core project files, but they fixed that soon enough.
And user authentication might be a bit too simple in the free version. There's no restraining who may push packets and who may only have a look. Well, for being free it's great enough
|
|
|
|
|
|
|
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
