Unfortunately this was a regression present in 5.1.19, but has since been fixed in 5.1.20 which was released earlier today.

Hi George, Do you have any suggestion that I can do to fix this issue?. Thank you.

Alana, thank you for the update. I guess we can consider this closed until such time as we know otherwise.

The resources are embedded in the ProGet assemblies (in this case, InedoLib.dll), so if you can hit the site, then it means some IIS setting is preventing those from being served. It's hard to guess which one... perhaps URL filtering?

Sorry for a late follow up on this. So one place where this solution falls apart is that your Jenkins add-on for BuildMaster does not support the meta-tags in the version field.

Hi Ryan, That's definitely unusual! There should definitely be a bunch of logs here, especially showing the exact SCM command-line command that was run. So, something quite unexpected is happening... What source control provider are you using? And also, what happens when you test connection? Can you share the configuration of the provider (a screenshot should be ok), you can send this to us at support - at Inedo dot com.

The INEDOPROGETSVC service is used by ProGet to perform background tasks (indexing, cleanup, etc) and is required to run ProGet. The only options (right now anyway) to install the ProGet web application are: IIS-hosted Integrated web server (this is essentially a 2nd Windows service) Linux via Docker (currently v4.0 in beta)

This sort of workflow isn't really support; the standard way to do this is to re-execute a previous release's promotion to Production, thereby setting the context for the artifact to that of the previous-deployed build.

While there is currently no first-class extension for it, it'd be really easy to do with a Execute Command Line action, or a reusable Powershell Script that you put in the Script Repository. It's also fairly easy to write your own extension too -- if you choose to go that route, let us know, and we'll be happy to help where we can!

The -source argument doesn't look right. Since the command is running remotely, it shouldn't be accessing localhost, but instead it should be using the ProGet server's URL. To override that URL, make sure to set the ODataBaseUrl in Advanced Configuration to something like: http://proget-server:1000/nuget/

Does one of your embedded scripts contain a reference to a module that doesn't exist on a remote server, e.g. Web Server Administration for IIS? Unfortunately the error returned by PowerShell is fairly useless in determining which exact module is missing :)

Thanks for the report - I'll have a dev take a look at this and fix it for the next version, which should hopefully be out today (8/14/14).

Curious, what versions of PowerShell do you have installed on the machine with the ProGet service, and also on the remote machine?

Thank you for the report - this will be fixed in the maintenance release coming out today (v3.1.1)

Looks like Chocolatey now requires the description field to have a value, whereas pre-v0.9.8 it did not require one. We've updated the editor for v3.1.1 to require a description, though this will not impact existing data, so you'd still have to edit existing descriptions so that they have a value.

Not as of 3.8, but there will be a UI refresh in v4.0 (due later this month) and that will no longer be in the navigation bar.

Just name your database connections something like: "SQL-Integration", "SQL-Testing" (using the environment names). Then in your "Execute Database Change Script" (or whichever database action you're using), enter the name of the database connection as SQL-${EnvironmentName}

Interesting, it looks like the unzip program is returning a non-zero exit code, which causes the SSH agent to interpret the command as an error. You might be able to get around this by editing that specific Deploy Artifact action to treat errors as warnings. Also as a workaround, you could deploy the artifact to the "CurrentDirectory" on the BuildMaster server, then use the Transfer/Synchronize Files action from the CurrentDirectory on the BuildMaster server to the Solaris server.

Hey Tod, Its when we execute the workflow, it hungs after the execution is started. the very first step after it starts, still I kept the work flow going on.. and it took 208mins to execute all the steps which generally shall take not more than 2mins... A simple app pool recycle on the target system takes more than 30mins. I verified the communication with the target system and the agent .. they are working fine... the ports and communication between both the servers is good did the telnet and its responding... I can transfer the data between both the servers using normal copy within seconds... so no network issues. I can see the agents as ready for the target system.