Tuesday, November 21, 2006

Catastrophic Error, Multiple Infopath Forms

An error that seems to be plaguing a number of people occurs during the following scenario:

A user attempts to open a new instance of InfoPath, loading a form that is based on a template that there is already a form open form. When the form attempts to load InfoPath spits back a helpful error: "Catastrophic failure!".

A workaround for this, which I am not convinced is the best solution, is to remove the name attribute from the processing instructions.

So typically you may have a PPI that looks like this:


<?mso-infoPathSolution solutionVersion="1.0.0.562" productVersion="11.0.6565" PIVersion="1.0.0.0" href="file:///\\yourhost\templates\yourTemplate.xsn" name="urn:schemas-microsoft-com:office:infopath:yourTemplate:-myXSD-2006-06-12T01-41-41" ?><?mso-application progid="InfoPath.Document"?>


Change this to:
<?mso-infoPathSolution solutionVersion="1.0.0.562" productVersion="11.0.6565" PIVersion="1.0.0.0" href="file:///\\yourhost\templates\yourTemplate.xsn" ?><?mso-application progid="InfoPath.Document"?>


This will do the trick it seems.

Friday, July 21, 2006

Mismatched Hosts, Binding Drama and BTS 2006 Reconfiguration

Recently, for a frustrating reason, I had to unconfigure a BizTalk server located in the development environment at a client's site. Later, when reconfigured, I came accross an interesting error when I tried to redeploy some of the orchestrations:

Error 6 Failed to add resource(s). Change requests failed for some resources. BizTalkAssemblyResourceManager failed to complete end type change request. Failed to update binding information. The following items could not be matched up to hosts due to name and/or trust level mismatches: Item: 'APS.Search.GetChildDetails.Orch_GetChildDetails' Host: 'BTS_APS' Trust level: 'Untrusted'You must do one of the following:
1) Create hosts with these names and trust levels and try again
2) Re-export the MSI without the binding files and have a post import script apply a suitable binding file.

The symptom of my problem seemed basic enough- when the assembly was attempting to deploy to the BTS server it was utilising a prior binding file that was not configured properly to interact with the reconfiguration. I googled and google-grouped the error and came up with nothing. I assume that the binding file is embedded in the assembly somewhere, but where I do not know! What I did work out was how to solve the problem.

Presumably if you googled the error you just want the damned solution, so here it is- changed the strong key associated with the project and rebuild. This seems to remove whatever binding file was associated with the assembly and allows for smooth deployment, all things being equal.

So if you have any idea where this binding file is actually located, please comment as I'd love to know.

Tuesday, February 21, 2006

Introduction

G'Day Viewers,

I am a .net developer based in Perth, Australia. I intend to use this blog as a place to put the solutions I come up with to the various problems I face. I primarily develop BizTalk based solutions but as expected, I am involved in many other .NET related projects.

Ben Szymkow