Yeah we can add those. I've filed this issue as BM-1396.

Not exactly - it's simply used instead of reading the connection string from the appSettings file. To move the database, just back up and restore it to your new server and change the connection strings in the web application's Web_appSettings.config file and the service's App_appSettings.config file. Whatever service account is running the application pool or running the BuildMaster web server service needs to be granted the BuildMasterUser_Role for the new database as well.

There is no way to tell from that error alone what the problem is. Some questions to help troubleshoot: is the other feed also a ProGet feed, or some other type of a feed? Can you actually browse to and get packages from that other feed? Can you connect to the NuGet.org feed from the feed that current has the broken connector?

You can add an ExtensionIconAttribute assembly attribute to your extension for a custom logo that accepts a URL to the image in its constructor. Note that this attribute requires the BuildMaster SDK v4.1 or later. If you want to embed your image directly, you can convert the URL to a base64 string and embed it using a tool like this one: http://webcodertools.com/imagetobase64converter

Hi Max, That sounds like a great idea. Unfortunately, there is no SC Provider that is associated with a particular build; that is, there'd be no way (aside from looking at logs) to know which ProviderIds were used in deployment plans executed over a build's lifecycle. You could capture this as a variable, however. If you haven't already, make sure to see how the SourceControlProviderActionBase actions work; you can find their code thru a decompiler (BuildMasterExtensions assembly), or just ask for it and we'll email you. Hope that helps, Alex

After further investigation and help from support I found the issue. I am using the NuGet package and publish Visual Studio extension to create my NuGet packages. This is really just some MSBuild targets and supporting files that get included in your project/solution. What it does is use NuGet.exe to push the NuGet package and the symbols package. After further investigation (and help from ProGet support) I found that my packages were getting overwritten by the symbol packages. The reason for this is that NuGet.exe strips the symbols from the name of the NuGet package when it pushes. ProGet therefore has no way of knowing this is symbols package and since I have overwrite of packages enabled for the user that pushes the symbols package overwrote the primary package. The symbol package for obvious reasons only has the dll, pdb, and source files hence it looked like the content files were stripped. Since I didn't want to revamp my entire build process (it was already setup for about 30 projects across a number of solutions) I came up with an alternative approach. Since ProGet retains the symbols and source in the NuGet packages (it only strips them when they are downloaded) I created a separate feed for symbols and source (I named it SymbolsSource). This ends up working out beautifully. I push NuGet packages to Default and symbols to SymbolsSource and setup Visual Studio accordingly. I would like to give kudos to support for helping me out on this!

Sorry - I did mean .org in my previous response :) Still however, I am not able to reproduce this behavior that sets the Remote Repository to something other than what was typed in unless I edit an existing repository and do not save the edited values. If you could detail the exact steps you did (e.g. 1. Click Create New Provider button, 2. Input values abc and xyz, 3. click Test Connection, etc.) that would help tremendously.

In this case, you should install ProGet to IIS (it's an option in the installer), and configure SSL from there.

It's working for us too. Thanks!

Hi Richard, Unfortunately it doesn't look like the exact error is being reported, but it definitely happening when the database schema is being initialized. Based on the error code, it looks like it's happening at the database driver level has something to do with updating the database schema. Perhaps there's an error connecting to the database, or something? Your best bet might be to tryagain, or use try the manual install process for the database.

I appear to have found the answer. On a windows server you need to set up a network share with the git repository you want to share. Then, on the BuildMaster provider page, set the remote URL to file:////YourServer/path/to/git This will allow you to create a git provider that's on the same network as your BuildMaster server without SSH or git protocol.

Hello, We have some case studies listed here http://inedo.com/buildmaster/case-studies, and we've also put together a list of featured users here: http://inedo.com/users. Steve

Thanks, Tod, that was the conclusion I came to as well. I created it, issue #3.

Setting up ProGet in what is essentially a load balanced environment is detailed here: http://inedo.com/support/kb/1073/load-balanced-and-high-availability-installation-of-proget. Note that this type of setup requires at least 2 ProGet Enterprise licenses (one for each server node). That being said, ProGet itself does not handle synchronization in the manner you described and symbol/source serving is not designed to work for connected feeds. If you wanted to sync ProGet servers manually, all you need to do is copy the packages on disk from one feed to the other.

To install ProGet, you must be an administrator and have db_owner privileges against the target database.

Spot on! Its working. I feel really sad when I think that I was troubleshooting this issue for the past 1 hour. I know I was doing something wrong! But thanks a lot! :)

