itaysk

Itay has reported this issue and i had same issue with my development environment. Request failed. System

To allow the form template's business logic to call this member when it is being debugged or previewed, you must set your form template's security level to Full Trust as described in the following procedure.

Configuring a Managed Code Form Template that Requires Full Trust

Set your form's security level to Full Trust

If you are working in InfoPath, open the form template in design mode.

If you are working in Visual Studio, open the InfoPath Form Template project, and then click the manifest.xsf [Design] tab to display the form designer.

On the Tools menu, click Form Options.

In the Category list, click Security and Trust.

Under Security Level, clear Automatically determine security level.

Select Full Trust, and then click OK.

Actually, if you set your form to use full trust it will only run on people's machines if you sign it with a certificate that they trust.

Another workaround is to follow the steps at msdn.microsoft.com/.../aa943232.aspx under the section titled "Assigning FullTrust to Forms at a Specific URL or UNC".

This just solved the problem for me, but note that after creating the new node, the "Microsoft .NET Framework 2.0 Configuration" tool renamed the node to "Copy of InfoPath Form Templates" for some reason, and I had to change the name back to "InfoPath Form Templates" before it would work.

Hope that helps.

I think the original message by Itay is accurate.  I have the same problem.  When a form has managed code, rules, web service data connections, SharePoint data connections, etc.  and Domain trust level, I see the same errors if a workstation (Windows XP SP3 or Windows Vista) has .NET 3.5 installed.  A machine with .NET 3.0 or less does not have problem.  Initially, I thought it has to do with administrative rights when a user logs on into a pc; but it is not the case.  I logged on into my windows XP SP2 (with .NET framework 3.0) and I don't have admin rights to my pc, the form works fine with managed code and rules,etc.  Another user who logs on into the machine without admin rights has problem running the form; and the difference is the .NET framework.  I need to further find out whether or not it is related to MSXML version 6.0.

FYI, when you are developing a .xsn template, you set it to Full trust; PRIOR to publishing the form to SharePoint as a content type template and not as browser-enabled form, you set security to Domain.

What we found is the form will need to be full trust and signed with a digital certificate and published to SharePoint Form library to solve the error.

Since I can't obtain a certificate issued by a Central Authority, so I created my own certificate to sign it.  When other users open the form from SharePoint, they see a prompt warning about risk opening the form.  Click Open button, the form is opened and works fine.

I think the issue is the security introduced and not the .NET 3.5.

Another way is to create an installable template (as an MSI installation file) which is equivalent to deploying the form as a windows-based form.  After installing the MSI file, you have a .xsn form template and a supporting file .exe under the installation folder.  Your form, upon submit, is still posted into SharePoint because you specify how the submit is done.