Problem with NuGet plugin

I've tried to install the NuGet plugin into our Teamcity 6.5 installation, as described here http://hadihariri.com/2011/08/24/native-nuget-support-in-teamcity/
After placing the plugin in the appropriate folder and restarting the server I fail at step 2. The NuGet package could not be retrieved.
I've already tested if the service account which is running teamcity has internet access (it has).

Is there any other setting which could be wrong?

[2011-08-25 09:58:29,345]   WARN - stry.tab.InstallToolController - Failed to fetch NuGet.Commandline package versions. Connection to https://go.microsoft.com refused
jetbrains.buildServer.nuget.server.toolRegistry.FetchException: Connection to https://go.microsoft.com refused
 at jetbrains.buildServer.nuget.server.toolRegistry.impl.AvailableToolsStateImpl.fetchAvailable(AvailableToolsStateImpl.java:113)
 at jetbrains.buildServer.nuget.server.toolRegistry.impl.AvailableToolsStateImpl.getAvailable(AvailableToolsStateImpl.java:73)
 at jetbrains.buildServer.nuget.server.toolRegistry.impl.NuGetToolManagerImpl.getAvailableTools(NuGetToolManagerImpl.java:65)
 at jetbrains.buildServer.nuget.server.toolRegistry.tab.InstallToolController.doGet(InstallToolController.java:83)
 at jetbrains.buildServer.controllers.BaseFormXmlController.doHandle(BaseFormXmlController.java:61)
 at jetbrains.buildServer.controllers.BaseController.handleRequestInternal(BaseController.java:73)
 at org.springframework.web.servlet.mvc.AbstractController.handleRequest(AbstractController.java:153)
 at org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter.handle(SimpleControllerHandlerAdapter.java:48)
 at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:875)
 at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:807)
 at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:571)
 at org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:501)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
 at jetbrains.buildServer.rootDispatcher.TeamCityDispatcherServlet.service(TeamCityDispatcherServlet.java:430)
 at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
 at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
 at jetbrains.buildServer.web.SetThreadNameFilter.runChainWithModifiedThreadName(SetThreadNameFilter.java:9)
 at jetbrains.buildServer.web.SetThreadNameFilter.doFilter(SetThreadNameFilter.java:5)
 at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
 at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
 at jetbrains.buildServer.web.ResponseFragmentFilter.doFilter(ResponseFragmentFilter.java:19)
 at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
 at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
 at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
 at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
 at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
 at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
 at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
 at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298)
 at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:857)
 at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:588)
 at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489)
 at java.lang.Thread.run(Unknown Source)
Caused by: org.apache.http.conn.HttpHostConnectException: Connection to https://go.microsoft.com refused
 at org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:158)
 at org.apache.http.impl.conn.AbstractPoolEntry.open(AbstractPoolEntry.java:149)
 at org.apache.http.impl.conn.AbstractPooledConnAdapter.open(AbstractPooledConnAdapter.java:121)
 at org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:573)
 at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:425)
 at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:820)
 at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:754)
 at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:732)
 at jetbrains.buildServer.nuget.server.feed.reader.impl.FeedHttpClientHolder.execute(FeedHttpClientHolder.java:60)
 at jetbrains.buildServer.nuget.server.feed.reader.impl.UrlResolverImpl.resolvePath(UrlResolverImpl.java:68)
 at jetbrains.buildServer.nuget.server.feed.reader.impl.NuGetFeedReaderImpl.queryPackageVersions(NuGetFeedReaderImpl.java:60)
 at jetbrains.buildServer.nuget.server.toolRegistry.impl.AvailableToolsStateImpl.fetchAvailable(AvailableToolsStateImpl.java:81)
 ... 33 more
Caused by: java.net.ConnectException: Connection timed out: connect
 at java.net.PlainSocketImpl.socketConnect(Native Method)
 at java.net.PlainSocketImpl.doConnect(Unknown Source)
 at java.net.PlainSocketImpl.connectToAddress(Unknown Source)
 at java.net.PlainSocketImpl.connect(Unknown Source)
 at java.net.SocksSocketImpl.connect(Unknown Source)
 at java.net.Socket.connect(Unknown Source)
 at com.sun.net.ssl.internal.ssl.SSLSocketImpl.connect(Unknown Source)
 at org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:375)
 at org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:148)
 ... 44 more

15 comments
Comment actions Permalink

Thank you for report.

Please check TeamCity server instance is able to connect to microsoft.com. It uses "https://go.microsoft.com/fwlink/?LinkID=206669" as a reference to feed. The same logic is implemented in NuGet.exe.

As workaround, you may put latest NuGet.Commandline package (i.e. NuGet.CommandLine.1.4.20615.182.nupkg)  to <TeamCity data directory>/System/pluginData/jetbrains.nuget/nupkg and wait for server to detect the change.

