Microsoft CRM

Using external assemblies with CRM 4.0 Plugins

Wes Weeks — Mon, 23 Feb 2009 21:39:19 GMT

When developing for CRM, we like to keep our business login contained within its own class to be shared and used by other parts of the system. Most all of our CRM implementations have other applications accessing CRM in one way or another so this approach works well. This was fairly straight forward wtih the 3.0 callout model, you just had to put them in the same directory with your custom callout (C:\Program Files\Microsoft CRM\Server\bin\assembly\ in most cases) .

The way around this is to either put your assemblies in the GAC, or drop the assemblies in the bin directory of the CRM Web application (which is the route we chose).

Another caveat is your assemblies MUST be signed. This was a bit of a pain to get working because we had a few unsigned third party assemblies and a signed assemblie can only reference other signed assemblies. Probably the biggest issue was the Plugin deployment tool registered the unsigned assemblies without any issue, and we were without any error messages explaining why our code wasn't running. In CRM 3.0 you could use unsigned assemblies by setting a config setting to 'allowUnsignedAssemblies' to true.

Hope these two pointers helps you out with your development...

Entity Typecode not found in Metadata Cache

Wes Weeks — Sun, 07 Sep 2008 12:12:14 GMT

While performing an update to some code originally written for CRM 3.0 which I was upgrading to 4.0 and using the new 2007 version of the web services, I found myself getting an unusual error during one of the callouts. The code created a new custom entity from the data in an existing entity. This code was orginally written by another party and I"m not sure why they didn't use the mapping features in CRM to do this but it was coded manually.

The entity with typecode '8' was not found in the Metadata Cache.

Never having seen this before it of course took a lot of time digging through the event viewer and trace logs to find the source of the error. In this case, it came down to one line:

newEntity.OwnerId = originalEntity.OwnerId

In a nutshell: the 'type' attribute on the originalEntity which had just been read out of CRM using the web services was '8', however when creating/setting the type on create the attribute field needs to be the name of the entity. In this case, since the owner was a system user, the type field needed to be set to 'systemuser'

One would think that the inbound and outbound values could be the same or possible set up to parse for both a type code of or the type name.....

Anyway, if someone else comes across this or a similar problem, I hope this helps.

Microsoft Dynamics 4.0 Installer Gripe

Wes Weeks — Fri, 29 Aug 2008 15:41:19 GMT

The CRM 4.0 installer has a nice new feature. The ability to get upgraded setup files prior to running the instalation. A nice step forward to hopefully address setup issues which are often present in the first release of the components.

Now for my Grip...

I've rarely been lucky enough to get it right the first time. Usually I have to run the installer, fix a few things, and repeat until succesful.

The problem is that their isn't any 'memory' of the upgraded setup files. If you have to run the installer a second time, you have to download the files again. The connection I had was slow enough that it took nearly 20 minutes to update the setup files the first time. When it came around to do it again, I wasn't patient enough to even consider going through that pain a second time and skipped the update. I'd prefer not to go with that approach ;)

So if anyone from the MS team gets this message somehow, keep the upgrade strategy but provide a way for the updates to e maintaned or downloaded as a seperate file. Will help us in he trenches out quite a bit.

CRM 3.0 to 4.0 upgrade error

Wes Weeks — Fri, 29 Aug 2008 04:10:21 GMT

While performing an upgrade from Microsoft Dynamics CRM 3.0 to 4.0, the upgrade installer halted early on with the following error message:

Microsoft.Crm.Setup.Server.ShutdownCrmServerAction failed

Turns out that at some point the IIS Admin service was shutdown and disabled. Not sure how this occured since I had been running CRM 3.0 just prior to the install.

So if you get unlucky enough to get this message, open up your services and Enable/Restart your IIS admin service. The setup continued without a hitch after that.

HeaderAuthenticationProvider doesn't exist

Wes Weeks — Fri, 25 Apr 2008 22:08:57 GMT

Another issue that may be faced when deploying custom .Net applications in the CRM root directory is the following error:

'Microsoft.Crm.WebServices.Crm2007.MultipleOrganizationSoapHeaderAuthenticationProvider,
Microsoft.Crm.WebServices, Version=4.0.0.0, Culture=neutral,
PublicKeyToken=31bf3856ad364e35' doesn't exist.

You can resolve this one of two ways...

1. Add the following to your applications web.config (not CRM's web.config!)

2. Go to the crm bin directory for IIS and either copy the Microsoft CRM.WebServices.dll to the GAC or to the bin directory of your custom ASP.Net application

How to deploy your own ASP.NET application within the same site as Dynamics CRM 4.0

Wes Weeks — Fri, 25 Apr 2008 22:06:54 GMT

Working for a client on an upgrade for 3.0 to 4.0 with an application that was in place under the CRM IIS directory as a virtual directory. Struggled trying to get this to work and respond as it did under 3.0.

Basically, the site would work if it was it's own web site, but not as a virtual directory. To make matters worse, the only thing returned when you navigated to the site was a blank page. None of my code was executing and I wasn't getting any type of error message. Tried messing with every IIS 7.0 setting that seemed to make sense and even a few that didn't

Didn't know what or who to blame. CRM 4.0? Windows Server 2008? My brother-in-law? (because he owes me money and I blame him anyway)

The issue is that you cannot access to your custom application from IE because CRM 4.0 is running a .NET HttpModule and that .NET HttpModule is re-writing the URL depending of the organization (default organization normally.). This is a normal execution because of the multi-tenancy capability of CRM 4.0 and that is why you are not able to execute the ASP.NET pages from IE. IE is not finding that changed URL.

In fact, that HttpModule is declared within CRM web.config as the following:

So, if you want to deploy and run your custom ASP.NET application within the same IIS WebSite where CRM is running, what you gotta do is to specify within your custom app’s web.config that you want to get rid of that kind of filter (HttpModule). Please, note that I am talking about changing your own custom app's web.config. Do not touch CRM 4.0 Web.config, ok

So, if you go to your custom ASP.NET application folder and then you open your own Web.config, if you add the following directives, your clean that CRM filter, so you’ll be able to run your custom app from IE.

This is what you have to add to your own web.con file:

<system.web>
<httpModules>
<clear/>
</httpModules>

Problem solved. Still blaming the brother-in-law though....