<strike>Unfortunately no. I'll add this as an item to improve for the next release though.</strike> As of BuildMaster v4.7 this is now supported using the /ServiceName argument. For the complete list of arguments, see: http://inedo.com/support/documentation/buildmaster/installation/silent-agent-installation

Fixed! This is included in v4.6 of the NuGet extension, which is now available.

Another quick way you can close all connections to the database: ALTER DATABASE [DbName] SET OFFLINE WITH ROLLBACK IMMEDIATE ALTER DATABASE [DbName] SET ONLINE

This is the default behavior already. Every artifact in BuildMaster is associated within a context of a build and deployable, so as long as you create the artifact in a specific build, that artifact will be used whenever that build is promoted/executed in every future environment by default. For more info, see the documentation on Builds.

Glad that works. If you only have a few instances of variables like $HOME, you can always just escape the $ - use $$HOME instead and BuildMaster will treat it like the literal $HOME and not try to replace anything.

Your projects sound like they're all part of an overall business application; i.e. to the business, and how it's consider for requirement changes and the like. In that case, the best way to handle this scenario is through deployables; that's basically what they were built for. This allows for "partial" releases (i.e. having 1, 2, or 3 components) easily, and allows for some more advanced dependencies (such as, say, you wanted to import one of those deployables to another application). However, in Jenkins, these would be represented as three (or more) different jobs. So, what I might try is to use a Build Plan (i.e. not a build importer, just a regular plan you can add actions to)... and then use three different action groups (each associated w/ a different deployable) that contains "Get Jenkins Artifact (to working directory)", "Delete Files (from working directory, with whatever masking you need), then "Create Build Artifact (from working directory)". It's a little inefficient I suppose, because of the zipping/unzipping, but hopefully that is trivial. As for the bug, actually first I heard of it --- mind submitting a ticket so we can get it fixed?

It was execution time in web.config. Thanks for help!

Thank you for the report, this will be resolved in the next release.

UPDATE: This is supported with the new execution engine, available in BuildMaster 4.9. As of BuildMaster 4.6, this isn't supported, but definitely something we will support in the future. I can see other cases where this would be useful as well (e.g., copying files or deploying artifacts to multiple target servers).

This sort of workflow isn't really support; the standard way to do this is to re-execute a previous release's promotion to Production, thereby setting the context for the artifact to that of the previous-deployed build.

You should be able to reference your library from your custom extension. You just need to make sure that it and any other dependencies are either included in the .bmx file or are installed to the system GAC. BuildMaster doesn't use EF, so there shouldn't be any version conflicts there.

Note: we have now scheduled this feature for v3.6

A patch is available below; run the contained SQL scripts against the BuildMaster database in any order to resolve this. Note that this fix only applies to v4.6.3-4, and will be included in v4.6.5: http://44.inedo.com/buildmaster/CloneAppPatch-v4.6.4.zip

The story continuous :) Because I set TeamCity to create source packages as well (it's a checkbox called: Include sources and symbols) it was overwriting the packages in ProGet (I have all the PDB and sources in my nuspec files as well). This was causing the issue with the config file being gone, because TeamCity strips those files out for the symbols packages. So... I was doing things twice... Must be user error ;)

Which older version of nuget works correctly?

VPN will occur at a much lower level than ProGet operations (which is HTTP/IIS), so I suggest you use a tools like Wireshark to dig a little further and see where the problem might be.

4.0 is available for download now; we've tested it about as far as we can, the main reason it's still considered "beta" is to see how the Docker/installation process works in the wild. So, please give it a try. Depending on the requirements of non-AD LDAP, if it's easy to do, we can implement it quite soon.

Hi Dean Restarting the ProGet service solved the problem. Thanks!

It seems to be more stable now, or I can at least see the NuGet page on ProGet. Thanks.