InfoPath Dev

Using a sample I built according to the PDF instructions, I get this error:

Action: SaveToSharePoint
 Arguments: System.Collections.Generic.Dictionary`2[System.String,System.String]
 Details: Request for the permission of type 'System.Security.Permissions.EnvironmentPermission, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' failed.
Stack:   at System.Security.CodeAccessSecurityEngine.Check(Object demand, StackCrawlMark& stackMark, Boolean isPermSet)
   at System.Security.CodeAccessPermission.Demand()
   at System.Net.CredentialCache.get_DefaultCredentials()
   at Qdabra.Tools.RulesLibrary.Commands.SaveFileToSharepoint(String& base64Value, String& url)
   at Qdabra.Tools.RulesLibrary.Commands.SaveToSharePoint(String url, String domName, String nodeXPath)
   at Qdabra.Tools.RulesLibrary.Commands.SaveToSharePoint()
   at Qdabra.Tools.RulesLibrary.Commands.ExecuteCommand(Application application, XmlFormHostItem formHost, XPathNavigator commandsNavigator)

Using Ernesto's sample XSN from the demo video, I get this similar error:

Action: SaveToSharePoint
 Arguments: System.Collections.Generic.Dictionary`2[System.String,System.String]
 Details: Request for the permission of type 'System.Net.WebPermission, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' failed.
Stack:   at System.Security.CodeAccessSecurityEngine.Check(Object demand, StackCrawlMark& stackMark, Boolean isPermSet)
   at System.Security.CodeAccessPermission.Demand()
   at System.Net.HttpWebRequest..ctor(Uri uri, ServicePoint servicePoint)
   at System.Net.HttpRequestCreator.Create(Uri Uri)
   at System.Net.WebRequest.Create(Uri requestUri, Boolean useUriBase)
   at System.Net.WebRequest.Create(String requestUriString)
   at Qdabra.Tools.RulesLibrary.Commands.SaveFileToSharepoint(String& base64Value, String& url)
   at Qdabra.Tools.RulesLibrary.Commands.SaveToSharePoint(String url, String domName, String nodeXPath)
   at Qdabra.Tools.RulesLibrary.Commands.SaveToSharePoint()
   at Qdabra.Tools.RulesLibrary.Commands.ExecuteCommand(Application application, XmlFormHostItem formHost, XPathNavigator commandsNavigator)

I'm striking out so far with the qRules testing.

Environment:

- MOSS 2007 Enterprise SP1 + Infra on W2K3 w/SQL 2005

- IP2007 form template published to same site as the doc lib

- Kerberos is active but no SSL

- 3-server pilot farm with DB + WFE + APP

- I'm a site collection administrator

Hi Clayton,

Thank you for trying qRules. Are you trying to Preview the form or publish and run? Is the site you are publishing to in Trusted Sites? If so, remove and add to Local Intranet.

If that doesn't fix it, it's possible that the URL is wrong or that you are trying to use it with browser forms (not supported).

Once again, THANK YOU for trying qRules out. We appreciate your feedback and after we figure out what problem you are having, we will document it so others don't experience issues like this in the future.

1) Started by previewing but then saw the requirement for it to be published and still got the error. 

2) It is a Trusted Site, so I will change and check.

3) The URL is a copy and paste from the address bar when browsed to the doc lib

4) Blank template was created without checking the box for browser-enabling, and the form is in rich client mode during testing

BRB after switching the zone.

Trusted Sites run at lower permission than is necessary for .NET code. QRules is a set of .NET assembly that provide common functionality. As such, it needs to run as local intranet or just default (nothing) but not Trusted Sites. Trusted Sites actually lowers the permissions and prevents .NET code from running in an InfoPath form with Domain trust.

Bah!  Those settings are controlled and restricted via Group Policy.  I will go onto the server to see if I can work around it, but that would only be a temporary bandaid, because the group policy would get in the way for future production use...

Ok, I'm a local admin on the WFE, so I was able to modify the zone settings.  It worked perfectly with the site in Local Intranet.

This will be a definite issue not only here but with other clients.  Has there been any thought or work put into figuring out how to still get it to work in the Trusted zone for those who will have no way of changing that?

Excellent! We've definitely seen this issue a couple times. I will check with support and see if we have a release note on this. At the very least, now we have it documented here. :)

Did this issue ever get resolved?  I could really use this as a solution for a form I'm working on.

IE security zones and .NET permissions have issues. For example, InfoPath forms with .NET code won't work in a Trusted Zone. Trusted Zone used to be used for non .NET apps and it is not best practice. This has nothing to do with qRules. This is about .NET permissions and IE security zones.

 If you have a .NET form running in a local intranet, the IE security zone must be set to Local Intranet.