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.

Thanks for the help investigating this. We've identified a possible race condition during initialization, specifically involving discovering the connection string of the currently installed instance. The presence of .NET 2 shouldn't affect things, as the installer specifically targets 4. The 20 in the CLR20 error just refers to the runtime version. .NET 4 runs on the CLR 2.0 runtime, confusingly enough. 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. Again, thanks for the help!

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

Most definitely not. Unfortunately, we have no idea when NuGet v3 will come out, nor do we know when/if there will be API docs availalble (or a stable codebase to reverse engineer the API). Based on the various iterations of the v3 API that have been published in preview/beta, we have little confidence that it will solve the performace problems that ProGet users experience with connected/remote packages; so, on the ProGet Roadmap, we plan on solving that by creating a full index of nuget.org. That said, the NuGet team will need to support v2 for several years to come, so we're in no rush. Moreover, We have a plan that http://inedo.com/support/questions/3130

See: http://inedo.com/support/questions/3090

Also for convenience, as of .NET 4.0 there is a CopyTo() method on Stream that will do the buffering for you, so you can just call: srcStream.CopyTo(destStream);

Retention Policies are not inclused in the free edition. You can still delete packages manually however.

Turns out it does work, there was another issue preventing it from running. What's got me confused though is that the script is being run from the SRC directory (that's what the unix pwd command implies) when it was copied to the WRK folder as you can see from the log. Downloading http://192.168.59.103:8081/artifactory/libs-release-local/myapp/0.1/33/trial.sh artifact to C:\BuildMaster\_SVCTMP\trial.sh Transfer C:\BuildMaster\_SVCTMP\trial.sh to /tmp/buildmaster/_A5/_S5/WRK/trial.sh over SSH Execution complete. Finalizing... Target directory used. Abandoning source. Finalization complete. Source and target directory are the same; splitting... AgentBasedAction initialization complete: Temp Directory: /tmp/buildmaster/_A5/_S5/TMP Source Directory: /tmp/buildmaster/_A5/_S5/SRC Target Directory: /tmp/buildmaster/_A5/_S5/WRK Server: DockerVM (Id: 2) Initializing action... Initialization complete. Executing... trial.sh /tmp/buildmaster/_A5/_S5/SRC Script returned: 0 Script completed. Execution complete. Finalizing... Target directory unused; joining with source. Finalization complete. Source and target directory are the same; splitting... AgentBasedAction initialization complete: Temp Directory: /tmp/buildmaster/_A5/_S5/TMP Source Directory: /tmp/buildmaster/_A5/_S5/SRC Target Directory: /tmp/buildmaster/_A5/_S5/WRK Server: DockerVM (Id: 2) Initializing action... Initialization complete. Executing... echo result: Hello World, we've made it! ls result: trial.sh pwd result: /tmp/buildmaster/_A5/_S5/SRC

Anything with the suffix _Configuration can be deserialized, so for your example all you need is: return (ArtifactoryVersionVariable)Util.Persistence .DeserializeFromPersistedObjectXml(settings);

Predicates are not directly tied to applications anymore as of v4.3 because of global plans. However, if the plan is in a single application, you can use: int id = int.Parse(HttpContext.Current.Request.QueryString["planActionGroupId"]); int applicationId = StoredProcs.Plans_GetPlanActionGroup(id) .Execute() .ApplicationDeploymentPlans .First() .Application_Id; to get it.

Actually I was able to repro this (only when LDAP is enabled however); thank you for the report - it will be fixed in the next maintenance release v3.6.2. As a workaround, just visit the /administration/feeds/select URL directly.

That should be OK - just note that this will update all workflows in the system to have this behavior.

You can use: var configurer = Util.ExtensionConfigurers.GetExtensionConfigurer(this); from within the variable itself, or pass in an instance of the variable instead of this from the variable setter.

Thank you for the additional information, we were able to reproduce. The fix will be included in v3.6.2. If you want an immediate patch for v3.6.1, you can download the file at: http://44.inedo.com/proget/NuGetPackageVersionPage.js and save it into the WebApp directory of the ProGet installation under the following subdirectory: WebApp\Resources\mapped\Pages\NuGet\Feeds\ alongside the NuGetPackageVersionPage.js.gz file. You may have to clear your browser cache to see the change.

You may be best asking this on NuGet forums, as this relates to behavior in the nuget.exe client. We do not use "nuget.exe pack" ourselves (instead, we opt to use the proget client tools) as it's more reliable and has defined behaviors.

We have not had other users report this problem, nor have we seen it during testing. You can try running the service interactively (just stop the WIndows Service, then run the .exe file), and see what happens. Also worth noting, make sure that all the errors in the log are deleted before the packages start indexing again.

It is also worth noting that strictly speaking, pushing packages does not require the View privilege, that is a result of the NuGet client sending a GET request (i.e. "list") first before sending the PUT request to push the package -- it's the first request that gets 401ed. You can use the following PowerShell script to perform just the package upload: $FeedUrl = 'http://proget/nuget/Default' $FileName = 'C:\tmp\ProGet\packages\Package.1.0\Package.1.0.nupkg' $APIKey = 'Admin:Admin' #params([string]$FeedUrl, [string]$FileName, [string]$APIKey) $req = [System.Net.WebRequest]::CreateHttp($FeedUrl) $req.Method = 'PUT' $req.ServicePoint.Expect100Continue = $false If ($APIKey) { $req.Headers.Add('X-NuGet-APIKey', $APIKey) } $boundary = '---------------------------' + [System.Guid]::NewGuid().ToString('n') $req.ContentType = "multipart/form-data; boundary=""$boundary""" $utf8 = New-Object -TypeName System.Text.UTF8Encoding -ArgumentList ($false) $reqWriter = New-Object -TypeName System.IO.StreamWriter -ArgumentList ($req.GetRequestStream(), $utf8) $reqWriter.WriteLine("--$boundary") $reqWriter.WriteLine("Content-Disposition: form-data; name=""package""; filename=""package""") $reqWriter.WriteLine("Content-Type: application/octet-stream") $reqWriter.WriteLine() $reqWriter.Flush() $fileStream = [System.IO.File]::OpenRead($FileName) $fileStream.CopyTo($reqWriter.BaseStream) $fileStream.Close() $reqWriter.WriteLine() $reqWriter.Write("--$boundary--") $reqWriter.Dispose() $response = $req.GetResponse() $response.Dispose()

If "Multiple Active Builds" is enabled for the application, the builds will queue (i.e. the latest ones will stay "Pending" until the prior ones finish sequentially). Without that setting, newer builds will reject older builds for the same release. Beyond that, your workaround for the non-mulitple-active builds setting will work fine.

There shouldn't be anything else that needs to be passed in, are "hello" and "cause" the only 2 variables? It's possible there could be an issue with default variable values.

This error means that the connection string in the installed product doesn't work for the user installing the software. Most likely, you don't have access to the database or server. I think the discussion here http://inedo.com/support/questions/3126 may be related as well.