When you say "BuildMaster is not able to see it", are you saying you aren't able to get the latest files in that branch, or that when you browse the branches in the file/folder picker that they aren't visible? I just did a quick test with a Git repository on BitBucket and the moment I added a remote branch, it became visible in the file/folder picker.

We don't have any tutorials for this specifically, but you should be able to build everything using the "Execute Command Line" action: http://help.adobe.com/en_US/Flex/4.0/UsingFlashBuilder/WSbde04e3d3e6474c4-59108b2e1215eb9d5e4-8000.html

I can't reproduce this problem; the query always works for me. Could you send a fiddler trace of the failed request to support at inedo.com?

Strange. If you open the Tools->Options->Debugging dialog in Visual Studio, is the "Require source files to exactly match the original version" item checked? If it is not checked, that may cause it to use an old source file in the debugger. As far as I know, the PDB age is part of the symbol file's unique identifier - when Visual Studio asks for symbols, it makes a request to a URL with the PDB GUID and age. I think age normally gets incremented when a project is rebuilt in Visual Studio, though I don't know the rules about this for sure. Since you get the correct symbols/source if you clear out the symbol directory, I'm guessing Visual Studio just isn't making a request to ProGet because it thinks it already has the correct files. The best thing to do in this case is to run Fiddler and capture a trace of both behaviors and see what's different. You can send us a copy of these to support at inedo.com if you want some help troubleshooting.

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.

Yeah that's probably the best bet.

We have fixed this for v4.5.8. For users of v4.5.7, you may download a script patch here: http://44.inedo.com/buildmaster/v4.5.7-JS-Patch.zip This .zip file will contain a JavaScript file that should be saved in the \Resources\jQuery subdirectory of the BuildMaster web application installation. Its presence will override that of the existing DeploymentPlans.Common.js.gz file, and the page should refresh correctly once it's there (you may need to CTRL+F5 the browser once if it doesn't work right away).

Do you by chance have a space (or other reserved character) in the feed name? If so, make sure it is URL encoded when you access it, e.g.: http://domain.com:81/nuget/Feed Name With Spaces

Please note that granular, feed-based security is only available in the paid Enterprise edition. In the Express edition, privileges may only be applied to the whole system. If you would like to trial these features, you can request a trial key at https://my.inedo.com

v3.3.11 has been released that should resolve this issue.

v3.3.11 has been released that should resolve this issue.

We actually aren't familiar with that particular tool. We do have Axosoft OnTime integration, so if the API is the same, then it should already work :) If not however, issue tracking integration is extensible, and can be developed by your team or by us as part of extended support. Does this help?

Which aspect of insecurity are you referring to? Those credentials (as long as they are sent over SSL) are encrypted before they are transmitted. If you mean storing them in the BuildMaster database, of course that does leave them available to anyone who has access to them, but you can configure permissions to hide debug logs and access to the configuration for that provider. Anyway, you should configure your git client to use key-based authentication if the username/password combo can't be done.

ProGet does index those source files, for both C# and C++. Are you having a problem with this, and if so, can you provide some repro steps?

I can confirm that this is fixed in version 3.3.7 of ProGet. It is now working like a charm.

Executed with output of: (1 row(s) affected) (1 row(s) affected) Will let you know if I see any more problems like this, Thanks for the incredibly fast turn around time!

That should be all that's necessary, perhaps restarting the server where ODAC is installed might help?

I did solve my problem with installing and reinstalling proget. Now is everything working.

Are you sure you're on v4.5.5? This should have been fixed in that version (BM-1685)... it can only happen if you don't have any deployables set up for an application.

OK, I've upgraded the feeds to the ProGet 3.3 format (there was still in legacy format), and I have been able to successfully apply your workaround proposition. It's not ideal but it's working.