It certainly might... but we haven't evaluated it for performance considerations, etc. Early on, we tried implementing a much more advanced filtering system (author, versions, etc), but it really put a strain on NuGet.org and became useless, so we didn't continue on that featureset. This is the first request for this specific filter, and it might be simple, but we'll definitely consider it.

Use https://registry.bower.io/packages as the connector URL instead of https://bower.herokuapp.com to resolve this. Bower must have changed the default service URL within the past day.

I have created an issue to add a feature to display a better error message when the base url property is invalid.  (PG-1107)

Hi Alana, Sorry to say that the solution you propose is crap. If teamcity can monitor on wildcards, example +:refs/heads/release/* I'm sure BM can somewhat do it also. I raised a ticket for the purpose. EDO-3200. Thanks Regards

I should clarify my last post, it does a Return Select 0 only when it is successful.

Hi Ken, Thanks for contacting us. We are aware of this issue and have traced it to be a bug in a database script, that only affects Linux. The good news is we already have issued a fix for the problem (https://inedo.myjetbrains.com/youtrack/issue/PG-1101), it just needs to be reviewed and tested.

I'm guessing that you're referring to this from the docs. I'll give it a try. ...Feed API key authentication is performed using HTTP basic authentication. To authenticate using a Feed API key, supply "api" for the user name and the API key for the password. feed api keys

Thanks for the reply. I didn't really think it was BuildMaster itself since I can deploy other smaller apps to the same server, same main web site, without issue. This particular app has a lot of files so I was somewhat suspicious of BuildMaster, memory, Windows or combination thereof having some issue with that large number. I am continuing to debug it and we have been looking at couple of possible issues. One thing that did come is a possible incorrectly registered DLL. Our IS dept had been registering it under the apps folder rather than the Windows/system32 folder but it's not certain that the one is this particular folder was the one registered. Unfortunately this is a live server so I have to use caution as to what I do on it.

Very nice to hear that. Thanks Alana.

Hi, Yep it was the Powershell script in the end!

Ignore. Someone had modified a property value incorrectly when combining two variables which was causing the Virtual Path to be invalid.

That's great news. Thanks!

Thanks. I was able to resolve this by running the full 4.8.2 installer which appeared to have a minor DB schema change. Once the DB was updated by the installer, ProGet was able to load from the web nodes when updated to the 4.8.2 binaries. I wish there was better documentation on updating ProGet in a NLB enviroment when there are updates to the DB.

Is it a "Portal PDB"? This is the new format and is not yet supported. If not, then the next step would be for you to submit a ticket with the NuGet package attached so that we can debug the pdb parsing.

You will need to open both ports; the npm api uses both HTTP and HTTPS.

Support for portable PDBs is currently an "open issue", and our initial research found that metadata information was undocumented, however since then it has been: https://github.com/dotnet/corefx/blob/master/src/System.Reflection.Metadata/specs/PortablePdb-Metadata.md Unfortunately at this time we don't have a timetable for if or when this gets implemented, but it is on our list.

The ProGet server doesn't modify packages, except to strip embedded symbols and source code if that option is enabled on a feed. It certainly doesn't modify a package such that the folder structure is flattened. Are you certain the package isn't flattened on the server, and in addition to that, actually being downloaded from ProGet at all (versus the NuGet cache or something like that)?

Just to clarify, .NET PDBs with "full" debugging information (i.e. Windows PDB format) are supported, it is just .NET "portable" format that is currently not supported. Support for portable PDBs is currently an "open issue", and our initial research found that metadata information was undocumented, however since then it has been: https://github.com/dotnet/corefx/blob/master/src/System.Reflection.Metadata/specs/PortablePdb-Metadata.md Unfortunately at this time we don't have a timetable for if or when this gets implemented.

We've resolved this issue by running the Inedo agent service on the new build server under the same account as the Buildmaster service on our main server.