Plugin issue after onprem upgrade from v8.2 to v9.0

(0) Share

Report

Posted on by Bram Colpaert

Hi,

We are in the process of upgrading an onpremise farm of +-20 organisations from v8 to v9.
While testing the post-upgrade environments, we have the following error when executing plugins (on update eg.) on some organisations (not all of them):

The communication object, System.ServiceModel.Channels.ServiceChannel, cannot be used for communication because it is in the Faulted state.

Server stack trace: at System.ServiceModel.Channels.CommunicationObject.ThrowIfDisposedOrImmutable() at System.ServiceModel.Channels.CommunicationObject.Open(TimeSpan timeout)....

I've already googled this issue and the suggested "solutions" of rebuilding the plugin assembly with v9 sdk dlls didn't work.

However, I managed to get the plugins working again, by creating a new Visual Studio solution and copy/paste the code into the new project. I've registered the new assembly and moved the existing sdk message processing steps to this new assembly and all plugins worked again. I couldn't see any difference between the two solutions (same .net, same references, same signing key, ... except for a different assembly guid).

The thing is we have a lot of managed solutions on which we have the same issue and I can't create a new visual studio project for these...

Any suggestions on how to fix this?

BR,

Bram

I have the same question (0)

All responses (9)

Answers (1)

Community Member on at

Like (0)

Report

Hi Bram,

I know this is trivial and mostly you tried it, have you unregistered the faulty plugin and registered it again? It is always a safe bit to rebuild the plugins in the new SDK just in in case something changed in the new SDK.

Omar

Was this reply helpful? Yes No
Community Member on at

Like (0)

Report

Also, you can profile this plugin using the plugin profiler. You say the issue happens when the plugin triggers on update for example, try to debug the plugin and see where does break exactly.

Was this reply helpful? Yes No
thonda on at

Like (0)

Report

Pull the assembly manifest using ildasm and see if there are any differences except for versions of referenced assemblies. You may want to open a case with Microsoft support.

Was this reply helpful? Yes No
Bram Colpaert 15 on at

Like (0)

Report

[quote user="OmarZ"]
Hi Bram,

I know this is trivial and mostly you tried it, have you unregistered the faulty plugin and registered it again? It is always a safe bit to rebuild the plugins in the new SDK just in in case something changed in the new SDK.

Omar
[/quote]
Tried this, but didn't work

Was this reply helpful? Yes No
Bram Colpaert 15 on at

Like (0)

Report

[quote user="thonda"]
Pull the assembly manifest using ildasm and see if there are any differences except for versions of referenced assemblies. You may want to open a case with Microsoft support.
[/quote]
I couldn't see any major differences when using ildasm (except for some guids). I suspect it to be something in the crm db that is wrongly referenced somehow...

Was this reply helpful? Yes No
Bram Colpaert 15 on at

Like (0)

Report

[quote user="OmarZ"]
Also, you can profile this plugin using the plugin profiler. You say the issue happens when the plugin triggers on update for example, try to debug the plugin and see where does break exactly.
[/quote]
I tried debuging it via the plugin profiler, but there is nog log file generated. I can't select a profile from crm:

It looks like the plugin itself can't be loaded at all...

Was this reply helpful? Yes No
Bram Colpaert 15 on at

Like (0)

Report

Some extra information: we have two upgraded environments: A and B. On both environments we have exactly the same managed solution. However, environment A does not have the issue described, environment B has the issue.

Via the assembly recover tool I downloaded the assembly from A and registered the assembly in B (I tried updating the existing assembly and creating a new assembly). B still throws the error.

So it looks like there is no problem with the assembly itself, but there is an issue somewhere in the organisation itself...

Was this reply helpful? Yes No
Verified answer

Bram Colpaert 15 on at

Like (2)

Report

The issue is resolved:

The sandbox service was not working properly because of missing SPNs.

Was this reply helpful? Yes No
Carl_hanna 10 on at

Like (0)

Report

Hello Bram,

Could you please tell me how you solved the issue. We have similar issue.

Thanks

Was this reply helpful? Yes No