When I install Connect for Marketing Automation package v5.0.0 (https://nuget.episerver.com/package/?id=EPiServer.ConnectForMarketingAutomation&v=5.0.0) or the latest v5.0.1 (https://nuget.episerver.com/package/?id=EPiServer.ConnectForMarketingAutomation&v=5.0.1) I get this exception at runtime:
[ReflectionTypeLoadException: Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information.]
System.Reflection.RuntimeModule.GetTypes(RuntimeModule module) +0
Episerver.Marketing.Connector.Framework.Helpers.ReflectionHelper.GetInstances(IEnumerable`1 typeCollection) +133
Episerver.Marketing.Connector.Framework.MarketingConnectorInitialization.Initialize(InitializationEngine context) +73
EPiServer.Framework.Initialization.Internal.ModuleNode.Execute(Action a, String key) +58
EPiServer.Framework.Initialization.Internal.ModuleNode.Initialize(InitializationEngine context) +123
The intended connector I want to use is Connect for Marketing Automation Marketo latest version v4.0.0 (https://nuget.episerver.com/package/?id=EPiServer.MarketingAutomationIntegration.Marketo&v=4.0.0) but installing this still has the above exception.
(note: we are using EPiServer.CMS v11.9.4)
I've tried deleting the temporary ASP.NET files but it didn't help.
Any ideas or advice to resolve this?
Okay, so on our dev machines this issue always happens for a while on first build/restart but sometimes I can get it to work with a bit of tedious retrying with the debugger attached – I’m wondering if this is a timing issue (e.g. maybe the assemblies aren’t ready by reflection yet)?
We are also encountering this with the Marketo connector, same versions as you, we raised a ticket with support, there are other customers seeing this
Thanks Benjamin, glad to know I'm not alone!
I had also raised a support ticket, and application support have confirmed they've reproduced the error and have created a bug to be fixed.
Did they prodive an apprioximate fix release date?
Nope, nothing yet. All I had was initial confirmation of them reproducing the issue and creating a bug - but I'm not sure if it has progressed since, and they didn't give me any indication of a timeline.
Did you get any feedback from your ticket?
Yes, they confirmed a fix will be ready on Monday, lets see how it goes
We tried the updated ConnectForMarketingAutomation v5.0.2 (and with MarketingAutomationIntegration.Marketo v4.0.1) but resulted in the same error still..
Did you have any luck with new packages?
I've since heard from support that a new v5.1 will be coming out shortly with the intended fix.
So ConnectForMarketingAutomation v5.1 fixed the issue above but we then had a different issue where the Marketo credentials wouldn't correctly save with an error like this:
[KeyNotFoundException: The given key was not present in the dictionary.]
System.Collections.Generic.Dictionary`2.get_Item(TKey key) +52
Episerver.Marketing.Connector.Marketo.Views.Admin.Settings.OnPreRender(EventArgs e) +871
System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) +6875
This error would remaing any time trying to visit the admin page for Marketo. The only way I could remove the error was to go into the database and delete the entries from the DDS directly.
Episerver Support took our codebase and reproduced the issue and this is what they found:
We duplicated and found the issue. The project is changing the global default Json formatting resolver to be CamelCasePropertyNamesContractResolver.
This in turn causes the serialization of configuration data in our configuration dictionaries to have camel case format which in turn causes the error. This also explains why we are not seeing it in alloy or quicksilver. Note that this may also cause problems with other frameworks besides our own and it’s not recommended if it can be avoided. I did a quick google search and there are some great examples of how to use that resolver without changing the global default.
We will be putting a fix in the MAI framework to ensure that we serialize/de-serialize in an expected format so that we are not exposed to this in the future.
So it turns out I just had to remove this code from our global.asax.cs:
JsonConvert.DefaultSettings = () => new JsonSerializerSettings
ContractResolver = new CamelCasePropertyNamesContractResolver(),
StringEscapeHandling = StringEscapeHandling.EscapeHtml
With this removed, the issue went away. And for our application the above setting was unnecessary (we had it out of desperation when Web API wasn't staying with camelCase serialization - which was a different issue).
Sounds like the above will be fixed in a future version anyway - but this might be helpful for anyone with the issue in the mean time.