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.

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.

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.

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

WD Screen Variants - Component Usage

overview

<< previous

This is the last installment of this series.  Although it took some time, I enjoyed putting it together and hope you found it useful.

The concept of a selection screen variant is something that most SAP users have come to expect, yet this feature is unavailable in standard Web Dynpro. Below is the next in a series of posts detailing how to bring this necessary feature back to Web Dynpro. Start here to see the full requirements.

Now I’m going to show how easy it is to use the variant component in your own Web Dynpro component.  Start off by creating a new Web Dynpro component that uses one or more components of type WDR_SELECT_OPTIONS and this custom variant component.

In your view Layout, add a ViewContainer UI element.  In the associated window, right-click on the ViewContainer and embed the ZES_SELOPT_VARIANT component.

In your view Context, create a new controller usage of both Select Options and the Variant components.

In your view WDDOINIT method, initialize the Select Options component just as you would any other time.  My method looks like this.

   1: METHOD wddoinit .                                           " PLM8034

   2:  

   3:   DATA: lr_controller                 TYPE REF TO if_wd_controller.

   4:   lr_controller ?= wd_this->wd_get_api( ).

   5:   wd_this->m_msgman = lr_controller->get_message_manager( ).

   6:  

   7:   me->init_alv( ).

   8:   me->init_selection_screen( ).

   9:   me->init_variant_selector( ).

  10:  

  11: ENDMETHOD.

After initialization of the selection screen, you must initialize the ZES_SELOPT_VARIANT component. After creating the component usage, you get a handle to the interface and do both of the following:

1. Set the program name.  All variants are saved against this report id.


2. Append one or more selection screens to the variant.  All fields from all selection screens are available within the variant.  An important caveat: if you attach more than one selection screen to the variant, you must manage distinct field names.

   1: METHOD init_variant_selector .                              " PLM8034

   2:  

   3:   " create the used component

   4:   DATA l_cmp_usage                    TYPE REF TO if_wd_component_usage.

   5:   l_cmp_usage = wd_this->wd_cpuse_variant( ).

   6:   IF l_cmp_usage->has_active_component( ) IS INITIAL.

   7:     l_cmp_usage->create_component( ).

   8:   ENDIF.

   9:  

  10:   " get a pointer to the interface controller of the component

  11:   wd_this->m_wd_variant = wd_this->wd_cpifc_variant( ).

  12:  

  13:   wd_this->m_wd_variant->set_report_name( 'ZEMR_GCS_REPORT_RPT6' ).

  14:   wd_this->m_wd_variant->append_selopt_screen( wd_this->m_selopt1 ).

  15:   wd_this->m_wd_variant->append_selopt_screen( wd_this->m_selopt2 ).

  16:  

  17: ENDMETHOD.

It’s really that easy.  Save and activate your component and you’ll have a robust selection screen with classic variant functionality.

Thanks for reading about it.  Feel free to drop a comment with questions or suggestions.

overview

<< previous