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.

The remote repo is not required if the local one should be used.

Ah, thank you so much, don't know how I missed that. :)

There shouldn't be. It's probably trying to create a new record for whatever reason and that is triggering the dupe check. There's no other provider with that name.

The "pre-release" conventions in NuGet is incredibly bizarre and changes from version to version. We do not recommend using it until they fix it. If you want all the packages to be pre-release, then you'll need to recreate all of the package files (name + nuspec file).

As an extra note, if you're upgrading agents from pre-4.0 installations to 4.X installations, it will require reinstallation. Please see the following KB article for more details: Upgrading Agents for BuildMaster 4.0

The problem with building the project with the _CopyWebApplication is that this legacy target did not copy over bin folder references if they weren't immediately referenced in the web project. The easiest way to get this to work correctly is to build the web application .csproj without checking "This is a web application project", then grab the output from the _PublishedWebsites\Project.Name\ directory - this will include any referenced libraries and be xcopied to the website's home path. We will likely change the behavior of "this is a web application project" to grab from here instead of whatever contortions it is currently doing from back in the ASP.NET 2.0 days.

In short, if you are relying on exact paths, you should use the ~\ syntax with directories (e.g. ~\Source, ~\BuildOutput, etc.) which represents an application-relative path and doesn't use any SRC or WRK directories. How the SRC and WRK directories work under the hood is as follows: The WRK directory is used as either the source or target directory if they are not both set to use their default paths. If there is a source and target path that are both set to the default, a SRC directory is used as the Source and WRK becomes the target. Before this, the contents of WRK left over from the previous action are moved into SRC in order to work with those files (you'll see "Source and Target directory same; splitting." in the logs when this happens.)

I went to the Releases table and fixed it by hand, and the sequence is correct now. Thanks.