The URL must be in the form http://host:port/ You are missing the "/" at the end of the url you entered.

Hi Christian, the information you posted had mentioned internal packages (Aeon Framework, etc), so I removed it That said, it wasn't an error message, but a JSON document that contained metadata information about packages. This is an expected response if you visit an API URL directly in your browser, and when the npm client relies on the JSON data. If you are receiving an error from the npm client, please make sure to share: the precise error message that npm client is using the precise URL that the npm client is requesting; you can get this by running Fiddler, and seeing the requests that the client makes Note that you will need to disable Windows Integrated Authentication at the IIS level, not just within ProGet.

i updated to PowerShellGet 1.1.1.0 and it solved my issues. Release Notes PowerShellCore support Security enhancements including the enforcement of catalog-signed modules during installation - Authenticated Repository support Proxy Authentication support Responses to a number of user requests and issues

That behavior definitely sounds suboptimal; we will investigate a bit further!

Well i finally was able to publish to our Powershell feed. I updated the PackageManagement and PowerShellGet modules to version 1.1.0.0. which were released a few days ago... 12 Oct 2016 I hope this helps .

Thanks a lot. It works ;)

That particular error message is a result of the connection string missing from the configuration file. Please ensure there is a key present in both web.config and in ProGet.Service.exe.config. Most likely, someone had inadvertantly deleted it from the configuration file when attempting to configure the server in IIS. <add key="InedoLib.DbConnectionString" value="Data Source=...;Initial Catalog=ProGet;Integrated Security=SSPI" />

Here is a solution for you guys : We implemented two open source tools that allow using bower package-based artifacts based on Alana's previous comment. They are still in active early development, but we are currently using them in our day to day work. ##Bower client https://github.com/WoltersKluwerCanada/proget-universal-bower-client This tool is packaging bower repositories into a .upack file It can also deploy to a proget repository ##Bower resolver https://github.com/WoltersKluwerCanada/proget-universal-bower-resolver This tool is an extension to bower which resolves/unpackages upack-proget feeds as bower feeds.

Yes, although this is currently extensible by extending the UserDirectory class.

See: http://inedo.com/support/questions/5371

This was removed when all the feed pages were combined (NuGet was the only feed type with an additional filter). We'll have to figure out a good way to add it back - it should be returned in an upcoming maintenance release of v4.4.

This is not possible, because that is not a package (but a git repository).

So being new to BuildMaster I was just restarting the windows service rather than using the site to stop the service. Admin > Manage Service :> Stop then Start fixed it.

We refactored a lot of the user-interface code for ProGet 4.4, so this is unfortunately a regression introduced due to those changes. I've logged the issue and it will be fixed in the next maintenance release.

Well if you used "npm" as a source, and then set up that as a registry in ProGet, then it could be a source.

Do you have specific guidance on how to setup the separate site?

Hi Mike, For GitHub, that source control path doesn't look right. It shouldn't have the ".git" in it. Are you using the selector? That should provide for a proper source control path.

You can temporarily use your key for this purpose, that's quite alight. Just enter the key in, and it will activate.

That worked! Definitely a big work around. We additionally had to set the AppPool for the new site to Classic and disable Forms Auth in the bindings.