Thank you for the report - this will be resolved in v4.0.7 which is due out later today.

Update! This has been fixed in ProGet 4.0.6

the error was not occuring when trying to select project. Browsing worked perfectly, i was able to browse and choose my SLN file. the error occurred upon clicking "next". All that aside, installing .NET 4.5 seems to have resolved the issue. 4.5 is not a requirement for vault or for BuildMaster, but seems to have changed something. I found an unrelated artical on google saying that they were getting a MaxArrayLength error, and that the error went away after installing .NET 4.5, so i figured it was worth a shot, and sure enough issue resolved!

Thanks Tod. I have run the provided SQL and can confirm that the View Purge History page is now working again. Cheers.

Thanks, all good now.

Thanks, it works fine now :)

Thanks; we've identified a possible race condition during initialization, specifically involving discovering the connection string of the currently installed instance. We've made a small code change which should resolve this issue - assuming it is the cause. We haven't been able to reproduce it on our systems. The installer for the next version (which should be 3.6.2) will have the fix, so you may want to try using the larger installer again just to see if the issue goes away. You never need the full installer to perform an upgrade, however.

Hmm, we'll have to look into that... Just use Applications_PurgeApplicationData with this method: http://inedo.com/support/tutorials/cloning-an-application-with-the-sql-api

Thank you very much guys for pushing this feature to the last release. I've upgraded our server today, turned the option on, and it works great. Cheers.

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.

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

Thanks, I'll wait until the fix is released. It's not a blocking issue for me.

Ah, I see; please note that we do not support v1 feeds (they were already obsolete when we build ProGet in 2012) and we have no intention to. Suggest you push packages from TeamCity to ProGet instead.

And also see this post.

It could be that the versions were fixed up when a package cleanup ran - happens every day by default, but may not have been immediately after the upgrade. Thanks for letting us know about the zeros missing from that page; we'll add an issue for this to get fixed in the next release.

We will be adding a few fixes to help with retrying after indexing issues in the next maintenance release, as well as some more logging to figure out what is going wrong in these cases. Long term, we will also be redoing a lot of the indexing logic to eliminate these types of problems (but that probably will happen in a minor/major release.)

Oddly, running the service in interactive mode seems to have solved the problem: the deployment is now complete. I didn't do anything but stop the service and start it interactively, and I didn't notice anything unusual in the output. It did look like it found the action and ran it, as far as I can tell, but didn't say what had been in the way.

Fixed! The issue was that the subversion configuration was pointing to its local svn.exe instead of the one we had installed on the server. I had to change the 'Path to svn client' field to point to our copy of svn.exe. Thanks again.

Hi Tod, Thanks heaps, that makes sense to me. Thanks for the quick reply. Regards, Daniel.

The patch corrected the issue. Thank you.