It's hard to say why there was an issue uninstalling, but to clean up, just follow the manual install steps in reverse, and Strange. It doesn't really do that much. Anyway, if you want to fully manually uninstall here's how: Ensure the service is stopped: INEDOPROGETSVC Uninstall services by executing "ProGet.Service.exe" from an admin command line in the ProGet\Service directory, and followign the prompts Delete the Service and WebApp directories, (and anything else under ProGet you don't want to keep) Delete the HKLM\Software\Inedo\ProGet registry key Delete the HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall\ProGet registry key If using IIS, delete the ProGet web app and app pools If you really want to delete everything , you can also drop the ProGet SQL database

Currently, NuGet.org's API does not support this sort of filtering, so it's not feasible for us to do this via a connector. We do have an item on our ProGet roadmap for downloading the entire NuGet.org index, which would then make such a filtering possible. In the mean time, the best and easiest way to handle this workflow is to build a "curated feed" of approved packages.

Very helpful! Thanks :)

In the v4 execution engine, your best bet is to create a file with that name, and then read the file contents into a variable. In the v5 engine, you will be able to export variables via powershell a little easier (example: PowerShell & Scripting from Otter docs.

NPE has several bugs that prevent it from being used in many environments and seemingly basic scenarios, including this bug. Unfortunately the NPE is no longer maintained, and hasn't been changed in years, so it's unlikely this will ever be fixed. There is absolutely nothing we can do about it, as it's a client bug.

Thanks Alana, i'll check that out.

If you look at any package detail page on nuget.org or chocolatey.org they show "Authors" and "Owners" (packager) and in the sidebar they show links for "Software Site", "Software License". If there is an icon link in the package, that icon is actually displayed (in gallery as well as detail page). Their "tags" are also clickable to search by tag. It would be nice for Proget to be on parity with the Nuget Gallery as that is the defacto user experience. A bit more value add would be to allow me to create custom elements in .nuspec and somewhere on ProGet indicate if they display as either a main body item or a link on the left hand bar. These items would improve the browsing experience to help make it more useful as a package catalog.

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'.