We have released BuildMaster 4.1.3, which addresses this issue: BM-1380 - Hide passwords from clients when UseDpApiForPasswords is enabled So as long as that option is enabled, stored passwords will never be accessible from the UI.

I will copy my answer to another question "PROGET ALLOWS LOGIN ONCE USING LDAP AUTH, THEN CRASHES UNTIL IISRESET" here since i'm pretty sure they're tightly related: --- snip ----------------------------------------------------------------- Thinking about your answer, i'm pretty sure that this is not a problem with the .Net API. I guess that is tightly related to the second question, I've filed here (see "USE ACCOUNTS FROM TRUSTED DOMAIN FOR RIGHTS ASSIGNMENT"). Whenever i open a browser on machine.dev.local and go to the ProGet Server (located in dev.local - see explanation of the infrastructure in above mentioned question), I'm authenticated as company\John (which is a user of a different domain but dev.local has a trust with company.com). As long as the ProGet implementation assumes the accounts used for authentication to be members of the domain where proget is located in (and i guess that's the case!), you will get null back from the .Net API. So for scenario like mine, this would fail (principal = null): var ctx = new PrincipalContext(ContextType.Domain); var principal = UserPrincipal.FindByIdentity(ctx, @"company\John"); and this would work (principal has the expected value): var ctx = new PrincipalContext(ContextType.Domain, null, "company.com", @"AnAccountFromCompanyDomain", "TheAccountsPassword")); var principal = UserPrincipal.FindByIdentity(ctx, @"company\John"); I guess you need, you just have to make the account domain configurable for cases, it differs from the domain where ProGet is located in and let the user apply credentials fro Account- Queries in the Account- Domain and then use the example above to query and you're done. Right? ;-) So big question for me now is if and when can i expect a version that supports our scenario. As i told Karl last week, we're looking for a commercial solution to replace our Inhouse- Solution to reduce our maintenance efforts for package management tools. Unfortunately we run out of time for the decision to go with an external tool or to keep our internal stuff running. Would be great to get some info about if and if yes, when we can expect a ProGet version that fits our needs. Best Regards, Joachim --- snap -----------------------------------------------------------------

Thinking about your answer, i'm pretty sure that this is not a problem with the .Net API. I guess that is tightly related to the second question, I've filed here (see "USE ACCOUNTS FROM TRUSTED DOMAIN FOR RIGHTS ASSIGNMENT"). Whenever i open a browser on machine.dev.local and go to the ProGet Server (located in dev.local - see explanation of the infrastructure in above mentioned question), I'm authenticated as company\John (which is a user of a different domain but dev.local has a trust with company.com). As long as the ProGet implementation assumes the accounts used for authentication to be members of the domain where proget is located in (and i guess that's the case!), you will get null back from the .Net API. So for scenario like mine, this would fail (principal = null): var ctx = new PrincipalContext(ContextType.Domain); var principal = UserPrincipal.FindByIdentity(ctx, @"company\John"); and this would work (principal has the expected value): var ctx = new PrincipalContext(ContextType.Domain, null, "company.com", @"AnAccountFromCompanyDomain", "TheAccountsPassword")); var principal = UserPrincipal.FindByIdentity(ctx, @"company\John"); I guess you need, you just have to make the account domain configurable for cases, it differs from the domain where ProGet is located in and let the user apply credentials fro Account- Queries in the Account- Domain and then use the example above to query and you're done. Right? ;-) So big question for me now is if and when can i expect a version that supports our scenario. As i told Karl last week, we're looking for a commercial solution to replace our Inhouse- Solution to reduce our maintenance efforts for package management tools. Unfortunately we run out of time for the decision to go with an external tool or to keep our internal stuff running. Would be great to get some info about if and if yes, when we can expect a ProGet version that fits our needs. Best Regards, Joachim

In general, we recommend going with a "business context friendly" name for your application. There are several reasons for this, but it mostly goes back to the fact that it's a lot easier to share/consume friendly names. There are times, however, when it makes sense to match name/code/scm/etc., and this is usually when there's a "conventions" approach. For example, our extensions (see BuildMaster Implementation Specifics) use the application name to determine a lot. But this usually only makes sense when you have a lot of "cookie cutter" componentized applications (such as in our case). So for your example, I would say name it "Awesome", and then have multiple deployables within that application. I wouldn't use the word "solution" unless it's actually part of the business name. For us, the application name is "BuildMaster" not "BuildMaster Solution"... even though our codebase has a "BuidMasterSolution" folder and a "BuildMasterUbserSolution.sln" file.