Hello Chris, I don't think Bower feeds store anything on the filesystem (it's all in the database). I've filed PG-1256 to add support for Maven feeds being stored in package stores.

Hello Rob, I've released version 1.0.1 of the TeamCity extension, which should fix this (or at least give a more sensible error message). It should be available in /administration/extensions.

Hi, I'm afraid we don't have a step-by-step tutorial available at this time. It's enough of a challenge to always keep our tutorial screenshots up-to-date, let alone screenshots of Amazon's interface :( But if you get stuck, please let us know. It should be pretty straightfowrard and similar to a regular installation on a virutal machine,.

Thanks for letting us know. We are totally redoing our installer soon, so we will probably take care of it then! I think, generally, you might want to install SQL separately when going automated. When SQL fails to install, it's not so graceful, and it will be harder to tell what went wrong when diagnosing a failed ProGet installation

I'm not sure why, but looking at .11 and .12, they would only impact Windows installations, so you can just use .10 or upgrade to v5.

Not really I'm afraid... "Pulling with dependencies" would require implementing every dependency resolution algorithm of every version of every client, including the non-deterministic dependency resolution used by the npm client, and then somehow letting you select the algorithm version and the additional contet required by the algorithm (such as .net framework target versinon).

yes, after subscribing to one of our vulnerability providers like Sona OSSIndex or Whitesource (more coming later).

Hello, these errors are quite erare, but it can happen in dealing with randomly disconnecting web clients. The easiest thing to do is to set automatic recovery on the service. You can do this on the "Recovery" tab. You could also upgrade to iIS, which mas more transparent crash recovery.

It shouldn't, and if you're using SSL then it's encrypted traffic and nothing can "capture" it between... but keep in mind that ProGet is really only providing the server-side API. If you write a script (or use a tool) that logs all API calls to ProGet, or logs the full call to nuget.exe, then whatever you log is going to be logged.

I discovered one more error detail. BuildMaster logged an error that it couldn't use the folder (for the "get latest" copy on the build server) because it belonged to a workspace for a different account. I believe this is because I changed from using a domain account to a local account on the TFS server machine for the TFS connection from the BuildMaster machine. I deleted the workspace for the previous account. I edited the TFS connection in BuildMaster, entered the account information for the local account that I am now using, and saved it without doing a "Test Connection". Now, everything seems to be working okay. This installation of BuildMaster has been through many upgrades. Maybe someday I will do a full uninstall and a clean install of the latest version, and build new applications in that version, etc. If anyone needs to know, I found (and then deleted as needed) the TFS workspaces as follows (this is using TFS 2017 and Visual Studio 2017). On my workstation with Visual Studio 2017 installed, I ran the "Visual Studio 2017"-"Developer Command Prompt". This opens a command prompt window with all the appropriate environment variables set to allow the "TF" command to be used. Then, run: tf vc workspaces /owner:* /computer:* /collection:"http://URL-for-TFS-collection/" to show all the existing workspaces (this shows username and workstation as well). To delete an existing workspace, use a command like this (note that this uses the singular form "workspace" where the previous command uses the plural "workspaces"): tf vc workspace /delete /collection:"http://URL-for-TFS-collection/" WORKSPACE-NAME;USERNAME-for-the-workspace This will let you know if there are any pending changes in the workspace, and ask if you are sure you want to delete the workspace.

There is no additional ProGet configuration. Do note that PowerShell packages are actually NuGet packages behind the scenes, so you can always construct them and inspect them to make sure the manifest is being generated correctly before it's pushed to ProGet. Howeveer, also note that ProGet support uses SemVer2, which is slightly different, so makes ure you are following conventions that are compatible with both.

I've never seen this before, but it seems that Visual STudio is caching the result as to not hit the server. Maybe you can refresh or do a search from within Visual Studio to cause it to hit the server? Please share if you find the solution; you may be able to disable caching in VS, but I don't know how off hand.

The latest version was incorrect in the Den -- the latest cross-product TeamCity extension should be v1.0.0, and its legacy counterpart extension (i.e. TeamCityLegacy) should be v6.0.0. If it doesn't appear on the extensions page in BuildMaster, you can download and install it manually from here: https://inedo.com/den/inedox/teamcity If you go the manual route, note in the manual installation instructions it says the file extension is ".inedox", while in this case it is actually ".upack". Make sure there is no TeamCity.bmx or TeamCity.inedox in the extension path (TeamCityLegacy.bmx is OK if not a fresh installation of BuildMaster).

Once I flushed the browser cache, everything rendered as it should.

I see; my guess is that they have a custom-developed feed, and that feed is only supporting the limited/minimum number of queries required to get it working in the versions of Visual Studio of they support. In other words, it's not a proper feed. ProGet relies on a feed implementing the required API endpoints. In this case, your best bet will be to download the packages from the vendor, and then upload them into your ProGet repository.

It's obscured from view in the UI, but we must store the password so that it can be used for authentication. We may support a encrypted credential in the future, but if you have access to the ProGet server you will always be able to decrypt it.

There are three things that will cause this: Service not running Service doesn't have full control over drop path packages in drop path are invalid You can check the message center and see if errors are occurring.

Thanks for the good news!

Haha, I missed it by one minor verison. :-D Sounds good. Thanks for the quick response. Means I get to test my scripted upgrade process. :-D Have a good one.