Your best bet would probably be to use the Clone method via the API: http://inedo.com/support/tutorials/cloning-an-application-with-the-sql-api

Does this happen with all packages, or just one package? Can you try pulling a package to the feed (like JQuery), and then deleting it? Can you disable friendly error messages (webCustomErrors=off in advanced config), and post stack trace?

The root cause of this is that an undeclared execution variable is being created to override a declared non-execution variable. For example, if you create TESTVAR as a Release Variable but not as an Execution Variable, then use Set Variable Value to override TESTVAR value for the execution, it will exhibit this behavior. This will be fixed in a future version 3.7.1; either with a more helpful error or supporting the behavior.

This will be fixed in 3.7.1; but a patch is available for those on 3.7.0. Just email support - at- inedo - dot - com, and we'll send it over.

Thanks Peijen! In this case, you would use the Set Variable Values action to set the TargetDatabaseUsername variable name to %DatabaseUsername%. When the action is run, the TargetDatabaseUsername variable will be set to whatever the value of DatabaseUsername is at the time.

Unfortunately that issue PG-119 was moved to a future a release because of the priority of the other issues listed in the release notes: http://inedo.com/proget/release-notes#2.1.3 We will try to get this in 2.1.4.

Hi Andrew, You'd probably want to use Active Directory groups of some sort... but you could either add explicit privileges or add deny privileges to the groups you don't want to go to prod. Just keep in mind, however, that deny takes precedent over a grant in the same scope. IOW, if you say "X can deploy to A" then "X cannot deploy to A", then X will not be able to deploy to A. Steve

I would just move it to an application group called "Inactive".

Check out the "Get Labeled" action under the "Source Control" group of actions. I'm using Git and that's how I pull the code associated with a tag. I'm pretty sure "Get Latest" does pull down the whole repo. In general, when automating application builds, you want the process to be as repeatable as possible, and relying on a repo to be maintained on the build server between builds introduces unnecessary complications.

Hi John, I just tested the fix, and it indeed solves the problem. I am impressed how quickly this was handled! Thanks a lot!

Every .NET project that consumes NuGet packages has a packages.config file, and that should be in source control. Unless I'm missing something, the deployment plan actions should be as simple as "Getting Latest" from TFS, then an "Install NuGet Packages" action followed by "Create NuGet Package".

Yes it would, but the editor UI may attempt to validate the credential. The way to get around this would be to edit the Action XML directly and replace the principal name with %VARNAME%. We'll add a fix in a future version of BuildMaster (likely 4.x) to bypass this validation if %[A-Z]% or something is matched.

Wow! Talk about agile, thank you for the quick turn around.

Ah, yes, that is indeed a bug. The home page "Browse" should link to the first available feed. I've logged this as PG-121 and we will fix in a future version of ProGet. The "Feeds" navigation link, however, will show the available packages.

Hello, We've identified a bug that's causing this.... it will be fixed in ProGet 2.1.3. In the meantime, if you email support at inedo.com, we will send a patch to resolve this. Thanks, Steve

I figured out the problem was with the cloud service name. I was including the build number in the name and it just so happens that build number includes the {Major}.{Minor} numbers. The period was ultimately throwing it off. If you want to include the build number, then you have to use a url friendly number.

Hello, Thanks for the reply. I have started pushing just the Symbols package, and this seems to be working really well. Thanks Gary

Hi Andrew, The ProcessRemoteCommand method only works when working with .NET-based agents. Behind the scenes, that method will serialize the action and use a sort of remoting to run that method on the remote server. With an SSH-based agent, this is obviously not possible. The CommandLineActionBase abstracts a lot of the complexity in executing remote processes. Just ignore the ProcessRemoteCommand method (throw a NotImplementedException) and try run the ExecuteCommandLine method from Execute. FYI - this is all being refactored in 4.0, and we're trying to phase out as many ProcessRemoteCommand-based actions as possible.

Hey, This is great news! Thanks for getting this sorted out so quickly! Gary

We uncovered the cases in which it might lock... this should be addressed in ProGet 2.1.2 (released today).