I had the same issue, Resolved by uninstalling sql server 2005 ,restarting the machine and reinstalling buildmaster as admin

Yes, good catch; I noticed that it was missing too when writing the same exact docs for the Otter Silent Installation Guide.

There's absolutely nothing on ProGet's end that would cause symbols/source to sometimes work, and sometimes not in this manner. Async implementation in C# is very complicated and brand new, whereas source/symbols, OTOH are a 20+ year-old technology, and extremely fragile. So, this is just a bug in VS2015, where it's not loading a remote symbol. You can verify this using something like Fiddler or Wireshark, and then see that it's not even attempting to load symbols with the async debug. Please do send this to Microsoft, so they can fix it in a future update.

I kept saying it couldn't find the package. Would you provide me the solution how I can go by getting this to work in Proget env? Thanks!

Variable values are "cascaded" by the execution engine at runtime. So, yes; if you define it any level (server, environment, deployable, etc)., it will resolve the most specific variable definition (e.g. a "build" variable overrides a "global" variable, etc).

Are you referring to connecting to the BuildMaster database, or connecting to databases you have configured in the Database Connections section within BuildMaster? The former cannot be done as it must use the account that hosts the web application or service. The latter cannot be done through the web application with Integrated authentication because BuildMaster does not impersonate users like that - you must use SQL Authentication and specify the credentials in the connection string if you want to go that route. The other alternative is to create a Change Script Deployment tool, and have the respective users run the tool as their own accounts, though of course this requires manual intervention.

This can be done with Administrative Edits on the Admin > Administrative Edits > Change Release Status page

That particular endpoint is not listed in the metadata for the NuGet API (https://www.nuget.org/api/v2/$metadata) so it is not implemented in ProGet. We may be able to add that at some point, but the best bet for paket would be to query the versions using the standard Packages endpoint, i.e.: /Packages()?$filter=Id eq 'packageName'&$select=Version

Yes, in the new/v5 execution engine, we wrote a variable function called $EnvironmentVariable(name) that returns the machine environment variable. The current/v4 execution engine does not provide agent/server context in a variable function, so there's no way to write a variable function that executes on a remote machine.

Great --- worth noting that, while BuildMaster most certainly has some solid build automation sever capabilities , it's primary focus is actually Application Release Automation, which has a broader scope. As such, a lot of organizations will use a dedicated continuous integration server (like Jenkins) and import/trigger builds using BuildMaster, and then securely deploy/deliver to environments.

ProGet's remote connectors only apply to NuGet endpoints, and will not connect to UNC paths like Visual Studio does. You can however simply create another feed, import all the packages in the UNC path into it, then set the feed storage path to that UNC path.

I was only able to reproduce the difference in packages returned when the casing of the id was different than the actual ID of the package, i.e. for jQuery: http://proget/nuget/Default/Packages?$filter=Id eq 'jquery' and http://proget/nuget/Default/FindPackagesById()?id='jquery' The Packages endpoint does not return remote packages because searching in this manner is case-sensitive, while it is not for FindPackagesById. The solution seems to be always use FindPackagesById, or use /Packages?$filter=tolower(Id) eq 'jquery'.

We removed that simply because it was confusing having both actions like that, your best bet is to use the Execute Command Line action, or a PowerShell script in the script library that does what you need.

This is a known issue in the NuGet client v3.2; it does not support integrated authentication (i.e. 401 challenges). This is supposed to be resolved in NuGet v3.3.

I would suggest to reset your admin password using the ProGet.Service.Exe, there is an option in there. And then try to set-up LDAP again.

Yes, but that's because project.json is used client-side; ProGet is really only sent the package id and version, not the project file.

I see, while that works for some projects, not all of our projects uses a build server which complicates the process of deployment. Thanks

It's only a UI issue that's preventing the checkbox from being displayed. Here is the workaround click on the Configure Symbol Server link check "Enable symbol and source server for this feed" uncheck "Strip symbol files from packages downloaded from this feed" uncheck "Enable symbol and source server for this feed" Save

We don't have a tutorial or guide on creating one, but it basically just involves making a UserDirectory class, and then implementing the methods. Note that in BuildMaster 4.9, we changed the interfaces a bit to be more inline with ProGet. You can use a disassembly tool to see how the current ones work, or request the source.

Yes, but note ProGet is licensed for each server it's installed on, so if you keep both servers active, then you'll need an additional license.