So I've gotten this error message from time to time since working with MS CRM.
System.IO.FileNotFoundException: Microsoft Dynamics CRM has
experienced an error. Reference number for administrators or support: #C0916659
Since there are multiple places for DLLs to live it makes it a pain to maintain.
Here's what I know of so far.
CRM SERVER
c:\Program Files\Microsoft Dynamics CRM\Server\bin - ?
c:\Program Files\Microsoft Dynamics CRM\Server\bin\Assembly - Plugins
c:\Program Files\Microsoft Dynamics CRM\Server\CRMWeb\bin - Supporting DLLs for plugins
ASYNC SERVER
c:\Program Files\Microsoft Dynamics CRM\Server\bin\Assembly - Async workflows and plugins
What else am I missing or need to be corrected on how these paths work and their intended purpose.
Best practice is to register the assemblies to the database.
Plug-ins not-registered in the sandbox can be stored in the Microsoft
Dynamics CRM server's database or the on-disk file system. We strongly
recommend that you store your production-ready plug-ins in the
Microsoft Dynamics CRM database, instead of on-disk. Plug-ins stored
in the database are automatically distributed across multiple
Microsoft Dynamics CRM servers in a data center cluster. On-disk
storage of plug-ins is useful for debugging plug-ins using Microsoft
Visual Studio but is mostly provided for backward compatibility with
callouts. You can debug a plug-in that is stored in the database.
Plug-ins registered in the sandbox must be stored in the database
regardless of the Microsoft Dynamics CRM deployment (on-premises,
IFD/SPLA, or Online).
This excerpt from the MSDN describes the registration possibilities and the paths.
For on-premises or Internet-facing Microsoft Dynamics CRM
installations, when you deploy plug-ins from another computer to the
Microsoft Dynamics CRM server disk (on-disk deployment), the plug-in
assembly must be manually copied to the server before registration.
The assembly must be deployed to the \Program
Files\Microsoft CRM\server\bin\assembly folder on each server where
the plug-in is to execute.
Plug-in registration should be done after the assembly has been copied
to the …\bin\assembly folder on the server to prevent the situation
where a system user causes an event in Microsoft Dynamics CRM to be
raised but the registered plug-in assembly does not yet exist on the
server. For server database deployment, the plug-in assembly is
automatically copied during plug-in registration so that the earlier
situation is not an issue.
Depending on your plug-in’s design, your plug-ins may require other
referenced assemblies to run. Regardless of whether you deploy your
plug-in to the database or disk, if your plug-in requires other
assemblies to run, you must put copies of these assemblies in the
Global Assembly Cache (GAC) on each server where the plug-in is to
execute. This does not apply to a Microsoft Dynamics CRM Online server
because you do not have access to the GAC on that server.
See Register and Deploy Plug-ins
Related
When deploying plugins using the Visual Studio Microsoft Dynamics 365 Developer Toolkit, we have been plagued with duplicate steps being created.
If we find a duplicate step has been created, we delete the plugin from the server and then redeploy the plugin from Visual Studio using the right click, deploy method.
The RegisterFile.crmregister is under source control so the guids should be maintained whichever member of our small team deploys.
Why are the duplicate plugin steps being created and how can it be prevented in a team situation?
When I tried Visual Studio Enterprise 2015 to do load tests, it automatically connects to some website and asks for a team service account.
I don't have one and my environment does not have an Internet connection.
Can I do load tests without such an account?
Every month or so Visual Studio 2015 Enterprise requires the user to validate their license. That is quickly done via some network activity. The trial version of the software is just an unlicensed version that has some restrictions on the type of load tests that can be done.
Assuming that the license has been validated and that, I believe, does require a suitable account to have been connected: The default settings for load tests are to use Visual Studio Team Services (VSTS - previously called VSO for Visual Studio Online). Use of VSTS does require a suitable account.
You should be able to run a load test locally on your computer. The setting for local versus VSTS execution of a load test is in the "General" section of the .testsettings file.
I'm struggling to find location of SharePoint components installed on server.
In my case I'm interested in SharePoint List component for MS Dynamics CRM. The URL clearly says it should be following file and folder .../crmgrid/crmgridpage.aspx..., but on server there is no such items.
Where SharePoint components is hidden?
I would appreciate any clue! Thank you in advance!
Static SharePoint pages are stored in the Layouts folder in the SharePoint hive, typically Program Files\Common files\Microsoft Shared\Web Server Extensions\14 for SharePoint 2010.
Any customized pages are not stored on the web server, but rather in the underlying SQL content databases. If the web pages are represented as files contained within document libraries in SharePoint, you can access them via the UNC path to the libraries (such as \\site.com\site\subsite\library\myfile.aspx).
They can also be accessed via SharePoint's REST API and SharePoint's more traditional web services.
Note: you are not permitted to query the underlying SharePoint database directly or your environment will cease to be supported (and the underlying database has a really bizarre schema anyway).
We are working to migrate to Azure Cloud Services (not Web Site) for our ASP.net Web Application. We are wanting to start using the Team Foundation Service with 'Continuous Integration' publishing like we currently use between AppHarbor and GitHub.
We are running into challenges when using TFS's 'Continuous Integration' feature. The builds are inconsistent when comparing Visual Studio to Azure Cloud Service to TFS to Azure Cloud Service. When we publish to Azure Cloud Service using the TFS's 'Continuous Integration', our static pages work fine but for the pages that have an *.cs extension are not able to find the controls we have placed on those pages. However, when we publish using Visual Studio 2010 to Azure Cloud Service, these pages operate correctly.
Can you offer any insight to why Team Foundation Service's Continuous Integration to Azure Cloud Service would result in pages with an *.cs extension not being able to find the controls we have placed on those pages while a build and deployment using the same exact code from Visual Studio 2010 to Azure Cloud Service works perfect?
Make sure all the referred assemblies that include the custom controls are "NOT" referred from GAC. Ideally put those in a folder (call it libs or references etc to easily identify). Then refer the assemblies from that location in your project, also don't forget to mark them Copy Local = True.
Anything that is not part of the framework should be included like this.
Our app added functionality to allow users to import certain information from an excel spreadsheet (all users will have Office 2007 already).
The development machine has Office 2007 and the developer added a reference to Microsoft.Office.Interop.Excel - all was good.
However, the build machine does not have Office 2007 installed. When the build is run on the build machine, we get the following build error: "The type or namespace name 'Office' does not exist in the namespace 'Microsoft' (are you missing an assembly reference?)"
I did download the Office 2007 Primary Interop Assemblies redistributable. But when I run that msi on the build machine, I get a messagebox saying "Please Install Microsoft Office 2007 before installing this product"
Is it really necessary to install Office 2007 on the build machine? Is there some other way around this?
Make sure the Microsoft.Office.Interop.Excel assembly is checked-in with the source code and the VS project is referencing it from the source tree and not from GAC.
After that is done, surely you do not need MS Office to be installed on the build machine, but you would need it for the application to run.
Just ask your devs to check all dll dependencies. This is a clear case of "it works on my machine" where you need to drag the devs to the machine where it is not working and point out that their documentation is lacking in the "dependencies department". If you have access to the source code or can run ILSpy on the assemblies you can propably track this down yourselve.
Safe bet is that yo just install Excel, but this is hitting the problem with a sledge hammer. Your devs SHOULD know what is really needed.....
Yes, you must have Excel installed on all machines you want to run your app on.