Eric Laschinger

I encountered this very frustrating error deploying a new web service to a test machine.  Everything was working great in the dev environment. My dlls were appearing in bin and there was no need to install to the GAC.  Copying published files straight from dev to test; and a detailed comparison of IIS settings between the two environments yeilded no clues.

The Solution: If the third party dll was built using Visual C++ (apparently the .NET Connector was?) and the machine you are deploying to does not have Visual Studio installed on it (mine did not); try installing the the MS Visual C++ Redistributable Package. If the YSOD complains about a dll compiled to x86 install the x86 version of the redistributable.  Likewise, if the dll is 64 bit, install the x64 package.

Microsoft Visual C++ 2010 Redistributable Package (x86): http://www.microsoft.com/download/en/details.aspx?id=5555

If you’re running a x64 environment you may install both the x86 and the x64 packages with no ill effects.  Obviously, if you’re running a 32 bit OS don’t install the x64 package.

Microsoft Visual C++ 2010 Redistributable Package (x64): http://www.microsoft.com/download/en/details.aspx?id=14632

Related solutions:

• http://stackoverflow.com/questions/3104988/trouble-registering-chilkatdotnet4-dll-to-the-gac
• http://groups.google.com/group/pdfnet-sdk/msg/779a01bacdd4b495

Do you need to make changes to a published InfoPath form template in SharePoint 2007  but don’t have the original files? Perhaps the files you do have in source control are several versions behind what is currently hosted on SharePoint? SharePoint gives users a convenient way to upload new form templates but doesn’t allow users to download the “live” form templates that are hosted on SharePoint with similar ease.  You can download a copy of any form template hosted in a SharePoint 2007 site collection using the following path:

http[s]://[domain or hostname]/sites/[site collection name]/formservertemplates/[form template name].xsn

Note: Path may be different depending on how your SharePoint site/site collection hierarchy is implemented.

Note: Some browsers (notably FireFox) will attempt to render the form automatically.  Make sure you “save as” rather than attempt to open or view the file.

Downloading and modifying “live” InfoPath data connection files is similarly obscured by SharePoint.   Editing the properties of a data connection file from the central admin only gives the user a few (rather unhelpful) metadata points to modify.  The meat of the data connection xml underlying the udcx file remains hidden from view.  You can download a copy of any data connection file hosted in a SharePoint 2007 site collection using this path:

http[s]://[domain or hostname]/sites/[site collection name]/dcl/[data connection file name].udcx

Note: Path may be different depending on how your SharePoint site/site collection hierarchy is implemented.

You should also be able to get an idea of where your data connection file is hosted by examining the InfoPath from template that uses it.  The steps for InfoPath 2010:

1. Click on the data tab and select “Data Connections” from the navigation ribbon.
2. Highlight the data connection you’d like find and look at what is provided by the details panel.
3. The connection source path concatenated with the value under “Data connection file” should provide you with the appropriate path to download the udcx file.

Note:  Modifying this file by hand and uploading to SharePoint is not advised.  If you have the ability to create a new data connection file from scratch using InfoPath that is a much better option.  I would recommend using this only if  your data connection change is relatively simple like changing the destination path from one document library to another.

Much of my more recent development work over the last few weeks has been in system integration using the SAP .NET Connector v3.0.  I recently encountered this error creating a WCF web service to securely expose an SAP remote function call.  The function call had been tested extensively and I had a working example of the Connector up and running in another project, but when I to execute the line:

RfcDestination destination = RfcDestinationManager.GetDestination(“SAP_NCO_CONNECTIONSTRING”);

The service would throw and bubble up the exception:

exePath must be specified when not running inside a stand alone exe

The method RfcDestinationManager.GetDestination (implemented within the 3rd party sapnco.dll) uses the method ConfigurationManager.OpenExeConfiguration to open the project configuration file to pull out the appropriate “destination” in the configuration section <SAP.Middleware.Connector>, that has the NAME attribute of “SAP_NCO_CONNECTIONSTRING”.  Here’s the pertinent sections from my Web.Config (sensitive information removed of course):

<configuration>
<configSections>
<sectionGroup name=”SAP.Middleware.Connector”>
<sectionGroup name=”ClientSettings”>
<section name=”DestinationConfiguration” type=”SAP.Middleware.Connector.RfcDestinationConfiguration, sapnco” />
</sectionGroup>
</sectionGroup>
</configSections>
<SAP.Middleware.Connector>
<ClientSettings>
<DestinationConfiguration>
<destinations>
<add NAME=”SAP_NCO_CONNECTIONSTRING” USER=”XXXXX” PASSWD=”XXXXX” CLIENT=”300″ LANG=”EN” ASHOST=”X.X.X.X” SYSNR=”01″ MAX_POOL_SIZE=”10″/>
</destinations>
</DestinationConfiguration>
</ClientSettings>
</SAP.Middleware.Connector>
</configuration>

