That error message is coming directly from your remote SQL Server, and it can mean several different things: wrong password is specified for sql_tg_proget on that server the tg_proget database does not exist on that server the sql_tg_proget user does not have access to tg_proget on that server SQL Authentication is disabled on that server, or another setting is preventing the application from logging in to the database using that name/password; for security purposes, SQL Server does not log these reasons to the client In this situation, your connection string needs to be modified to either point to the correct server, and/or use the correct username, password, and database, or the sql server needs to be configured to permit that connection string. There is no other configuration required (or even possible) on the application side to connect to the database. Only the connection string.

Hi Hans... this requires WMF5.0 : https://www.microsoft.com/en-us/download/details.aspx?id=50395

Yes, definitely; BuildMaster supports any type of file, such as Java .properties as well. You could set up with a simple replacement syntax, or just have a separate .ini instance file for each environment.

Hi Stuart Could you let me know the settings you're using in the upload proget package build step in your Jenkins job and if you've changed any of the default settings in the advanced section of the build step? I've not been able to come up with a combination that causes an exception to be thrown in UploadPackageBuilder.java. Regards Andrew

Of course, it's possible that NuGet 3.4 works with your proxy servers differently. I don't know. But in either case, it's most definitely a bug in the 3.4 client; a "nuget push" is a very simple HTTP POST or PUT with a body containing a single file with a multi-part encoding, so if you are getting that error, then no file is being sent (unlikely multiple files). You can use cURL or any other tool to send file to ProGet like that. There is nothing we can change on the ProGet's end to work-around this bug, so please report this to the NuGet team. You should use Fiddler or Wireshark to capture the output from NuGet, and find precisely what requests it is struggling with, so you can share it with them.

Just use the API/Feed endpoint that you would otherwise use for that feed type as a connector.

Take a look at Changing an Inedo Product's URL with the Integrated Web Server; after setting up a certificate, you can follow this guide to register https urls, and edit the configuration file to listen on port 443 for ssl.

You may want to check hte IIS error logs to see if anything pops-up; there is no additional configuration needed on the ProGet side (just run the installer), and it's most likely the case the request isn't even being routed to PorGet software. IIS has so many configuration options, that it's possible something was inadvertantly misconfigured at a root level. As an alternative, you can just use the Integrated Web Server, and then try to later upgrade to IIS once you get things working.

It's scheduled for release later today. in the mean time, you can use PowerShell or not set that particular property that requires a timespan.

I understood. Thank you for your post, Alana.

At this time, the NuGet team has no plans to make the v3 API publicly consumable, and will support the v2 API indefinitely as the public API; as such, we have no intention to reverse engineer and attempt to implement a private API. Note this it is entirely a "behind the scenes" transport mechanism (JSON vs XML) and makes no difference at all from a usage perspective.

You could install the SQL Tools, but there may be a osql.exe installed that you could have command-line access to.

Yes, that would do it; the $WorkingDirectory() function will always ends return a slash. So, you'll want to definitely trim it; you can do this with a $PSEval, but we will have built-ins soon - https://github.com/Inedo/inedox-inedocore/issues/9

In v5.4, we will have a "Custom Setter" for template variables which would allow for this scenario. Our primary use case is to allow for a searchable list of packages from ProGet, or builds from teamCity/Jenkins/etc to be populated.

David, great to hear! Aris, would you mind opening a new thread, or submitting a ticket (maybe easier to back and forth on email); I think I understand what you're suggesting. We'll definitely have to re-engineer something to support this sort of usecase, so any more details on how it should behave (from the UI, pipeline JSON, etc) would be helpful!

This isn't currently supported, but we can add an endpoint for that. Sounds like it would fit in the Package Deployment API (see roadmap). Of course, we can always ship these in earlier maintence releases, they just won't be documented and may change before final releases.

Thanks; I can see the issue, it appears if the environment is the same, then this may occur, depending on which one fails first. We will investigate.

Please ignore this question. It works now.

Great! Thank you for the quick response, and also for an excellent lead time. Impressive!

Hi Dean, thanks for your reply. Redownloading the installer has resolved the issue. Best Regards Alex