If the files contained in a zip being transferred as a whole, shouldn't they be appearing almost all at once? It's like downloading a file from your browser... the files are sent are written to disk as they are being streamed. Unfortunately, sometimes the .exe files is relatively large that their size increases gradually, therefore probably locked by the anti-virus tools while the deployment is still going. That could happen; it's possible the AV tool is acquiring a lock between chunks. In this case, your best bet would be to disable the AV tool or, if not possible, then use the zip method you described.

If access is granted, then ProGet will routinely perform update checks. The url is http://inedo.com/pg. No specific package information is sent. If you block the outbound ports, then update checking will not be done. You will also have to activate your license manually. A lot of organizations do this; it's fine, but slightly less convenient.

The issue turned out to be a problem with uploading the package to ProGet. ProGet was reporting the package was available in our feed and we were able to download the package through the website however the package was not available through the nuget feed. Deleted and re-uploaded the package a couple times and it finally took. Issue resolved thanks to help from Inedo's great support team! Thanks!

This is handled by Release Package Variables within a Release Templates. They work basically the same, except now you can create multiple sets of required variables, depending on the template chosen at release time.

I would suggest to use the "Run MSBuild Script" Action instead. Then you can specify any of the properties.

This will be added as an Operation in the next release; look for [BM-2218]. IUn the mean time, the legacy action is a good work-around.

We had considered this as an option when designing templates, but decided against it because of the additional complexity required. The main challenge being, a user with Releases_Manage can already change the pipeline (or any other attribute) on an existing release. Making a "restrictive" template be a securable feature would require new permission attributes (and thus be more confusing/frustrating to use), and making it a convenience feature would give it the appearance of security (which is also bad).

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.