Take the 2-minute tour ×
SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It's 100% free, no registration required.

Using SharePoint object model to add an new list item. All resources say the code should not have been affected in the upgrade. It builds with now errors ... deploys to the Sandbox and activates. The form opens in the browser with no error ... a critical error is thrown when at the clickedevent - This was working before the upgrade to the 15 bits. I also opened it in the InfoPath client and received the following error at the clickedevent:

Could not load file or assembly 'Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c' or one of its dependencies. The system cannot find the file specified. at RequestsV4.FormCode.SubmitEquipment_Clicked(Object sender, ClickedEventArgs e) at Microsoft.Office.Interop.InfoPath.SemiTrust._ButtonEventSink_SinkHelper.OnClick(DocActionEvent pEvent)

It referenced the version 14 - This is no help - I ran this through a dev environment running SharePoint Server 2013 and InfoPath 2013 with the same disappointing result. I have also ran this against two separate Office 365 tenancies running the 15 bits.

Please help!

using Microsoft.Office.InfoPath;
using System;
using System.Xml;
using System.Xml.XPath;
using Microsoft.SharePoint;

namespace RequestsV4
{
public partial class FormCode
{

    public void InternalStartup()
    {
        ((ButtonEvent)EventManager.ControlEvents["SubmitEquipment"]).Clicked += new ClickedEventHandler(SubmitEquipment_Clicked);
    }

    public void SubmitEquipment_Clicked(object sender, ClickedEventArgs e)
    {
        // Use InfoPath OM's ServerInfo.SharePointSiteUrl property to programmatically
        // specify the site where the form is published.
        using (SPSite FormSite = new SPSite(ServerInfo.SharePointSiteUrl.ToString()))
        {
            using (SPWeb FormWeb = FormSite.OpenWeb())
            {
                // Get the SharePoint list.
                SPList LookupList = FormWeb.Lists["RequestList"];

                SPListItem NewItem = LookupList.Items.Add();
                // Set the value of the Title field in the list to the value in Combo Box on the form.
                NewItem["Title"] = GetDomValue("/my:myFields/my:RequestName");

                // Set AllowUnsafeUpdates to 'true' to temporarily allow updates to the database.
                FormWeb.AllowUnsafeUpdates = true;
                NewItem.Update();

                // Set AllowUnsafeUpdates back to 'false' to prevent further updates to the database.
                FormWeb.AllowUnsafeUpdates = false;
            }
        }
    }
    private string GetDomValue(string XpathToGet)
    {
        return this.CreateNavigator().SelectSingleNode(XpathToGet, this.NamespaceManager).Value;
    }

}

}

share|improve this question
    
I appreciate your question and wondered if you have any details or resolutions yet to your problem. I have a tenant that also received the update during this same release and a working system is now - not working. I have service requests opened with Microsoft around this issue but am not seeing the progress that I need or expect. Through much effort, I know the line of code that is throwing the error in our forms and it directly correlates to your initial using statement. From what I have gathered, the assignment is failing and throwing the error. Any how, we are deep in this and I was actuall –  user16125 Apr 4 '13 at 18:44
    
Daniel, I also have a service request in - thankfully it was escalated to technical out of the gate - it is a problem with assignment and has to do with the .net version reference. It was escalated to the SP Product team - the code should work and I have received no feedback that leads me to believe that there will not be a resolution. The only workaround for my code would be web services, specifically lists.asmx - which only works in the InfoPath client on Office 365, which does not meet my requirement. –  Greg Apr 4 '13 at 20:12
add comment

2 Answers

When I do InfoPath form code development, I usually have a folder that I keep with my projects that has some of the 12/14 assemblies in it so that I can reference them without doing development on the server.

Try getting a copy of the 15 Microsoft.SharePoint.dll out of the GAC of a SP2013 server, removing your reference to Microsoft.SharePoint.dll from the project, and then re-add the reference, this time browsing to the location of the DLL where you saved it to. Be sure to change the reference properties make sure that Copy Local is false, or else your form will package in the assembly and it'll be humongous.

If you don't know how to get the assembly from the GAC, the easiest way is to drop into a command-line (shouldn't need to be Administrator-elevated), cd into C:\windows\assembly\gac_msil\Microsoft.SharePoint , CD into the build folder (there should only be one DLL version on the server), and then "copy * C:\myfolder". Move that DLL into a good place for your development, and you're all set.

This is a rather unorthodox way to do things and probably not "best practice" but it works and saves me a lot of grief.

While you're in C:\windows\assembly\gac_msil, you might also want to get others like Microsoft.SharePoint.Security.dll, Microsoft.SharePoint.Taxonomy.dll, and Microsoft.Office.Server.dll.

share|improve this answer
    
Drew, thank you! before submitting this, I spun up a 2013 dev environment to do just that - changed all my tooling to 2013 and referenced the subset version of the Microsoft.SharePoint.dll - same result. It appears to be a .net version issue server side - very frustrating! Do you have code-behind forms working on Office 365 (15)? –  Greg Apr 4 '13 at 20:17
    
I do not, because I haven't tried yet, but I had this exact problem going from 12 to 14 and this was how I solved it. –  Drew Lanclos Apr 4 '13 at 21:27
    
I have a dev 2013 environment set up, I might try to do this with one of my smaller forms just so I can see if it works. Watch this space. –  Drew Lanclos Apr 5 '13 at 15:57
    
Thanks, Drew - The SP Product team is working on this to find a best practice for the code. In fact they have dedicated an InfoPath developer to it full time until it is fixed. - I appreciate you confirming this. –  Greg Apr 5 '13 at 16:50
add comment
up vote 0 down vote accepted

It was determined by Microsoft Online Support that this was a Office 365 wide issue. As of today 5.6.2013 a hotfix was applied to the farm that I was working in when I experienced this error. Everything is working as it should. If you experience an InfoPath code error ... spin up a support case and see if your farm has had this hotfix applied.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.