7. august 2007 12:11
I'm new to callouts and I seem to be having a problem. Can someone point me in the right direction?
I've put this callout.config.xml in the \\<server>\e$\Program Files\Microsoft CRM\Server\bin\assembly folder
<callout.config version="3.0" xmlns="http://schemas.microsoft.com/crm/2006/callout/">
<callout entity="task" event="PostSetState">
<subscription assembly="OrderItemHours_SendEmailAlerts.dll" class="OrderItemHours_SendEmailAlerts.OrderItemHours_SendEmailAlerts">
In the same folder I put my OrderItemHours_SendEmailAlerts.dll which contains
Public Overloads Sub PostSetState(ByVal userContext As CalloutUserContext, ByVal entityContext As CalloutEntityContext, ByVal preImageEntityXml As String, ByVal postImageEntityXml As String)
The method doesn't do much other than write to the EventLog and then send a mailmessage. I want it to fire when a task is completed but for now I'm just try to see that I can properly communicate between CRM and my callout. Can anyone see where I am going wrong? Is there some sort of switch that enables/disables callouts? After I put those files in the above directory I restarted IIS with an iisrestart and still nothing. I can move the file out of the directory so I'm pretty sure it's not referencing it. Does the file have to be named like MyCallouts as most examples show? If anyone can provide some insight or at least guide me in a way of debugging the issue I would greatly appreciate it.
EDIT: I'd like to add some other things that have popped into my head about what could be up. I reference the Callout.Base.dll in my project but it's a direct reference and not a web reference. In the project it shows a C:\<path>\<filename> string as the source, so I was wondering if this needs to somehow be pointing to the web server. I read that I didn't need to put that assembly in the \assembly\ folder because it is already in the GAC but my GAC directory only contains Microsoft.Crm.Platform.Callout.Manager.dll and no Callout.Base.dll.
8. august 2007 02:10
I found out I am getting the following eventlog error:
Event Type: Error
Event Source: MSCRMCallout
Event Category: None
Event ID: 16912
Time: 10:06:41 PM
Error: ISV code threw exception: assembly: OrderItemHours_SendEmailAlerts.dll; class: OrderItemHours_SendEmailAlerts.OrderItemHours_SendEmailAlerts; entity: task, event: postsetstate, exception: System.TypeLoadException: Could not load type OrderItemHours_SendEmailAlerts.OrderItemHours_SendEmailAlerts from assembly OrderItemHours_SendEmailAlerts, Version=1.0.2775.34499, Culture=neutral, PublicKeyToken=null.
at System.Reflection.Assembly.GetTypeInternal(String typeName, Boolean throwOnError, Boolean ignoreCase, Boolean publicOnly)
at System.Activator.CreateInstanceFrom(String assemblyFile, String typeName, Boolean ignoreCase, BindingFlags bindingAttr, Binder binder, Object args, CultureInfo culture, Object activationAttributes, Evidence securityInfo)
at Microsoft.Crm.Callout.CalloutHost.PostSetState(CalloutUserContext userContext, CalloutEntityContext entityContext)
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
8. august 2007 03:13
I've hacked my source file apart just trying to get the communication working without erroring... here is the current state and it's still not working:
PublicClass OrderItemHours_SendEmailAlerts Inherits CrmCalloutBase
Public Sub New()
ByValuserContext As CalloutUserContext, ByVal entityContext As CalloutEntityContext, ByVal preImageEntityXml As String, ByVal postImageEntityXml As String )
Here is the callout.config.xml
<callout.config version="1.0" xmlns="http://schemas.microsoft.com/crm/2006/callout/">
<callout entity="task" event="PostSetState">
<subscription assembly="OrderItemHours_SendEmailAlerts.dll" class="OrderItemHours_SendEmailAlerts" />
I have web references to the CrmMetadataService and the CrmSdk as per any example you see in the sdk. Also I added a local reference to the Callout.Base.dll that is copied to the local bin folder. I am still getting the error mentioned above that says that it could not load the type. I've done my best to remove any extra code that may not be necessary but I am still getting the issue. I know it is reading the config because of the error (it shows the class name) and also the dll because it's locking the files sometimes. I stop IIS to copy up the file, then restart IIS and the workflow service. I've run out of ideas, can anyone contribute anything to my madness?
9. august 2007 08:03Redaktør
One possible cause is any .Net namespaces. The class= attribute in callout.config.xml must include all .Net namespaces, and is case sensitive. I find the easiest place to check this is in the Object browser in Visual Studio .Net
Another possible cause is if the assembly is not using .Net framework 1.1. Callout have to use .Net 1.1
9. august 2007 13:46
Hmm. I tried adding a namespace to the source but that didn't seem to make any difference. I made sure to add it in the source and then made the callout.config.xml reflect the exact namespace ( I did a copy and paste ). I also checked my references and all are using the 1.1 runtime. I'm building my project in VS.NET 2003 as well so the project should be completely in 1.1.
This Type error that I mentioned above seems awfully vague. Is there a better way of getting some error tracing to show?
9. august 2007 14:58Redaktør
For further debugging try enabling CRM tracing - http://support.microsoft.com/kb/907490
As to the Callout.Base dll, you need Microsoft.Crm.Platform.Callout.Base.dll in the GAC on the CRM server, and you shouldn't have it in the bin\assembly folder
12. august 2007 22:51I still don't know what the problem was, but I decided at 3 am to rewrite the code in c# instead of VB and redeploy it. Worked the first time. I've also written a batch script now for deploying that resets IIS, stops the workflow service, copies the dll, resets IIS again and then restarts the service. It's probably a little overkill, but so far it's working so I'm not going to complain. Thanks for all the help - I have successfully enabled tracing which I had been wondering about as well.