Thanks Alex. Changing the type/user credentials did the trick. John

The "IsAbsoluteLatestVersion" is an undocumented NuGet attribute (well... it's in the source code), and has a confusing relationship to the quasi-documented IsLatestVersion attribute. Long story short, these these attributes tend to behave differently in different versions of NuGet clients, and our changes to remain compatible with the upcoming NuGet 2.5 caused a regression. You shouldn't have to change anything in your packages -- just post here if you find issues and we'll figure it out.

Are you able to browse for files in with the button? That sometimes does not work in VSS due to a lot of reasons (mostly, VSS does not provide very parsable output). You can just try typing in the exact path to the file $/MyProject/MyProject.csproj. The error may be a result of the file not correctly at that path.

I managed to get the source provider set up correctly but am now having a problem creating an application. I create a new .net app, but on the Source Control step (step 3) after I fill in the 'Path of solution or project' and click next I get an unexpected error. "Could not find file 'C:\Documents and Settings<username>\Local Settings\Temp<systemname>'. " I suspect this is because I originally installed as 'local system' and it doen't have rights to create the temp folder or something like that, Can you advise if this is the case and how to correct?

Not currently; but you could use a combination of actions (Generate RElease Notes, SEnd Email) to accomplsih a similar effect.

Hi Matt, The BuildMaster agent doesn't need to be installed on the TFS Server itself; whatever server you're using as your build server (could be same server BuildMaster is installed on) should have the TFS Client (Team Explorer) installed. As for the agent error... the "IIS agent" is "SOAP Based" --- so you'd want to make sure to add a SOAP Based agent from the BuildMaster servers page. To test that IIS agent is installed, you can do http://localhost:81/agent.asmx -- if that page shows up, the the agent is configured in IIS correctly.

I'm getting the error with both the bundled client and with Collabnet's Subversion client. I'll into the credentials of the App Pool & Service.

Hi Jan, Subversion does not support the "Apply Label" operation, so it complains about this. The UI is supposed to prevent you from using this action, but I think one of the recipes will create this action for you. Just replace the Apply Label / Get Labeled action pair with: Tag /trunk/mypath to /tags/%RELNO%.%BLDNO% Get Latest from /tags/%RELNO%.%BLDNO% Hope that helps, Tod

Hi Arian, BuildMaster's Database Change Management follows the steps outlined in Database Changes Done Right: http://thedailywtf.com/Articles/Database-Changes-Done-Right.aspx So, basically, each script is assoiciated with a release, and BuildMaster change script executer (action, manual, or self-contained executoer) can tell if the script has been run against a database by maintaining a metadata table. You can use this to configure all sorts of patterns, including what (I think) you're refering to. Alex

I could have sworn I had this set to use asp.net 2. Anyway updated in IIS and seems to be working now. Thanks

Hi David i got a similar error after installing, but in the web server process (inedobmwebsrv). Im my case it occured because the port i chose for the webservice (80) was already in use. A quick check revealed that skype was using port 80 ... quitting skype and restarting the server solved the problem for me. Cheers, Boris

Sounds good, by early next week we'll have some very specific documents that include exact deployment plans showing how we personally handle some cases with dependencies (specifically, how the BuildMaster installer deployment is automated, even though it depends on 4 separately-built BuildMaster extensions and BuildMaster itself). In the meantime, the feature as we've categorized it is Dependency Management: http://inedo.com/buildmaster/features/dependency-management

We've seen this happening with some connected feeds, and unfortunabely there is no workaround (aside from not using the connected feeds). This has to do with the translation of UTC dates between External Feeds (NuGet.org) and ProGet. We will have a new version (2.0.1) out today to resolve this.

Good question – we’ll have to fix this in our documentation. The BuildMasterUser_Role is for the BuildMaster Application (WebApp/Service) talking to the BuildMaster Database – doesn’t have really anything to do with deploying to databases. The database deployment bits of BuildMaster need only the permissions that the scripts need to run. You set up the database credentials in a your connection string (or, if you’re using integrated authentication, the service account) – so it’s really up to you. We generally recommend giving db_owner against the target database, since your scripts will generally do a bunch of things like create, alter, etc. But that’s up to you. The script will just error out if permissions aren’t there.

The connection string format is just a typical database connection string. You can follow the examples listed here: http://connectionstrings.com/ Specifying init as "yes" will initialize the database if it hasn't already been initialized. You'll need to specify this if you're running the changescripter tool against a DB for the first time.

Hi, Please ignore this question. The issue was ultimately down to the config file having unescaped percentage symbols within it and hence variable substitution not working. Regards, Jay

Currently, parameters are not supported by that action, though it is likely we will add them. For now if you drop the 'param($SolutionPath)' line it will work.

Ah, thanks; it would appear I wasn't on the latest version of NuGet... where this seems to be an issue. This is related to the aforementioned issue and should get resolved by PG 2.0.

I talked with our IT HUG and he changes the MAC address setting from dynamic to static. I hope this will solve the problem. Thank you.

This is a known issue (PG-61) that seems to have started with NuGet 2.2 (maybe 2.1?); our notes read as "if a package has a pre-release version and a stable version, only the pre-release version is shown." It's scheduled to be fixed in the next maintenance release.