NullReferenceException from AMO - Connect

Server svr = new Server();

svr.Connect(Properties.Settings.Default.OLAPConnectionString);

(Server is of type Microsoft.AnalysisServices.Server)

Results in:

NullReferenceException: Object reference not set to an instance of an object.

at Microsoft.AnalysisServices.DesignXmlReader.CheckForXmlaException()

at Microsoft.AnalysisServices.DesignXmlReader.ReadRoot(Type type)

at Microsoft.AnalysisServices.DesignXmlReader.DeserializeComponent(IDesignerSerializationManager manager, XmlReader reader, Type root)

at Microsoft.AnalysisServices.JaXmlSerializer.DeserializeComponent(IDesignerSerializationManager manager, XmlReader reader, Type root)

at Microsoft.AnalysisServices.AnalysisServicesClient.Discover(IMajorObject obj, ObjectExpansion expansion)

at Microsoft.AnalysisServices.Server.Refresh(IMajorObject obj, ObjectExpansion expansion)

at Microsoft.AnalysisServices.Server.SendRefresh(IMajorObject obj, ObjectExpansion expansion)

at Microsoft.AnalysisServices.MajorObject.Refresh()

at Microsoft.AnalysisServices.Server.Connect(String connectionString, String sessionId)

at Microsoft.AnalysisServices.Server.Connect(String connectionString)

at ... my code, the call to Connect, above

The connection string is non-null, and names a valid, running SSAS database on the local machine. Any theories? This code has been working fine up till now, and nothing's changed in the cube or the enclosing database in weeks. The only thing of interest that changed recently was a batch of updates from Windows Update - but that seems very unlikely since none of them were SSAS related.

... and, wouldn't you know it, next time through, the code worked fine. The process hasn't even been re-started. I hate bugs that "fix" themselves!

This is typically a result of late bindings. Not necessarily a bug, just a runtime risk.

Adamus

|||Actually, I think the problem was simply that I had VS set to stop on exception throw, instead of stop on unhandled. Second time through, I'd changed the settings. Presumably this exception was thrown, caught and handled inside of AMO and is nothing to worry about.