There is an unclosed literal string. Line 1, position 411.

I was recently quite scared to see an exception message thrown up from my Infopath form published to a sharepoint list. And most interestingly while I was trying to the same operation from Infopath designer preview, form was working correctly without any exception.

After a bit of search here and there I could not find any solution.

Suddenly I realised that the event causing this exception trying to use a filed which does not exist in the form.

So if you are seeing the same error message most probably your code is trying to access a field that does not exist or you have misspelled the name.

------------ exception message ------------

There is an unclosed literal string. Line 1, position 411.

System.Xml.XmlException: There is an unclosed literal string. Line 1, position 411.
at System.Xml.XmlTextReaderImpl.Throw(Exception e)
at System.Xml.XmlTextReaderImpl.Throw(String res, String arg)
at System.Xml.XmlTextReaderImpl.ParseAttributeValueSlow(Int32 curPos, Char quoteChar, NodeData attr)
at System.Xml.XmlTextReaderImpl.ParseAttributes()
at System.Xml.XmlTextReaderImpl.ParseElement()
at System.Xml.XmlTextReaderImpl.ParseElementContent()
at System.Xml.XmlTextReaderImpl.Read()
at System.Xml.XmlLoader.LoadNode(Boolean skipOverWhitespace)
at System.Xml.XmlLoader.LoadDocSequence(XmlDocument parentDoc)
at System.Xml.XmlLoader.Load(XmlDocument doc, XmlReader reader, Boolean preserveWhitespace)
at System.Xml.XmlDocument.Load(XmlReader reader)
at Microsoft.Office.InfoPath.Server.Xml.InfoPathXmlDocument.Load(XmlReader reader)
at Microsoft.Office.InfoPath.Server.DocumentLifetime.DataObject.<>c__DisplayClass3.<.ctor>b__0()
at Microsoft.Office.Server.Diagnostics.FirstChanceHandler.ExceptionFilter(Boolean fRethrowException, TryBlock tryBlock, FilterBlock filter, CatchBlock catchBlock, FinallyBlock finallyBlock)
at Microsoft.Office.Server.Diagnostics.ULS.SendWatsonOnExceptionTag(ULSTagID tagID, ULSCat categoryID, String output, Boolean fRethrowException, TryBlock tryBlock, CatchBlock catchBlock, FinallyBlock finallyBlock)
at Microsoft.Office.InfoPath.Server.DocumentLifetime.DataObject..ctor(EnhancedBinaryReader reader, Solution solution)
at Microsoft.Office.InfoPath.Server.DocumentLifetime.DataObjects.<>c__DisplayClass2.<.ctor>b__0(EnhancedBinaryReader innerReader, DataObject& newObject)
at Microsoft.Office.InfoPath.Server.Serialization.EnhancedBinaryReader.ReadObjectMap[KeyT,ValueT](Dictionary`2 map, ItemReaderDelegate`1 readKey, ItemReaderDelegate`1 readValue)
at Microsoft.Office.InfoPath.Server.Serialization.EnhancedBinaryReader.ReadObjectMap[ValueT](Dictionary`2 map, ItemReaderDelegate`1 readValue)
at Microsoft.Office.InfoPath.Server.DocumentLifetime.DataObjects..ctor(EnhancedBinaryReader reader, Solution solution)
at Microsoft.Office.InfoPath.Server.DocumentLifetime.DocumentSessionState.DesterilizeVersion1(EnhancedBinaryReader reader, Solution solution)
at Microsoft.Office.InfoPath.Server.DocumentLifetime.DocumentSessionState..ctor(EnhancedBinaryReader reader, Solution solution)
at Microsoft.Office.InfoPath.Server.DocumentLifetime.DocumentSessionState.CreateFromByteArray(Byte[] serializedSessionState, Byte[] serializedVersionState, Solution solution)
at Microsoft.Office.InfoPath.Server.DocumentLifetime.DocumentSessionStateManager.GetSessionState(HttpContext context, String editingSessionID, Solution solution)
at Microsoft.Office.InfoPath.Server.DocumentLifetime.Document.LoadFromSession(HttpContext context, SPSite contextSite, EventLogStart eventLogStart, Solution solution)
at Microsoft.Office.InfoPath.Server.Controls.PostbackPage.<>c__DisplayClass1.b__0()

.NET Exceptions again

Debugging in Visual Studio sometime really gets you bugged with annoying error messages. I have listed here are a few of them:

1. A first chance exception of type 'System.Configuration.ConfigurationErrorsException' occurred in System.Configuration.dll. Additional information: This element is not currently associated with any context

2. A first chance exception of type 'System.InvalidOperationException' occurred in System.dll. Additional information: Instance names used for writing to custom counters must be 127 characters or less. 

3. A first chance exception of type 'System.IO.FileNotFoundException' occurred in mscorlib.dll . Additional information: Could not load file or assembly 'myProjectProxy.XmlSerializers, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified.

Scenario 1 and 3 is seems to be problem with the implementation of .NET libraries. In their normal processing they throw exception. It catches them and follow alternate execution path. In short developer (debugger :) )Don’t need to worry about it simply ignore them.

For number 2 lots of people has lot of thing to say. None of them so far solved my problem. I will update once I find a solution. As I said again this one also doesn’t stop my application from working. But still i tried to fix it. After googling I found somebody was saying adding following parameter in web/app config will fix the problem. 

<userDeploymentRoot
type=“System.String“>c:\temp</userDeploymentRoot>
<useDefaultDeploymentRoot
type=“System.Boolean“> False</useDefaultDeploymentRoot>

Well this didn't solve the problem yet. As I was saying these stuff are annoying but we gotta live with it.

Happy debugging :)

This element is not currently associated with any context

When debugging unit for a WCF client in Visual studio 2008 you often come across following error message. "A first chance exception of type 'System.Configuration.ConfigurationErrorsException' occurred in System.Configuration.dll

Additional information: This element is not currently associated with any context"

If the test is executed in non debug mode it works fine, without any glitches. This is because some of the exception which otherwise handled by WCF library is not handled in debug mode.Fix is simple. Open the Exception dialog box from Debug menu and deselect the Common Language Runtime Exception check box. Shown in red in following diagram. This simply tells Visual Studio not to break in system exception.

This happens because WCF throws and catches exception for it's normal application flow. Apparently there is no fix to it. See the post in MSDN(http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1025211&SiteID=1).