How To Register A Plugin In Crm 2015

I was asked this question today

Do I need to restart IIS (Internet Information Services) afterwards I accept deployed my plugin?

My initial quick answer was no merely then I was curious why they asked me the question? This is what I refer to as a suspicious question. Often the question people ask, isn't the existent question they want to ask, a bit like when my 3 year old daughter asks.

"What's that chocolate bar doing on the tabular array Daddy?"

The real question

"Daddy I want to open up and eat that delicious looking chocolate bar"

This picture isn't my kid but it's a fits the text in a higher place

Plugin storage options

There are 3 plugin storage options

Database
Deejay
GAC

deployment options

The options are adequately self explanatory. (plugin.dll is your custom plugin assm)

Database = Plugin.dll uploaded into the database
Deejay = The Plugin.dll is saved on the CRM Servers difficult deejay
GAC = The plugin.dll is loaded into the GAC on the CRM Server.

If yous don't know what the GAC is it's the Global Assembly Cache. It'due south a common expanse on a computer to store the DLL'southward which is C:\Windows\assembly. This discussion has a expert definition – What is the GAC in .Cyberspace

As always Start with the SDK, which has a good commodity on the field of study

Default Option

The default option should be store your plugin on the database and to be honest I tin't recollect of any reason why you would shop you plugin not in the database. Microsoft STRONGLY agrees with me (excellent, I like it when Microsoft does that)

Nosotros strongly recommend that you store your production-prepare plug-ins in the Microsoft Dynamics CRM database, instead of on-disk.

The advantages of deploying your plugin to the database our

The plugin is backed up when the database is backed upward
For multiple server configurations y'all only need to deploy once to the database and non individually to each CRM server.
Plugins in the database can be added to solutions, Disk, GAC plugins cannot
Plugins deployed to the GAC or Disk volition need an IISRESET to refresh, plugins deployed in the database exercise not.
Sandboxed and CRM Online plugins have to be deployed in the database

If you want to understand what deploying to the Sandbox is read my blog postal service Understanding Plugin sandbox mode

I take experienced a CRM deployment where common code used by the plugins was held in a divide DLL which was stored in the GAC of the CRM servers. The preproduction environment had 8 CRM Servers and the Production environs had 11 CRM servers. It was a tedious job to install the DLL on every server, restart the ISS server and CRM async services.

I cannot remember of whatever advantages to installing CRM plugins on the server or in the GAC and so my advice is never to exercise it.

Some people might recall y'all need to install the plugin.dll on the CRM server to enable remote debugging only this isn't truthful, you lot tin can install the plugin.dll in the database and put the pbd file in the the binder C:\Programme Files\Microsoft Dynamics CRM\Server\bin\assembly. Microsoft gives you this tip on the Debug a plugin page

It is possible to debug a database deployed plug-in. The compiled plug-in associates's symbol file (.pdb) must be copied to the server's <crm-root>\Server\bin\assembly folder and Internet Information Services (IIS) must so be restarted. After debugging has been completed, y'all must remove the symbol file and reset IIS to foreclose the process that was executing the plug-in from consuming additional memory.

Personally I prefer to use the plugin registration tool to debug plugins because this can exist done a CRM Developers individual machine. When people remote debug on the CRM server this can sometimes deadening, finish the CRM Async services from running and processing other plugins.

Basically information technology's non expert CRM developer etiquette to terminate other developers using the system because you lot need to debug a plugin (although sometimes need must).

A better arrangement is to write unit tests to exam the logic of your code in isolation

Why CRM Developers should unit of measurement test their lawmaking
Experiences of Unit of measurement testing with Microsoft Dynamics CRM Projects
Information to Get started with Unit Testing with Microsoft Fakes and Microsoft Dynamics CRM 2013

CRM MVP Gonzalo Ruiz has written a great article on the benefits of registering your plugin to the CRM database.

half-dozen Great Reasons to Register your Plugins in Database Instead of Deejay/GAC

Betoken number 4 is interesting

iv. Disk assemblies will not support multiple versions

I never realised (or yet needed/wanted to use) y'all tin can store multiple versions of an assembly.

I constitute one small reason for deploying to deejay, highlight by this blog by David Jennaway, where he mentions if you plugins have dependant dll's you tin can put them in the same directory every bit the plugin, in a similar style the plugin registration tool has the CRM SDK dll'due south in the same directory simply this isn't much of a reason.

What tin can yous restart and how does it effect plugins

At that place are a few things which you can restart which tin can affect your CRM plugins. I will state plugins deployed to the CRM database practise not demand any of these restarted, which is some other practiced reason to deploy your plugins to the CRM database.

IIS Server
Recycle CRM App pool
Restart CRM Services

You exercise sometimes need to check the IIS Server or CRM services if your CRM isn't working, for more detail check out the article Microsoft Dynamics CRM non working? check these common causes

IIS Server

