Support

• ?

  Passwords are visible when using UseDpApiForPasswords=true
  buildmaster security • 9 Feb 2014, 19:40 • Dave Clarke   13 Feb 2014, 09:56

  6
  0
  Votes
  6
  Posts
  2
  Views

  ? 13 Feb 2014, 09:56

  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.
• ?

  Use Accounts from trusted domain for rights assignment
  proget ldap • 12 Feb 2014, 06:34 • Dave Clarke   12 Feb 2014, 12:43

  3
  0
  Votes
  3
  Posts
  16
  Views

  ? 12 Feb 2014, 12:43

  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 -----------------------------------------------------------------
• ?

  Proget allows login once using LDAP Auth, then crashes until IISRESET
  proget ldap • 12 Feb 2014, 06:27 • Dave Clarke   12 Feb 2014, 12:40

  3
  0
  Votes
  3
  Posts
  21
  Views

  ? 12 Feb 2014, 12:40

  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
• ?

  Application Names
  buildmaster applications deployables • 12 Feb 2014, 12:03 • Dave Clarke   12 Feb 2014, 12:20

  2
  0
  Votes
  2
  Posts
  8
  Views

  ? 12 Feb 2014, 12:20

  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.
• ?

  What is the purpose of the Local Repository path and remote repository URL in the Mercurial Source Provider settings?
  buildmaster mercurial • 11 Feb 2014, 14:48 • Dave Clarke   12 Feb 2014, 10:29

  4
  0
  Votes
  4
  Posts
  17
  Views

  ? 12 Feb 2014, 10:29

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

  Can't specify MSBuild target?
  buildmaster msbuild • 11 Feb 2014, 02:06 • Dave Clarke   12 Feb 2014, 00:39

  3
  0
  Votes
  3
  Posts
  6
  Views

  ? 12 Feb 2014, 00:39

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

  Validation error when modifying TFS issue tracker settings
  buildmaster tfs issue-tracking • 11 Feb 2014, 10:13 • Dave Clarke   11 Feb 2014, 18:24

  6
  0
  Votes
  6
  Posts
  4
  Views

  ? 11 Feb 2014, 18:24

  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.
• ?

  Mark all packages in a feed as a beta version?
  proget nuget • 11 Feb 2014, 10:45 • Dave Clarke   11 Feb 2014, 17:35

  2
  0
  Votes
  2
  Posts
  7
  Views

  ? 11 Feb 2014, 17:35

  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).
• ?

  What is the process for upgrading agents to the latest BuildMaster version?
  buildmaster agents • 3 Feb 2014, 16:37 • Dave Clarke   10 Feb 2014, 18:20

  3
  0
  Votes
  3
  Posts
  5
  Views

  ? 10 Feb 2014, 18:20

  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
• ?

  BuildMaster 4.01 Beta - "Build MSBuild Project" Broken?
  2 Oct 2013, 15:25 • Dave Clarke   10 Feb 2014, 15:04

  6
  0
  Votes
  6
  Posts
  49
  Views

  ? 10 Feb 2014, 15:04

  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.
• ?

  Directory Issues
  buildmaster • 5 Feb 2014, 14:13 • Dave Clarke   10 Feb 2014, 11:35

  2
  0
  Votes
  2
  Posts
  10
  Views

  ? 10 Feb 2014, 11:35

  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.)
• ?

  DB Change Scripts and Releases
  buildmaster releases change-scripts • 7 Feb 2014, 13:24 • Dave Clarke   10 Feb 2014, 11:08

  8
  0
  Votes
  8
  Posts
  5
  Views

  ? 10 Feb 2014, 11:08

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

  Updating to 2.2.10, "login failed for user..."
  proget update • 4 Feb 2014, 16:06 • Dave Clarke   6 Feb 2014, 10:06

  3
  0
  Votes
  3
  Posts
  16
  Views

  ? 6 Feb 2014, 10:06

  I'm not using Windows authentication, so user rights aren't the issue. The very first thing I did was to simplify the password, and that didn't work either. I know that the connection string works, because both the web application and the service function fine. I ended up doing a manual install of 2.2.10 to get me up and running (I needed the fix for NuGet 2.8).
