Current discussion thread:
http://devnet.jetbrains.com/message/5519081#5519081
Bug Report: http://youtrack.jetbrains.com/issue/TW-37148
Error: Cannot prompt for input in non-interactive mode.
One thing to note is that the credentials prompt is triggering on each package download instead of at the beginning. I think this may be a bug in the way Team City is calling NuGet, but I'm not sure.
I have the "NuGet Feed Credentials" build feature configured, basic auth configured, and I've run the feed in Firefox and got the list of packages to show up on the agent machine (with credentials required).
My build log: https://gist.github.com/tonyeung/517597ca2312dad85f62
The following is a workaround which may help you, although I was of the impression the NuGet Feed Credentials build feature was meant to fix the problem. I was having a similar issue with the internal TeamCity NuGet feed without guest access (called Local in this example).
Initial build step (command line - custom script)
del /F %env.APPDATA%\NuGet\NuGet.Config
%teamcity.agent.tools.dir%\NuGet.CommandLine.DEFAULT.nupkg\tools\nuget.exe sources add -name Local -source %env.NuGetFeed%
%teamcity.agent.tools.dir%\NuGet.CommandLine.DEFAULT.nupkg\tools\nuget.exe sources update -Name Local -User %env.BuildServiceUser% -pass %env.BuildServicePassword%
As I say, it's a workaround, but not too much to maintain if using templates. Hopefully it gets you up and running.
I know this is an old question, but I recently came across this issue in TeamCity 9.1.7.
In my case, the issue was that I had a trailing slash on the Server URL, found in Administration > Global Settings. Removing that slash made the authentication work correctly.
For the TeamCity 8.1.2 (build 29993), I solved this issue by installing the Nuget v. 2.8.0 at the TeamCity Administration panel (I had v.2.8.2). Then I've added "Nuget Install" build step and set up the NuGet Feed Credentials build feature.
Probably, if you'll update the TeamCity it would also fix this issue.
To solve
http://localhost:80/httpAuth/app/nuget/v1/FeedService.svc: The V2 feed at 'http://localhost/httpAuth/app/nuget/v1/FeedService.svc/Packages(Id='***',Version='1.0.0')' returned an unexpected status code '401 Unauthorized'.
issue I have done:
create local administrator account
net user tcbagent password123 /add
net localgroup administrators tcbagent /add
attach "Logon as service" permissions (using Carbon PS helpers)
Grant-CAPrivilege -Identity tcbagent "SeServiceLogonRight"
create account within TeamCity
run cmd using destination environment
runas /user:tcbagent cmd
add nuget source with credentials
nuget sources add -name local -source http://localhost/httpAuth/app/nuget/v1/FeedService.svc -UserName tcbagent -Password password123
localhost of whatever you need
check your teamcity-build.log file to get something like this:
Starting NuGet.exe 3.5.0.1284 from C:\TeamCity\buildAgent\tools\NuGet.CommandLine.DEFAULT\tools\NuGet.exe
...
Restoring NuGet package xxxx.
...
Using credentials from config. UserName: tcbagent
TeamCity v9.1.7, NuGet v3.5.0-beta
I've spend 2 days to resolve it because I'm quite new with TeamCity and CI.
Hope it was helpful.
seem like a similar issue to https://nuget.codeplex.com/workitem/4172.
Can you try the workaround at the bottom of the issue description?
Related
I know my question is very similar to this one (Visual Studio Package Installation Error: "Failed to initialize the PowerShell host."). But still the answer that was given there didn't solve my issue.
So like the guy in the link above I have a problem in Visual Studio when I try to create a Web Forms Application or when I want to download and install some Nuget packages (example: AWS DynamoDB sdk) it gives me this error:
failed to initialize the PowerShell host. If your PowerShell execution policy setting is set to AllSigned, open the Package Manager Console to initialize the host first.
When I did some browsing I came across this command:
Set-ExecutionPolicy Unrestricted
But that didn't help. I still got the error. In the link above someone shares this command:
start-job { Set-ExecutionPolicy Unrestricted } -RunAs32 | wait-job | Receive-Job
But I don't really know what difference it makes or what it actually does. After trying the first command and doing:
Get-ExecutionPolicy
I got a response that the value is Unrestricted. But in the other command it was still AllSigned. I also tried running Visual Studio as administrator and that didn't help either.
I figured out, that there was a certificate from Microsoft on the Untrusted list, and I needed to delete it, and now it works.
I am stuck in a problem trying to install appx with Powershell -ExecutionPolicy Unrestricted add-appxpackage <path to appx> using the Powershell plugin in Jenkins and the below errors are logged:
add-appxpackage : Deployment failed with HRESULT: 0x80073CF9, Install failed.
Please contact your software vendor. (Exception from HRESULT: 0x80073CF9)
Deployment Add operation rejected on package
<path to appx> install request because the Local
System account is not allowed to perform this operation.
NOTE: For additional information, look for [ActivityId].
As I understand, this problem is mainly because Jenkins service on Windows gets installed as NT Authority\System. (If I use psexec.exe to open a command prompt that runs as Authority\System, I run into the same issue.) I then tried adding net localgroup "Administrators" NT Authority\System /add hoping the group might get added as Administrator and would let me install the appx, so I can run the tests, but with no success. Now I am stuck and I am not sure if there is really a way to install an appx via Jenkins or not OR if there is a way to invoke the Powershell script as an administrator via Jenkins. I have been through couple of SO links already, but none of them seems to fix the issue I am facing. Any pointers would be appreciated.
DO NOT try to add System to the Administrators group, it's a limited account for a reason and does not require administrative privileges.
Instead change the Jenkins service to run as a user that has the right permissions for what you're trying to do. That might mean you need to create an account specifically for the Jenkins service.
There are a few ways to change the service account, this answer gives the following as a solution:
sc.exe config "Service Name" obj= "DOMAIN\User" password= "password"
When I create a new WebAPI project (MVC4) I get the following error.
EntityFramework.5.0.0: Failed to initialize the Powershell host. If your powershell execution policy setting is set to AllSigned, open the package manager console to initialize the host first.
jQuery.1.7.1.1: Failed to initialize the Powershell host. If your powershell execution policy setting is set to AllSigned, open the package manager console to initialize the host first.
After Googling I have found a few answers but nothing that works yet.
Error creating new MVC project - EF and JQuery
This answer seems like it should work for me as my last project was a 7z Command Line app and I might have done something daft with 7zip. But I copy pasted the 7-Zip directory from Program Files to Program Files (86) with no luck.
http://social.msdn.microsoft.com/Forums/en-US/vssetup/thread/c934fed4-e44e-4a06-9e3b-eccb9c8aa8d6
There is an answer here that might work (I haven't tried it) but even if it does work I wouldnt want to do this every time I create a new project.
Is anyone able to help me with this one?
I got around a similar error by running PowerShell as administrator with the command Set-ExecutionPolicy Unrestricted, restarting Visual Studio, and opening the Package Manager Console before what I wanted to do.
Make sure you understand the security implications of doing this first.
http://technet.microsoft.com/en-us/library/ee176961.aspx
Restricted - No scripts can be run. Windows PowerShell can be used only in interactive mode.
AllSigned - Only scripts signed by a trusted publisher can be run.
RemoteSigned - Downloaded scripts must be signed by a trusted publisher before they can be run.
Unrestricted - No restrictions; all Windows PowerShell scripts can be run.
I encountered this issue recently, after re-install VS and install the latest VS update 2, things go well. This works for me at least.
I'm trying to have the build agent run under another account than the build-in SYSTEM account. On our previous windows 2003 box this is no issue; just adding it to the buildAgent.properties and configuring the buildservice to run under the required account works fine.
However, on our server 2008 instalation the new setting is not picked up. Can anyone confirm changing this setting actually works on a server2008? / What else can I try?
Ok, I found the answer on the Teamcity forum here, apparantly it's a known issue and will be fixed in 7.1, but for now there are the following options:
install 7.1 EAP
run the agent using the console
apply a dirty, dirty hack in the registry
Upgrading from 7 to 7.1 resulted into a non-working TC installation so I opted for option 2:
To run the agent.bat we put a batch file in the Buildagent directory containing:
%windir%\system32\runas.exe /savecred /user:domain\user "%windir%\system32\cmd.exe /k D:\Teamcity\buildagent3\bin\agent.bat start"
I'm having a bit of a problem with Web Deploy I just can't seem to iron out. Every time I try and publish to WMSvc via the [proj].deploy.cmd command in the package I'm getting "The remote server returned an error: (401) Unauthorized". The command looks like this (project is called "Web", server is named "AutoDeploy"):
Web.deploy.cmd /Y /M:https://AutoDeploy:8172/MsDeploy.axd -allowUntrusted
I can publish fine to https://AutoDeploy:8172/MsDeploy.axd via Visual Studio so the service is definitely running and I can successfully authenticate to it as administrator. Running this locally on the machine against the package while logged on as administrator (it's just a little local Win 2k8 VPC) isn't working and adding /U and /P parameters with the administrator account does nothing.
I've enabled failed request tracing and am getting this output so at least there's something to refer to but unfortunately I can't determine what the root cause is. I'm trying to connect to the same service with the same credentials as in Visual Studio but obviously something is different.
Just out of interest, I can publish fine to the Web Deployment Agent Service (MsDepSvc) as follows:
Web.deploy.cmd /Y /M:http://AutoDeploy/MsDeployAgentService /U:AutoDeploy\Administrator /P:...
But I really want to get WMSvc running! Any thoughts?
Sayed's comment above got me pointed in the right direction. After making the build output verbosity "Detailed" and also setting UseMsdeployExe to true in the .csproj (another tip from Sayed's blog), I found the command generated by Visual Studio was setting the authentication type to basic which retrospectively, is obvious given the plain text username and password.
The MSDN post on How to: Install a Deployment Package Using the deploy.cmd File explains you can just add an "a" flag to the command to set this. So in short, here's how it now looks (and actually works):
Web.deploy.cmd /Y /M:http://AutoDeploy/MsDeployAgentService /U:AutoDeploy\Administrator /P:... /A:Basic