Hello Charles, upack pack expects a directory, not an individual file, so the command should be: upack pack C:\location_of_upack_json_file C:\directory_containing_my_setup_exe --targetDirectory=C:\mytargetDir\build_artifacts

Hello Robert, Thanks for the bug report! I've filed this as PG-1047. NPM feeds were showing the download count as the total for all NPM packages, not just the ones associated with that feed.

Yes. Of course you will not be able to connect to NuGet.org as connector, or inedo.com for automatic updates and license activation. You can request a key from my.inedo and enter it in the installer.

Same issue here, tried with Local Users, LDAP and Windows AD, with and without API. Did anyone managed to solve this? Thanks!

At this time we do not have a Go repository planned. This is the first request for a private Go package manager, and we have other ones ahead in terms of priority (PyThon, etc). But we will consider it for the future.

Follow up question, would the file that is in the artifact already have had the key pairs replaced when the artifact was made? And do I need to deploy the config file first and then make the artifact or will it just automatically be part of it? What I'm needing to accomplish is deploy it using the same way if possible without having to replicate storage of the config in different apps. So replacing the key pairs under the new app if possible. I know it would make more sense to make it part of the original apps but I cannot here because this is strictly on-demand deployments and we want to keep the restrictions on the pipelines requiring deployment to stages in order for the real apps.

It's certainly possible in BuildMaster, but it's not a common workflow anymore. We have considered extending support, but the market generally is moving towards "many single-purpose tools" than "multi-function tools". The general flow these days looks like this: Source >> CI >> Package >> Deploy In this case, ProGet is the Package repository and BuildMaster is the deploy tool. The advantage to this workflow is that, the CI tool need only "create a validated package", instead of trying to deploy. By the way, I also recommend you to look at GitLab; we switched to it after extensive evaluations of similar "simple" tools (GitHub, BitBucket), as well as the enteprrise tools (Perforce, etc).

I tried on a different machine which runs Ubuntu 16.04.2 LTS and for some reason I no longer see the problem. Even more surprising is that both machines are virtual machines built from the same VirtualBox image. The 16.04 one was recently upgraded from 14.04. I guess 14.04 image is somehow broken and was fixed during the upgrade. I guess that's answers my question.

Yet one more solution (after 6+ months). After trying all the possible solutions mentioned above - if you are still seeing the error: Response status code does not indicate success: 405 (Method Not Allowed). then most likely you need to disable your WebDav IIS plugin. You may either remove the IIS feature from the machine or if you need to keep the feature you may disable it only for this website. You may do this by editing the Web.config file (by default located here: C:\Program Files\ProGet\WebApp) and add two entries as shown below: <system.webServer> <modules> <remove name="WebDAVModule" /> </modules> <handlers> <remove name="WebDAV" /> </handlers> </system.webServer>" Note: the Modules and Handlers section should already exist, you only need to add the line <remove name="xxx"> for each section. I think Proget Dev team should integrate this in the Web.config by default to prevent future issues.. Thanks HS

This is not a supported setting to change, and you won't find anything useful by changing it; it's only intended for diagnostic purposes when working with an Inedo engineer. The specific behavior may change from version to version, and we don't want to document how it works or support a particular behavior. if you're really curious to know, the best bet would be to look at the source code, and see how it's used; that's how we would use it ourselves.

You'll need to run bmdbupdate.exe. It doesn't need to be run on the database server itself; the user that runs it must have dbo permissions to the proget database.

This is currently on our roadmap

There appears to be a problem with the windows service manager. I recommend you to reboot the server, and try again. If that fails, you can use the manual installation instructions.

Ah, I see it. I use Caddy as my reverse proxy which doesn't support this feature.

Thanks for the response! Gotta say, I'm impressed that y'all take the time to answer questions like this, even when they're from free-license users.

I figured that by remove Windows Auth and going back to build-in security but that won't work for my scenario. I've moved to an azure registry and it's working fine. I'm sorry I can't use Proget for all my feeds though. Cheers, ET