Restarting the service sorted it thanks.

The current behavior is to never overwrite existing packages during a bulk import. Maybe we should add a configuration flag for this- at the very least I'll make a note to update the documentation to describe this behavior.

Hi Simon, If those buttons aren't lighting up, then the machine doesn't have internet access and can't request a key. Just go to my.inedo.com and request one instead, then enter it in. You don't need to manually install, but FYI that zip file would be in the manual installation package.

Apparently only the PowerShell scripts support variables in parameters and in scripts at this time, so we will have to add this feature for shell scripts as well. Ideally it will be included with the initial 4.7 release, but may be a maintenance release behind that. For now, if you use the Execute Shell Script action and enter the script as text or a file, it should work as you expect.

As currently written, I can't think of a good way to inject a connection string since that's handled at a higher level. I suppose the best way is to test against a local copy of BuildMaster with the connection string you want.

Hi Dan, we don't offer any additional pricing options; although we do provide licenses for free open-source projects.

Here is the "draft" list that will be posted on the website soon (Free, Basic, Load Balanced, High Availability): Features F B L H Unlimited Users X X X X NuGet Server X X X X NuGet Package Symbol Server X X X X Chocolatey Package Server X X X X npm Registry Server X X X X Bower Server X X X X Maven Server (beta) X X X X License Filtering X X X Connector Filtering X X X Feed-level User Privileges X X X Active Directory Integration X X X Package Retention Policies X X X MyGet Feed Synchronization X X X Package Statistics X X X Custom Licensing Agreement * X X Multiple Web Servers X X Multiple Index Servers X Automatic Failover X * w/ purchase of 5 or more servers

As far as I'm aware, this particular issue has already been resolved. Can you post a new question with the same details? For some quick suggestions though, does echo $ApplicationName work as expected? Is the application configuration to use new variable support (Settings -> Application Settings)?

Sorry to resurrect my old post, but I'm trying to use LDAP in ProGet and am running into the same issue. Users and groups that are in the domain of the server running ProGet are found, but users in a different domain are not.

Ah! That would explain why I couldn't reproduce this. I forgot that some versions of npm did weird things with URLs... Glad it's resolved!

That option unfortunately will not work at this time without significant changes, and it's supposed to be hidden currently. We may remove it in the next version or add the required functionality to get it working in an even later version. The problem with it is that dependencies can now vary based on other factors such as platform, .NET Framework version, etc. As a workaround, enabling caching for the feed and downloading the package from Visual Studio will accomplish essentially the same thing, though.

Please see: http://inedo.com/support/kb/1021/using-proget-with-nuget-the-visual-studio-extension

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