See: http://stackoverflow.com/questions/22767440/using-teamcity-build-number-in-buildmaster

This is not a very common scenario, so I would suggest altering your workflow to not always update the packages if they don't change. Alternatively you'll need to add some custom steps such as deleting the package before pushing it, or using a custom package store.

It sounds like there are some encoding issues; i would make sure your assemblyinfo file in source control is saved as UTF-8.

Yes Spaces were in all of my feed names. Removing the spaces resolved my issue. Removing the spaces also resolved the issue where the Download button was not working which I had reported in another thread. Thanks.

It looks like that particular package has a .nuspec file that does not match the name of the package ID. If you change the name of the nuspec file inside the package to match the package ID it should be able to be indexed. We will add a better error message for this in the next version.

We don't have one.... for now we're planning on featuring our deploy features in v3. Any suggestions or things you think we should do?

We had considered this feature when designing ProGet, but ultimately didn't implement it. One very popular workflow is to have BuildMaster push the packages to different feeds based on environment. Have you considered using that?

I believe this is a bug in NuGet; https://nuget.codeplex.com/workitem/4050 If not, I would suggest to do a fiddler trace to see specifically which url is failing,.

I get the same error with nuget.exe 2.7,2.6 and 2.5. We hope you can fix it in future version

This can sometimes happen if you import a plan from an application that only has a single deployable. It is possible that a deployment plan could be created without being assigned to a deployable, and since applications with a single deployable are designed to hide deployables from the UI, it's difficult to determine what would have caused this. From the UI, the easiest way to ensure that the correct deployables are assigned to an action group is to add a 2nd "dummy" deployable that will re-enable the ability to see assigned deployables from the UI perspective. This will then display the deployable name on the action group as it did before v4.0.

That seems odd - it's possible Gallio changed the output format of the tests and they are no longer registering correctly as failures in BuildMaster. Can you post the issue on GitHub? https://github.com/Inedo/bmx-gallio/issues

There is no current way (as of 3.0.0 beta) to do this built-in, but could be done with an extension. A feed adapter is probably the best way to handle this. I'm not sure what you mean by the 2nd half of your question... you don't have to pull the package to download it from a connected feed - there is a download button just the same as if it was in your private feed.

We do intend to upgrade the SDK used to get the newer version working, but there is no specific schedule for when this will happen at this point. If this is a showstopper for your team please email us at support@inedo.com

I'll try changing the type to IIS-hosted and see what comes of it. Just seems a little strange, since we've been running with the same configuration (TCP-hosted) since BM 4.0.5, without any issues. At some point (I believe within the last month), all build agents began failing at random times. Whatever version it was, around the same time we were no longer able to use SSL on the agents and we haven't tried using it since.

The exact process is detailed on the page used to switch over, but here are some troubleshooting ideas: ensure both Windows Auth & Forms Auth enabled for the website ensure Anonymous Authentication is disabled ensure there are administrator privileges granted before switching perform an iisreset on the web server if using IIS

I believe someone from our support staff emailed you a quick fix for this. It appears the double.Parse() method was not taking the current NumberFormatInfo into account for some reason.

Thanks for the report! Just update the site to fix this.

Yes, and we have actually already implemented it for our next release :) We're thinking of releasing a beta version of 3.0 today if you want to be on the lookout for it.

It's alphabetical. We've considered adding in a sequence, but have found that most folks will prefer the old "GWBasic" route of prepending an integer to the name to determine execution order. First SCript Second Script Last script This ordering comes after the release ordering.

Yes, all good. That directory is monitored for changes, and when a change occurs, the contents are re-indexed.