A License Key is always required. You can get one from My.Inedo.com. The ProGet Silent Installation guide gives the arguments to the installer; one of the options is to automatically request a key (just set Edition to Express or Trial).

Hello; this sounds like a NuGet/TFS question, I don't think we'll be able to help much. I would suggest to post to Microsoft forums or stackoverflow.

Thanks for clarifying that about the Nuget feeds. Awhile back I understood the behavior had been changed so new Nuget feeds did not function the same way. It was a discussion related to Jenkins so I may have misunderstood where the change was.

Restating the Proget's service fixed the problem! Thank you for your rapid response :) Regards.

Tod - thanks for the reply. We would definitely be interested in this feature in an upcoming release. Thanks.

You can just drop your npm packages in the configured drop folder; they need to be valid npm package,s which means <name>-<version>.tgz file format.

The TFS libraries used by the 4.9 and 5.x are different; sometimes, the workspace gets corrupted. To address this, it needs to be deleted on the server (unfortunately, deleting files on disk isn't enough). Please don't hesitate to contact support directly w/ any 5.x issues; it was a major upgrade, and while a lot of the changes were documented in various upgrade notes, we're quite familiar with common issues.

Uh, my current extensions path is C:\Program Files\ProGet\Extensions, not ProgramData. It's the Extensions.ServiceTempPath and Extensions.WebTempPath paths that are empty and ProGet is warning about. Here are the settings: [image: HCPtEyc.png] And the warning: [image: EUzrmf6.png] So now there's even more confusion. Should I move the Extensions directory from Program Files to Program Data? What about the ServiceTempPath and WebTempPath?

By default, Visual Studio 2012 and later does not use the source server even if the PDBs contain the correct source indexing information. To enable the source server, go to Tools > Options, Debugging, General and check "Enable source server support". This is disabled by default as it's a security risk. The mechanism for the source server encodes a command to execute into the PDB file, therefore untrusted PDB files could execute arbitrary code. Users have to opt in. See "Use Source Servers" in Specify Symbol (.pdb) and Source Files in the Visual Studio Debugger for more information.

I trying http://myExample.com/nuget/Default to http://myExample.com/myframework/packages . But i changed baseUrl = http://myExample.com/myframework/packages/nuget/Default

It would appear this isn't currently supported, you're right; we will add this in a future release!

We actually haven't tried using SBT just yet (in fact, I just learned about it from your post). But generally speaking, one of challenges with Maven is that it's convention-based, and doesn't have any documentation on the convention. So it's possible that SBT is using a slightly different convention than Maven or Ivy clients are. Moreover, different "packages" have a convention to behave differently... Would you able to attach Fiddler and see where some of the discrepancies in the request/responses might be? Sometimes it's incredibly obvious, and that might allow us to implement yet another undocumented convention. It may be easier to communicate over email, so perhaps fill out a ticket or just email us at support-at-Inedo-com once you have some details?

Great idea; I've resolved this in [BM-2314] , and it will ship in next release of BuildMaster. Now it displays "AppName::DeployableName"

Wow, cool usage! That sound something fairly general-purpose, so we might be able to incorporate it in the InedoCore extension as well. But yes, you can certainly use Variable Functions for that purpose; I don't believe we have anything that's quite as advanced, but we had definitely intended for usage like that. We just hadn't put in the logging facilities because none of the functions required logging (and the out-of-order logging may seem very strange). But as Dean mentioned, it's definitely doable. Note there is a EvaluateAsync method that might be more suitable for situations like this as well.

My best guess is that it's related to permissions- most likely the user account which is running the service cannot talk to the SQL database. There should be an error/exception in the Windows event log if this is the case.

What you described should work; the connection should be proxied through the agent server you selected. however, I see you also submitted a ticket... so we'll review via that!

There might not be a single API call for this, but there is the Variables Management API (were you can get the variables data), or you could use the Native API to list the deployables.

There are no built-in methods for this, but it could be done with a custom function or perhaps a powershell script that uses $ArtifactPath.

I was finally able to reproduce this - I had been using v5.5.0 of the Windows extension which does not exhibit this behavior. We will have a fix for either the Windows extension, BuildMaster or both shortly.

It looks like there was a regression in 4.6.0 that is causing this change in behavior. We'll have it fixed in ProGet 4.6.3, which will should be released by tomorrow at the latest.