InfoPath Dev

Thye have found an issue on their web server that is causing link problems.  When this issue is fixed, it may resolve the other issues with qRules,  My case is escalated to the InfoPath team in Redmond, I will be talking to their techs today and will let you know what I find out.  Does Qdabra have a Service Ticket open wiht MS concerning this issue?  If not please enter one, I mentioned that your company was ecperiencing the same issues.

The list keeps growing. http://support.microsoft.com/kb/2789555

Jerry have you heard anything back from MS?

Operations has determined that the issue concerning links to IP forms is being caused from the Office 365 web servers and is a direct result of the SU4 upgrade.  This issue is:

1. Link errors when using the "Email a link" button on the Ribbon to send an email with a link to an InfoPath form.

2. Cannot open the links from a search in a Forms Library that is using an IP form as the default form. (clicking the IP form link in the search results fails)

3. Workflow links that use the action "Send an Email" that have a link to the current Item in the body of the email do not work.

 The error received when clicking the link in any of the 3 above situations results in an error - "The following location is not accessible because it is in a different site collection, https://...........xml.

The issue with not being able to publish IP forms using qRules is still open awaiting a resolution to the issue above.  Once the issue above is fixed with the Web Server, it may result in fixing the publishing of Browser forms.  I am able to publish brower forms as long as the form is not using qRules.  I am not able to rerpoduce the issue when the form is not injected.  If you have an example of a situation where you cannot publish an IP browser form and not using qRules, please let me know and I will try and reproduce it.

MS has stated that they will not support the issue if it is only being reproduced when qRules is used.  When the form is injected, it adds a Qdabra .dll file and if the dll file is in the template, they are not supporting.I have a few browser based IP forms that are not using qRules that I am able to publish fine.

It would be interesting to test a form with code.

Some simple code, nothing as complex as qRules, but since all forms with code include a DLL, I wonder what Microsoft will say.

After all, any user who has coding experience can add custom code to an InfoPath form.

If they are not supporting any custom code, I imagine that will upset quite a large number of users.

I have attached a form with some very simple code. Want to test publishing it to the browser?

I cannot open your form, I get the attached error:

Save the XSN to your local drive, then right click on the file and select Design.

Then you can go thru the publishing wizard.

Looks like this could be the problem. Can you tell me what type of code is in the template.  I cannot see any of the code because i get the error that the C# or VB code is not included in the template.  Let me know how I can create a similar form and I will send this to MS.

I tried what you just did with Hilary awhile ago and it didn't work. Actually I just tried again and it does work.

I created a form with a dim statement in the form load and received the error. Sent repor instructions to MS to see if we can get the Sandboxed Solutions turned on.

Try uploading the form I attached.

Hi Jerry, Have you got any new information on browser forms with code?

We have made some progress.  We are able to publish browser forms with code at this point, MS is working on determining the issue with the templates that are using qRules.  I am hoping to hear back from them today.  They have reproduced the errors and have 4 of my templates.  One of the programmers has thier own code that performs the same function as the Sumbit TO SharePoint in qRules and it works fine.  They believe that there is something in the .dll that may be causing the issue. 

 The developer I am working with knows the owner of Qdabra, he was considering a call to discuss.  You should test a form that has custom code in it to see if it is working now.  This may be something that was fixed in our farm and not yours, I cant be sure.  MS has also fixed the issue with the IP form links not working from the "Send and Email" and when generating a hyperlink from a workflow.  They out that hotfix on our farm on Friday, if your farm is not yet fixed then it should be updated this week.

One value peice of info I go from the programmer is when you publish an Browser enabled InfoPath Form Template, with code, directly to a SharePoint library the process that is used to complete the publishing is the SPUserCode worker process.  If the SPUserCode worker process takes more than 30 seconds to complete, the form will error with the message that the form has been published but can only be opened in the client.  The reason behind this is that the browser code conversion process didnt complete so the form gets published and the only available config is the client.

Thank you for the update. I am glad you are making far better head way then I am. The people I have spoken to at MS are still tier 1 people who don't know whats going on. I sure hope they figure out what they broke in 2013 that worked fine in 2010.

Hey, Jerry, thanks for the update - I've been emailing with the same MS resource you've been working with - we are trying to determine why a form with the qRules DLL injected takes longer to convert in IPFS than his form with custom code - the initial thought we had was the size of the code DLL (the qRules DLL is much larger than the one with his single method to upload to SharePoint), but then he added a reference to the qRules DLL to his code file and the upload still took less time. I'm hopeful I'll hear more today.