Lots of CRM developers I have met do an IIS Reset and Async CRM Services restart when ever they deploy a plugin, even when the plugin is deployed in the database and they didn't need to. The reason they did this was because the CRM programmer who helped them larn CRM did information technology, so now they exercise it.

First lets empathize what doing an IIS Reset does. When y'all type IISRESET into the cmd line or go to the IIS server and click restart. The first thing you should do is warn the users you are about to take down CRM and all other websites and spider web services hosted in IIS. The key point is information technology restarts everything on the IIS server and not just CRM, make sure you lot want to restart everything.

IISRESET restarts these services, it's the same as stopping and and so starting the 3 services below according to this mail

IIS Admin Service
Windows Process Activation
World Broad Web Publishing

This give-and-take has an splendid summary what IISReset does What does an IISReset do?

IISReset stops and restarts the entire spider web server (including non-ASP.Net apps)
Recycling an app pool will only affect applications running in that app puddle.
Editing the spider web.config in a web application only affects that web application (recycles simply that app).
Editing the machine.config on the machine will recycle all app pools running.

IIS will monitor the /bin directory of your application. Whenever a change is detected in those dlls, it will recycle the app and re-load those new dlls. It also monitors the web.config & motorcar.config in the same way and performs the aforementioned action for the applicative apps.

useful tip – If you are doing an IISReset via command line then it's a skilful to practise

IISReset /noforce

This will gracefully close down IIS rather than IISReset and wait for processes to finish. IISReset volition abruptly close down IIS which could go out processes half mode through updating the CRM database! which is something you want to avoid.

This discussion highlights an area where y'all need to recycle the app puddle

Practice we really need IIS Reset and Async Services restart when we depoly plug-in or custom workflow – CRM 2011

There is one other scenario where yous need to recycle the CrmAppPool application pool. If you modify the parameters that are available for a Custom Workflow Activity, and so CRM volition not make any new parameters available when editing the workflow until subsequently recycling the application pool.

Recycling the CRM app pool is a lot less disruptive than restarting the whole server.

I couldn't find whatever need to practice an IIS reset for database stored plugins, I call up you would need to recycle the app pools to if you your plugins are stored in the GAC or Deejay.

CRM Services

You have a number of choices when deploying plugins which furnishings what CRM process runs the plugin code. Here are the CRM services

CRM services

Isolation mode

Sandboxed
none

If you choose Sandboxed the plugin code will exist run in CRM Sandboxed Processing services, this service is sandboxed, if the plugin tries to modify or access external dll's, certain organization resources an error will be thrown.

if you choose none it gets run past the cadre CRM system in the event execution pipeline if information technology Synchronous, if it's asynchronous information technology gets run past the CRM async service

CRM Async services

I accept written earlier most CRM 2013 – Understanding SystemJobs and Async Plugins.

If you expect at the msdn article – Outcome execution pipeline, this motion-picture show shows you the various parts of CRM

Synchronus plugins runs straight abroad and the CRM form will hang until the plugin has successfully run. Looking at the architecture in a higher place you lot can run across synchronus plugins go run in by the core CRM system inside the database transaction.

Async Plugins become run subsequently the Plugin execution pipeline has finished and go into the Async Queue Managing director and get run when CRM has costless resources. Researching this topic today I constitute Microsoft has quite a big department on Asynchronous services in CRM, which I accept never read until today

Asynchronous service in Microsoft Dynamics CRM

This commodity Asynchronous service architecture is mentions this

The asynchronous service features a managed queue for the execution of asynchronous registered plug-ins, workflows, and operations such as majority post, bulk import, and campaign action propagation. These operations are registered with the asynchronous service and executed periodically when the service processes its queue. The asynchronous service tin can be hosted on a server other that the server running Microsoft Dynamics CRM.

The reason I mention the Async service is because there is a small piece of best practise I had not considered or heard before tucked in the

You should stop the asynchronous service earlier you unregister a plug-in that was registered to execute asynchronously. Stopping the service prevents a situation where an asynchronous registered plug-in has been queued for execution but for which there is no plug-in assembly currently registered. For example, consider the situation in which a plug-in has been registered to execute asynchronously and the related event has fired. After the asynchronous functioning has been queued by the queue director, you so unregister (delete) the plug-in assembly from the Microsoft Dynamics CRM database. In this case, an error occurs when the asynchronous service tries to execute the queued asynchronous operation just the plug-in assembly no longer exists.

So if you lot have Async plugins and so it'southward adept practise to restart the CRM Async service when yous unregistered an async plugin. This volition avoid a plugin being queued which has been unregistered.

Finally I volition leave you with the my mail service on common plugin errors and isolation mode

CRM 2011/2013 – Common Plugin Errors and Isolation Mode

Dorsum to the question

I forgot about the question. The reply is no the programmer won't have to do an IISReset if the plugins are deployed to the database, which they were.

Information technology's been interesting researching this topic and I have learnt a bit more than virtually the CRM architecture