• ?

  Nuget command line 2.8 push
  proget • 30 Jan 2014, 09:36 • Dave Clarke   5 Feb 2014, 22:24

  5
  0
  Votes
  5
  Posts
  29
  Views

  ? 5 Feb 2014, 22:24

  Hi, Thanks for the fix - I have tested in our environment and can now push with the nuget 2.8 client. Note: I did not test with the nuget 2.7 client Thanks again.
• ?

  MSBuild and web.config instances
  buildmaster net microsoft msbuild • 4 Feb 2014, 11:10 • Dave Clarke   5 Feb 2014, 20:25

  2
  0
  Votes
  2
  Posts
  4
  Views

  ? 5 Feb 2014, 20:25

  You can pull the artifact out of _PublishedWebsites, or try the "This is a Web Application" checkbox. There is a transform config file action available as well, though you can store your configuration files in buildmaster.
• ?

  _SVCTMP locks out
  buildmaster error • 4 Feb 2014, 11:04 • Dave Clarke   5 Feb 2014, 20:22

  2
  0
  Votes
  2
  Posts
  2
  Views

  ? 5 Feb 2014, 20:22

  It sounds like the files are being marked read-only from the source checkout; I would try to use the Set File Attributes action, and set read only = off.
• ?

  Powershell v2 after 4.0 upgrade
  9 Dec 2013, 21:36 • Dave Clarke   4 Feb 2014, 19:03

  5
  0
  Votes
  5
  Posts
  3
  Views

  ? 4 Feb 2014, 19:03

  Ross - BuildMaster runs powershell hosted under CLR 4. To work around this, try the following: C:\windows\system32\windowspowershell\v1.0\powershell.exe -Command { <YourScriptHere> } If you have Params: Param([string]$SolutionFolder) C:\windows\system32\windowspowershell\v1.0\powershell.exe -Command { Param([string]$SolutionFolder) <YourScriptHere> } Example for SharePoint: Param([string]$Identity) C:\windows\system32\windowspowershell\v1.0\powershell.exe -Command { Param([string]$Identity) Install-SPSolution -identity $Identity -AllWebApplications -GACDeployment -Force }
• ?

  How to use the Agent.Client parameter in the agent config file
  buildmaster agents • 3 Feb 2014, 15:44 • Dave Clarke   3 Feb 2014, 17:27

  2
  0
  Votes
  2
  Posts
  8
  Views

  ? 3 Feb 2014, 17:27

  You just need the BuildMaster server IP. BuildMaster agents are push-only, so only the BuildMaster service will initiate connections to agents. You shouldn't need to make any other changes to enable this.
• ?

  BM-1334 - Allow HTML in issue tracker descriptions
  buildmaster tfs issue-tracking • 3 Feb 2014, 10:47 • Dave Clarke   3 Feb 2014, 17:23

  2
  0
  Votes
  2
  Posts
  4
  Views

  ? 3 Feb 2014, 17:23

  We've added support for extensions to allow HTML issue descriptions as of 4.1.0, but we still need to update the TFS extension to indicate this. We should have it available within a day or two.
• ?

  Create text file from variable adds rubbish characters
  buildmaster actions • 2 Feb 2014, 17:50 • Dave Clarke   3 Feb 2014, 10:03

  4
  0
  Votes
  4
  Posts
  6
  Views

  ? 3 Feb 2014, 10:03

  We'll be adding some options to control text encoding for the actions which create a text file in 4.1.1, but in the meantime if you want to strip out the byte order marker, it should work to add a Search/Replace File Contents action immediately after the create file action that matches only the created file. Then, enable the Use Regular Expression option and put in a Regex that will match nothing, such as ^$ The Search/Replace action should strip out the characters at the beginning of the file. Alternatively, it would be pretty straightforward to create an alternative Create File action that never writes a BOM using the script repository feature added in BuildMaster 4.1.