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.

There is no erros in that log.

You can just use the license key on the new server.

For completeness: An alternate approach is to create a private source server and update to both the source server and to the Universal Feed from out in-house deployment tool. But we were hope that we could have pig-backed on what you already had. Oh well. Thanks.

Verified - the problem is resolved after upgrade to 4.6.1. Thanks!

https://github.com/PowerShell/PowerShellGet/issues/76

The problem is the CpuResetInterval parameter; it is missing the attribute to identify minutes, so it is treating it as seconds. I fixed this here, and it will be fixed in the next release of the extensionhttps://github.com/Inedo/inedox-windows/issues/10 AS a work-around, you can just specify the value in seconds (300 instead of 5). But this will become 300 minutes after you upgrade, so might be best to not set it for now.

An "Access to the path is denied" message is coming from Windows. Permissions aside, a likely culprit is anotherr process (anti virus, backup, etc) is locking the file and preventing access. Sometimes you'll need to use ProcMon to identify what this is. ProGet does not requests locks when reading files.