0
Comment actions Permalink

If I login on the server (RDP) with the service account used for running Teamcity, the URL opens without any problem. I've downloaded the package manually and dropped it in the directory, you've mentioned.
If I run "NuGet.exe update -self" as the service account user, the URL is accessed successfully. Only the check via TeamCity fails.

Is there any other setting in Teamcity regarding HTTP-proxies, DNS, ...?

Do you have an issue tracker for the nuget plugin where we could file issues or feature requests?

Thanks in advance. Great work so far.

0
Comment actions Permalink

You may post issues to TeamCity project in our tracker at http://youtrack.jetbrains.net

Please attach logs from your server.
ake a look at http://confluence.jetbrains.net/display/TCD65/Reporting+Issues for more detils.

Do you run TeamCity behind proxy?

0
Comment actions Permalink

Yes, we run Teamcity behind a proxy.
I'll file an issue in your tracker (I know it already, but I was not sure since the NuGet-plugin is atm not a part of Teamcity).

0
Comment actions Permalink

I committed a fix to NuGet plugin to make it query "https://go.microsoft.com/fwlink/?LinkID=206669" and than (on erorr) "http://packages.nuget.org/v1/FeedService.svc"
Could you please try te fix and let me know if it would work. If not, you may try to capture HTTP traffic (say with Wireshark) to check the reply from the proxy.

0
Comment actions Permalink

Thanks a lot for your effort.

Sadly it also doesn't work. It looks like it is an issue with our network. I'll try to get a network trace to investigate the issue on this level.
I'll keep you updated.

-- Edit

Just to make sure, as I found no proxy related setting for Teamcity: Is there any configuration which should be adjusted for using TeamCity behind a proxy? Or does it respect the setting for the service account/system setting?

0
Comment actions Permalink

Sorry for log delay, I missed you changed the post.

There is no proxy server settings in TeamCity.
Please feel free to post an issue for TeamCit at http://youtrack.jetbrains.net

0
Comment actions Permalink

It seems I found the way to make NuGet plugin use HTTP proxy from system defaults.
I've just pushed the change. Please give it a try. You need build #0.5.1027.5 or newer. It will need 5-10 minutes to be compiled.

0
Comment actions Permalink

Sorry, but this does not work (for me). This shows me that it could only be an error on our side which I have to solve now.

btw: thank you so much for your support

0
Comment actions Permalink

I had the same issue with TeamCity 6.5 and followed the recommendation of copying the NuGet

.CommandLine nupkg file into the appropriate TeamCity folder which recognised the plu

gin successfully BUT if a newer version is released

in future, the team city option to install new versions of the NuGet.exe

doesn't seem to work. Is there an xml config file that contains the feed URL?

0
Comment actions Permalink

Do you mean a way to replace defauilt NuGet feed url with a custom one?
It is not yes supported.

As new version of NuGet is released, you may explicitly open 'NuGet' tab to install new nuget version. Than, you need explicitly select newer version of NuGet for every build configuration. Do you think we need to introduce a 'Default NuGet' option in all runner's settings to make it easy to switch nuget for all configuration in one click?

0
Comment actions Permalink

The problem was, when I attempt to "Install additional versions of NuGet.exe Command Line" from the NuGet tab, I get the following response:

Failed to fetch latest NuGet packages from default feed.
Failed to parse xml document. Error on line 1 of document http://mywebsite.com/re-direct.htm: The markup declarations contained or pointed to by the document type declaration must be well-formed.

As a result, this will mean I won't be able to download the latest version (when available) via TeamCity except by manually obtaining the .nupkg file and copying this into the relevant TeamCity folder.

0
Comment actions Permalink

How do you think it could be made more usable?

I had an idea to add there an option to upload custom nuget package. Do you think it'll resolve your issue? Another way to fix it is to allow using non-default nuget feed.

0
Comment actions Permalink

Hi Eugene,

I've just upgraded to Teamcity 7 and tried this again. Same issue. I've done a little research and found a solution.
I've set following parameter for the Teamcity Service

-Dhttp.proxyHost=_PROXY_HOST_HERE_
-Dhttp.proxyPort=_PROXY_PORT_HERE_
-Dhttps.proxyHost=_PROXY_HOST_HERE_
-Dhttps.proxyPort=_PROXY_PORT_HERE_

After a restart of the service, the connection problems are gone and I am able to install a new nuget command line package.

There are other problems with the nuget plugin, but these are not connected with this issue.

0
Comment actions Permalink

Thank you for workaround. I updated the related issue
http://youtrack.jetbrains.com/issue/TW-20402

0

Please sign in to leave a comment.