Sure, happy to share the source, though you're welcome to use a disassembler or reflection tool as well -- easiest thing would to fill out the Source Code Request and we'll email it on over. If you only ever had a single, well-known database to work with, then hard-coding the connection string isn't too bad of an idea. You can always just update the code and redeploy the extension if it ever changes. But since you have multiple databases... I'm not sure if it's the best approach. Otherwise, consider that any property on your class that you mark with the Persistent will be displayed as a textbox and it will be available at runtime. So, two ideas come to mind: You could have a ConnectionSTring property, and just use that; that would be quite easy You could have DatabaseConnectionName property, and have that reference a database connection within your application; these are used to deploy database changes The DatabaseConnectionName will be a little trickier, as you'll have to retrieve it from the database, then deserialize it, then look at the object's connection string property. All of the Database ACtions do this, so you can look at their source code. You'd only want to do this if you're already using database connections.

It's hard to say why there's a discrepancy, but you can just re-index the entire connector. Just run the "FullNpmConnectorIndex " scheduled task, accessible from the admin portal. This will take several minutes. There will be a LOT of warnings about "missing versions property". You can ignore thesethey are effectively invalid npm packages that they return anyway with the index request.

Hi Damian, I completely that you shouldn't have to install a client to use TFS. Unfortunately, only the most recently (v2015) libraries are licensed for redistribution, and these libraries require .NET 4.5, whereas BuildMaster v4 only requires .NET 4.0. These libraries also don't seem to connect to earlier versions of TFS unless VS2015 was actually installed; it's a bit frustrating for us, and other ISVs as you can imagine. We have requested a redistribution license of the earlier libraries, and we can continue to explore getting it to work on our end, but it's not at all trivial. The currently solution is to GAC the assemblies yourself or to install the TeamExplorer 2013 client, which does GAC these assemblies.

Thanks Tod. I have run the provided SQL and can confirm that the View Purge History page is now working again. Cheers.

Visual Studio is filtering out your package because your project is targeting a different framework than your package is configured for. For example, you may have a net45 package and are trying to make a net35 project

I assume you can see the package when you browse the feed in ProGet? If so, then Visual Studio is filtering out your package because it's targeting a different framework than your package is configured for. For example, you may have a net45 package and are trying to make a net35 project.

Just a quick note to add to this, there is a setting on the Admin->Advanced Settings page called AllowDropPathImportOverwrite that will allow drop path packages to overwrite feed packages when set to true.

Yes, there is, but I'm afraid we don't have a detailed set of instrucitons on how to do that. Effectively though, you need to install the certificate to the host name you wish to use, and then change the url to https. However, we strongly recommend using IIS hosting if you want to do this, as there are plenty of guides available on how to do this, and administrators will be much more familiar with how to manage certificates.

I've got it working now, but only with the port. I'd rather not have to do that, but it will work for now. I'd really like to know why I can't use a reverse proxy in front of ProGet to avoid needing to specify port numbers.

There are some disk usage reports on the Manage Feed Page, but they do not break it down overtime and by month. We simply do not store disk usage statistics -- only the current space utilization. There are likely some third-party utilities that will tell you disk usage peaks, usage over time, etc; you can point those to the disk path that ProGet uses for internal storage.

The issue is that before nuget publishes a package, it goes to the feed source without authentication with GET. This fails with 401 and nuget starts asking credentials. In general, this means that we must have a view feed assigned to anonymous user, which is rather unfortunate but this is the issue with nuget.exe

The service must be able to restart itself and overwrite its own files.

Hmm, they are not different. Privileges are checked in the same manner regardless of the action that's being edited. If you're running into an error, it may not be related to privileges; perhaps send in some screenshots / more details to support at inedo dot com? If the plan is a global plan, note you need the [Plans_ManageGlobalPlans] task instead of the [Plans_ManagePlans] task.

If you want multiple builds of the same application going at the same time, then you won't be able to use the default, $CurrentDirectory. I would instead use a directory like, $ApplicationDirectory$ReleaseNumber$BuildNumber. However, once you deploy a release, you may want to clear $ApplicationDirectory$ReleaseNumber, otherwise you will end up with a lot of disc space used.

Oh, it works now. Thanks a lot, Alana!

This requires the [Events_ManageOwnNotifiers] task.

After updating to ProGet 3.8.1 the query http://192.168.216.1:25602/nuget/Packages()/$count?$filter=substringof('TESTTAG',Tags) now works as expected. Fixed by • PG-441 - FIX: substringof OData function arguments should be swapped Thanks.

SFTP essentially works over SSH; BuildMaster's SSH-based agents utilize SSH and SFTP to run scripts, actions, and transfer files; so, you can just set-up an SSH agent, and then transfer files as needed. FTPS, on the other hand, is completely different; it's basically FTP over SSL, so you can just use the FTP extension for that.

The reason you have to Get Latest is because otherwise if you built straight from the BuildMaster-managed "ScrRepo" directory, there would be artifacts from the SCM tool also included (for git, .git files), and other times added files from the BuildMaster build steps that you wouldn't want stored with the repo. Once you "Get Latest" somewhere, you can operate on a fresh set of files to perform whatever build tasks are necessary for deployment. Note the "Get Latest" action will essentially perform a clone or pull from BitBucket, then copy the files to the source directory of the action.

You don't have to install Visual Studio 2015 on the buidlserver. Install MS Build Tools 2015 will do it. https://www.microsoft.com/en-us/download/details.aspx?id=48159