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.

Hi Steve, Thanks for the reply, I think this is best illustrated with a screenshot or two, which I shall send to your email address as mentioned in the other answer. Thanks, Adam.

Feel free to contact us at support AT inedo DOT com as well... sometimes easier to have back-and-forth discussions for feature ideas :-) Interesting idea; we haven't had this requested before. We'll be introducing an SDK in ProGet 2.0, so that could make things like this easier to do as well. We'd be curious to see some specifics, or some packages you know that have complex enough dependencies that a graphic would help.

We wanted to include versions in our Connector Filters, but it wasn't really practical. If memory serves correctly, NuGet's ODATA implementation sees version numbers as strings, thus you couldn't do version ranges or anything like that. I think someone on our team submitted an issue to NuGet about this, but as far as I know it's still treated as strings. So, until then, your best bet is to manually craft your feed. One trick someone suggested was to create a feed with a connector to nuget.org and then download packages to a "Allowed NuGet PAckages" feed (no connectors) --- both of which share the same local directory.

In ProGet 1.x releases (current), package metadata is not stored in the database -- it's just in-memory, and is recreated when the server restarts. In ProGet 2.x (coming soon), we will be storing package metadata in the database and will thus have an ability to retain this information. We'll also be integrating some more in-depth package usage analytics using some bits from Gibraltar Loupe ( http://www.gibraltarsoftware.com/loupe/Default.aspx ) -- though that likely won't make the 2.0 cut.

Hi, Thanks for the prompt reply. We're in the process of getting this running to hopefully become one of your enterprise customers, and it definitely was a problem for us unfortunately. Obviously I do appreciate this isn't actually your fault...!! Rather your workaround for someone else's issue. We would definitely be interested in pre-release versions, as we are still in the testing/implementation phase, it will be simple for us to move up and test. Thanks again! Adam.

Yes, just edit the value of the Core.BaseWorkingDirectory key in App_appSettings.config file in the service installation directory. I believe you'll have to restart the service in order for it to use this value as well.

Ah, definitely a bug -- will be fixed in next release, (1.1.4 or later)

It is possible (and fairly easy), but we do not have instuctions just yet. Hopefully this response will be enough. It basically follows the same steps as the Manual BuildMaster Installation ( http://inedo.com/support/documentation/buildmaster/installation/manual ), just without the Extensions or Agents. The hardest part will be getting the artifacts, as we don't have those available for download yet. But it's not so bad. For the files (WebApp and Service), you can just directly copy out of an existing installation. Just make sure to edit the appropriate appsetting config files when moving to the new server. For the Database, you can restore a back-up of the existing installation. To upgrade, you can use 7-zip to open the installer, and then copy out bmdbupdate.exe and $_OUTDIR\OBJECTS\SqlScripts.sql. First run bmdbupdate.exe then the .sql scripts. We will definitely make manual install artifacts avaiable in the future (along with instructions), and we do support this scenario for Enterprise Customers. We'll even help with install through our Professional Services ( http://inedo.com/company/professional-services ). Hope this helps...