While RfcDestinationManager.GetDestination works great for Windows/Console stand-alone applications, if you plan on using the .NET Connector within a service application (WCF), the method call ConfigurationManager.OpenExeConfiguration will throw the above exception.  Since no executable is created there is no exePath that can be passed to the method.  Unfortunately, the section of code making the call to OpenExeConfiguration is located within a 3rd party dll, so many of the popular solutions to this problem – featured here: (http://pcsmitpra.blogspot.com/2011/04/title-exepath-must-be-specified-when.html), here: (http://stackoverflow.com/questions/235618/wcf-and-system-configuration-namespace), and here: (http://social.msdn.microsoft.com/forums/en-US/csharpgeneral/thread/4ab25de2-4278-4d62-b2c1-c4dfc8975605) – were not a viable options for me.  I probably could have started modifying the SAP .NET Connector source and compiled my own dlls, but a cursory search did not reveal the licensing terms under which the software was released.  Any custom modifications could also present compatibility issues down the road when/if we decide to upgrade to the next version of the .NET Connector.

If you run into this issue and cannot change the method used to read from the configuration file, as described in the links above you may want to use my less desirable solution of turning on ASP.NET compatibility.

Solution:

Set aspNETCompatibilityEnabled=”true” in your Web.config.  Example:

<system.serviceModel>
<serviceHostingEnvironment  aspNetCompatibilityEnabled=”true” />
</system.serviceModel>

Decorate the class containing your code which connects to SAP with this statement:

[AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Allowed)]
public class MyClassName : IMyClassName
{

}

You will also need to add a using statement for the namespace System.ServiceModel.Activation.

For more information on how these changes will modify your WCF Service see (http://msdn.microsoft.com/en-us/library/system.servicemodel.activation.aspnetcompatibilityrequirementsattribute.aspx) and (http://msdn.microsoft.com/en-us/library/aa702682.aspx).

Very convenient when writing to a log file.  You can additionally take XML representation of the object from the log file and retroactively re-create the object in memory by deserializing that XML string and casting to the appropriate object type.

public override string ToString()
{
System.Xml.Serialization.XmlSerializer x = new System.Xml.Serialization.XmlSerializer(this.GetType());
StringWriter writer = new StringWriter();
x.Serialize(writer, this);
return writer.ToString();
}

After uninstalling the reporting services add-in from a SharePoint 2007 installation I was greeted with this error the following morning.  No matter which SharePoint page/site I tried to access, I’d get the same error:

Obviously I did not have remote errors enabled in my web.config.  Rather than turning them on, just take a look at your application event log to see what’s been going on behind the scenes.

The true errors (there were many more but these were at the heart of the matter):

Error: Failure in loading assembly: Microsoft.ReportingServices.SharePoint.UI.WebParts, Version=9.0.242.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91

Error: Failure in loading assembly: Microsoft.ReportingServices.SharePoint.UI.ServerPages, Version=9.0.242.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91

What the Microsoft TechNet “How to” (http://technet.microsoft.com/en-us/library/aa905871.aspx) fails to mention is that on installation of the add-in adds several lines to the HttpHandlers section of the web.config of both the central admin and the root SharePoint site.  To complete in uninstall you’ll need to remove (or preferably comment) out the following lines (your version number and/or public key token may be different from mine):

<add verb=”*” path=”Reserved.ReportViewerWebControl.axd” type=”Microsoft.Reporting.WebForms.HttpHandler, Microsoft.ReportViewer.WebForms, Version=8.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a” />
<add verb=”*” path=”_vti_bin/ReportServer” type=”Microsoft.ReportingServices.SharePoint.Soap.RSProxyHttpHandler, RSSharePointSoapProxy, Version=9.0.242.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91″ />
<add verb=”*” path=”Reserved.ReportViewerWebPart.axd” type=”Microsoft.ReportingServices.SharePoint.UI.WebParts.WebPartHttpHandler, Microsoft.ReportingServices.SharePoint.UI.WebParts, Version=9.0.242.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91″ />

The reporting services add-in (http://msdn.microsoft.com/en-us/library/bb283190.aspx) does a terrible job of uninstalling itself from SharePoint 2007.  Expect to continue to see reporting services objects littering your central admin into the distant future.  When and if we choose to set up a secondary instance of reporting services in integrated mode I am not looking forward to installing the SQL 2008 R2 add-in and discovering what issues and incompatibilities lay ahead.

Unless you are planning to run a full dashboard style “report” page or site in SharePoint, it hardly seems worth the effort (installing a reporting services instance in SharePoint “integrated mode”, installing the add-in, configuring each using the appropriate permissions, service accounts, etc…).  With all the hoops you need to jump through I would ask any developer to seriously evaluate the utility of seeing a report from within a SharePoint web part versus just running or linking to the same report in your reporting services native install.  In most cases I would say no.  Microsoft really needs to make this feature/integration more streamlined.

A secondary error (cause is unknown – but started appearing at the same time as the rest of the errors)  caused my SharePoint logs to sometimes ballon to upwards of 500mb in size.  This made it extremely difficult to view the log and determine exactly what was going on:

“The previous instance of the timer job ‘[Job Name]‘, id ‘{[Guid]}’ for service ‘{[Guid]}’ is still running, so the current instance will be skipped.  Consider increasing the interval between jobs.”

Joe Rodgers has a great blog post (http://blogs.msdn.com/b/josrod/archive/2007/12/12/clear-the-sharepoint-configuration-cache-for-timer-job-and-psconfig-errors.aspx) explaining how to clear up the issue, so you can get a better look at those SharePoint log files.