Sometimes when installing, it can be necessary to allow the installation to take place despite the fact that some of the system checks that are conducted during the installation fail. There are some different places mentioning how to do this, it is actually rather simple, you just have to add the DWORD key IgnoreChecks with a value of "1" to the MSCRM key in the registry [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSCRM].
Gustaf Westerlund
CEO, Chief Architect and co-Founder at CRM-konsulterna AB
www.crmkonsulterna.se
Thursday, May 12, 2011
Problems when connecting PluginRegistration Tool to CRM
I was going to deploy some plugins to a server today and when I tried to connect to the CRM with the PlugingRegistration.exe I found got the following error:
Unhandled Exception: System.ServiceModel.FaultException: The server was unable to process the request due to an internal error.
So I switched on the tracing in CRM and read the following from the trace log (edited):
System.IO.FileNotFoundException, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
Could not load file or assembly 'Microsoft.Xrm.Client, Version=5.0.2.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The system cannot find the file specified.
The error seems to originate from CRM not being able to find the Microsoft.Xrm.Client.dll file. After some fiddeling, I fixed it by copying the file from the SDK\bin directory to CRMWeb\bin directory. It is a bit strange that it is required that you do this, and it will probably be fixed in future rollups of CRM 2011.
By the way, I heard some rumors from the CRM Statement of Direction that CRM 6 will be released Q2 2012 and that it will have multibrowser support. The feature we have all been waiting for, and it is probably going to be more or less the same thing as the 2011 version but with multibrowser support. So Software Assurance will probably be a good idea this year for Microsoft Dynamics CRM.
Gustaf Westerlund
CEO, Chief Architect and co-Founder at CRM-konsulterna AB
www.crmkonsulterna.se
Unhandled Exception: System.ServiceModel.FaultException: The server was unable to process the request due to an internal error.
So I switched on the tracing in CRM and read the following from the trace log (edited):
System.IO.FileNotFoundException, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
Could not load file or assembly 'Microsoft.Xrm.Client, Version=5.0.2.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The system cannot find the file specified.
The error seems to originate from CRM not being able to find the Microsoft.Xrm.Client.dll file. After some fiddeling, I fixed it by copying the file from the SDK\bin directory to CRMWeb\bin directory. It is a bit strange that it is required that you do this, and it will probably be fixed in future rollups of CRM 2011.
By the way, I heard some rumors from the CRM Statement of Direction that CRM 6 will be released Q2 2012 and that it will have multibrowser support. The feature we have all been waiting for, and it is probably going to be more or less the same thing as the 2011 version but with multibrowser support. So Software Assurance will probably be a good idea this year for Microsoft Dynamics CRM.
Gustaf Westerlund
CEO, Chief Architect and co-Founder at CRM-konsulterna AB
www.crmkonsulterna.se
Tuesday, May 10, 2011
New design and name
Since I live by the principle that you should focus on what you are good at and leave the rest to others, I must admit that my SharePoint experience is degrading due to the fact that I havn't worked with it for several years. This can also be seen in the postings that I have done on the blog, where almost 100% of the posting during the last years have regarded Dynamics CRM.
The natural conclusion of this is that this blog should also focus, hence I have renamed it to Gustaf's Microsoft Dynamics CRM Blog omitting the previous SharePoint part.
I also revised the layout of the blog, to freshen things up a bit.
Gustaf Westerlund
CEO, Chief Architect and co-Founder at CRM-konsulterna AB
www.crmkonsulterna.se
The natural conclusion of this is that this blog should also focus, hence I have renamed it to Gustaf's Microsoft Dynamics CRM Blog omitting the previous SharePoint part.
I also revised the layout of the blog, to freshen things up a bit.
Gustaf Westerlund
CEO, Chief Architect and co-Founder at CRM-konsulterna AB
www.crmkonsulterna.se
Friday, May 06, 2011
Debugging sandboxed plugins
Microsoft Dynamics CRM 2011 includes a feature to allow sandboxing of plugins. This means that the program execution is fenced off from the rest of the server to avoid any buggs or exploit attempts in the plugins to affect the rest of the server. This is most useful in the CRM Online and partner hosted deployments but can also be used in normal on-premise solutions to fence off some risky code.
When developing plugins, I strongly recommend a local CRM installation, even if the deployment of the plugin is going to be on CRM Online. It is not possible to step-debug programs on CRM online for natural reasons, and the shotgun-debugging approach that is available from the CRM Plugin SDK is quite rough and does increase development time.
Normally when step-debugging plugins, you would attach to the w3wp process for the CRM app-pool.
However, you do have to remember that plugins that are registered to be run in the sandbox, actually are executed under a different process hence you cannot attach to the w3wp process when debugging but instead have to attach to the Sandbox process.
If you would like, it is also possible to register the plugin outside the sandbox first while developing and the re-register it in the sandbox later. Some errors might, however, only show when working with sandboxed plugins so it is also good to be able to debug these.
Do note that it I have installed the sandbox to use Network Servce as the executing account, this is not recommended for production deployments, since that will nullify some of the security features of the sandbox. Instead a dedicated minimum security account should be used to block the process from accessing anything outside the sandbox.
Gustaf Westerlund
CEO, Chief Architect and co-Founder at CRM-konsulterna AB
www.crmkonsulterna.se
When developing plugins, I strongly recommend a local CRM installation, even if the deployment of the plugin is going to be on CRM Online. It is not possible to step-debug programs on CRM online for natural reasons, and the shotgun-debugging approach that is available from the CRM Plugin SDK is quite rough and does increase development time.
Normally when step-debugging plugins, you would attach to the w3wp process for the CRM app-pool.
However, you do have to remember that plugins that are registered to be run in the sandbox, actually are executed under a different process hence you cannot attach to the w3wp process when debugging but instead have to attach to the Sandbox process.
If you would like, it is also possible to register the plugin outside the sandbox first while developing and the re-register it in the sandbox later. Some errors might, however, only show when working with sandboxed plugins so it is also good to be able to debug these.
Do note that it I have installed the sandbox to use Network Servce as the executing account, this is not recommended for production deployments, since that will nullify some of the security features of the sandbox. Instead a dedicated minimum security account should be used to block the process from accessing anything outside the sandbox.
Gustaf Westerlund
CEO, Chief Architect and co-Founder at CRM-konsulterna AB
www.crmkonsulterna.se
Subscribe to:
Posts (Atom)