Well, I had to break a rule but I decided to go ahead and do some simple .NET managed code on a web enabled InfoPath form I need to build. I followed my instructions on How to Deploy an InfoPath Form as a Feature and I started to get errors when accessing my form.
Error Message
An exception occurred during loading of business logic. (User: SHAREPOINT\administrator, Form Name: ContractsApprovalRequestForm, IP: , Request: http://mossserver:28921/_layouts/FormServer.aspx?XsnLocation=http://mossserver:28921/FormServerTemplates/ContractsApprovalRequestForm.xsn&SaveLocation=http://mossserver:28921/contractsapproval/Contract+Approval&Source=http://mossserver:28921/contractsapproval/Contract%2520Approval/Forms/AllItems.aspx&DefaultItemOpen=1, Form ID: urn:schemas-microsoft-com:office:infopath:ContractsApprovalRequestForm:-myXSD-2008-12-12T02-14-05, Type: FileNotFoundException, Exception Message: Could not load file or assembly 'file:///C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\Template\Features\ContractsApproval.Form.Request\ContractsApproval.Form.Request.dll' or one of its dependencies. The system cannot find the file specified.)
Cause
Since the form was installed to SharePoint using a Feature the apparently the DLL that is part of the XSN is not extracted by Form Services when the form is installed as a Feature. For detailed information read KB 930894. What I found out is that this is a common issue for InfoPath association, initiation and task forms that are part of a workflow. I had not run into this because I have tried to not use .NET managed code when doing InfoPath development.
Resolution
The solution is to get the dll for the InfoPath form and place it with the XSN. In this case, it would be in the Feature folder for the InfoPath form in the 12 Hive. Installing it in the GAC of the machine does not resolve the issue…
To resolve this in my How to Deploy an InfoPath Form as a Feature blog, modify the WSP.ddf to grab the dll and package it up in the WSP.
No comments:
Post a Comment