Thanks, this works :)

This has been logged in our issue tracker - it will be fixed in the next release, which will be v4.0.11. We should have that available early next week. It looks like this was just an oversight on our part.

I'm afraid we don't have any tutorials for this ourselves, but there a lot of third-party tutorails out there for using mvn. Here's one that might be helpful, directly from maven project:https://maven.apache.org/guides/mini/guide-3rd-party-jars-remote.html

With any versions of ProGet – from free to Enterprise – you’ll be able to access the repositories but scaling down from Enterprise to basic, or basic to free , you'll lose access to license filtering, feed-level user privileges, and other benefits that many users have come to enjoy, depend on, and take advantage of throughout their use of enterprise or basic ProGet. Very rare are there cases folks want to lose those features but if it's necessary, your team will still be able to access the repositories. Take a look at the full break-down of features and benefits per version here: http://inedo.com/proget/pricing/features-by-edition

Whoops, updated! It's http://inedo.com/proget/roadmap

Is this feature now available? Where could I find documentation to this?

This should be fixed in the 5.0 beta, which we will probably have available for download this week. Basically, we are dropping those _WRK, _SRC, directories entirely from OtterScript plans in favor of something a little easier to reason about. We'll have more information about this behavior in an article soon.

Alright, well I did manage to make it work using IIS so at least there is a workaround, however since that was the only thing on that server that needed IIS it's too bad that I had to install and configure it only for that purpose. Thanks.

Thanks for letting us know; this is something we want to work very consistently in 5.0, so it's possible it's working half the "old" way (OtterScript plan wrapping an old action), and half the new way (a new "operation").

Thanks for the help... in the end I found I needed to install Microsoft Visual Studio 2012 Agents on the build server. The project was then able to build successfully.

I bumped into this issue as well. It turns out if you wanna use existing local SQL server, you need to add an account "NT AUTHORITY\NETWORK SERVICE" to your SQL database. To be clear, this account is added to ProGet database during installation but it didn't mark as "Public" in server role.

Yes, but it's not "officially" scheduled as BuildMaster v5 is the top priority at the moment. Here is the roadmap for reference: http://inedo.com/proget/roadmap

First of all, Thanks for your answer. I know it, but the problem is that I have more than one deployable in an application, sometimes the new builds has no need to re-build all of them, but in the last step of my deploy plan, I need to update a sql table with the versions of all the deployables included into the build deployed. For that reason I need to access an specific deployable, and then, of course, I will use the $referencedBuildNumber function. "$ReferencedBuildNumber : Returns the build number referenced by the imported deployable in the current scope." Thanks

I think this was a regression 3.8.6; if you upgrade to the latest, you should be able to remove them.

The tutorial still needs to be updated (we will do this for v5), but take a look at the SDK Documentation for how the variable base classes work now; basically you declare them as properties and then use attributes to indicate that they are parameters.

You might be getting that message if you have Windows Integrated AUthentication enabled; this is unfortunately not supported in the npm client. Otherwise if you follow the steps in the npm tutorial it should work just fine.

Thanks, Tod, but I want to keep all the actions on the client side. I found that I can just do a GET and a PUT, and once I constructed the multi-part form data correctly and added a boundary to the content, it worked.

Actually, reading your last sentence again, it sounds like I shouldn't use API keys in cases where I want to keep a feed secure. This is probably the best answer correct? Yes, pretty much. I suppose you could think of it as two different sets of doors that could secure a feed --- the first door (LDAP) is quite secure and can be user/group controlled, whereas the second door (API Key) is quite weak and works a bit like a skeleton key that everyone shares. There's zero point in requiring users to unlock two different doors, which is why we say using an API key doesn't make sense when you've enabled LDAP. If you want to use only an API key, then you must bypass the first door by allowing anonymous. This is less secure and generally not recommended.

This would require creating an after-push adapter using the sdk. Several folks have done this in their own instances, but we currently don't hav ea tutorial for how exactly to write one;, but the classes should be fairly self-explanatory to assist with this.

Thanks, I was able to download the Oracle extension and modify it to look for a custom statement delimiter for testing purposes. A few tests seem to check out fine so I'm able to deploy package updates this way. This means I have to customize my deploy scripts but this may be an acceptable tradeoff for now. I've made my statement separator tokens comment sequences (i.e. "--$$") so that the script can still run in sql*plus.