2012-04-26

Visual Studio OneClick Publish - Target machine actively refused it 128.30.52.37:80

The project is a VSTO Excel Add-In that retrieves additional information from web services hosted on our ERP system.  The end of this is an unresolved issue that we were able to work around by taking SharePoint out of the scenario.

One requirement: provide a deployment package that automatically installs new versions without requiring the user to manually uninstall previous versions.  Simple enough.  In the past I had always included a Visual Studio “Setup” project with my solutions.  There’s lots of flexibility there, but this was just an Excel Add-In.  I considered trying (again) Microsoft’s OneClick publishing mechanism.

I’m relatively new to OneClick.  I scanned through the documentation and configured the Publish pane to store the data onto my local hard drive with a URL off of our local SharePoint server.  Something like the following.  Side note: I tried using a WebDav UNC path to the SharePoint site, but VS2010 choked so I gave it up. Okay – I can copy the files there manually.

SNAGHTML296d7680

My project is designed to generate a prerequisite setup program for .NET Framework 4.0 Client Profile and VSTO 4 Runtime. Our SharePoint site is configured to disallow .exe files, so I zipped up my setup.exe before placing the entire installation at the SharePoint location defined above.

Without a setup.exe, this process works great.  The .vsto file is fully accessible; clicking only the .vsto file functions fine to install the Excel Add-In.

image

There’s a problem, however, when trying to use the setup.exe.  When using the setup.exe to initiate the installation, the following exception occurs.

************** Exception Text **************
System.Net.WebException: Unable to connect to the remote server ---> System.Net.Sockets.SocketException:
No connection could be made because the target machine actively refused it 128.30.52.37:80
   at System.Net.Sockets.Socket.DoConnect(EndPoint endPointSnapshot, SocketAddress socketAddress)
   at System.Net.Sockets.Socket.InternalConnect(EndPoint remoteEP)
   at System.Net.ServicePoint.ConnectSocketInternal(Boolean connectFailure, Socket s4, Socket s6, Socket& socket, IPAddress& address, ConnectSocketState state, IAsyncResult asyncResult, Int32 timeout, Exception& exception)
   --- End of inner exception stack trace ---
   at Microsoft.VisualStudio.Tools.Applications.Deployment.ClickOnceAddInDeploymentManager.GetManifests(TimeSpan timeout)
   at Microsoft.VisualStudio.Tools.Applications.Deployment.ClickOnceAddInDeploymentManager.InstallAddIn()

Researching online, I was able to find one reference to a deployment architecture similar to ours.  Here, someone on the Nintex forum discusses the same error within SharePoint.  Unfortunately no solution is available there.

Conjecture: It appears that while the .vsto file is being processed on the server an XML validation is failing.  Could the failure be due to security implemented on the server to disallow connections outside the firewall – in this case to hans-moleman.w3.org?  If that error happens under the watchful eye of the setup.exe, maybe the installation fails.  Working with our LAN team, we removed the “no external HTTP requests” restriction on the SharePoint server, but the problem was not resolved.

Supposing that SharePoint may be the culprit, I reconfigured the Publish pane to use a URL straight from an IIS server – no SharePoint involved.

SNAGHTML29947568

From this, I received two benefits.  First, I was able to move the entire installation to the web server share without having to first zip the setup.exe.  Second, and most important, the setup program functioned without error.  When SharePoint is not included and setup.exe accesses the .vsto file from IIS, then whatever caused the request to 128.30.52.37:80 either

  • does not occur or
  • does not fail or
  • the exception is not passed back to the setup program.

For us here, using IIS instead of SharePoint (essentially avoiding the problem) is a fine solution and we intend to make this the direction going forward for OneClick-published installation packages.  However – if anyone has additional information about the error or can propose a different solution, I would be interested in hearing it.

Jeff