Skip to main content

Dynamics 365 v9 Unit Testing and .NET Confusion

Recently while creating a plugin for Dynamics 365 v9, I ran into an issue trying to connect to CRM via the tooling connector in my unit test project.  The underlying problem was that the .NET version I was using in my unit test was 4.5.2.  This was preventing me from being able to connect to CRM to create my organization service.  I updated the .NET version on my unit test project to 4.6.1 and was then finally able to connect.  I will also add that I am using the latest nuget package version for Dynamics 365 v9.

For consistence, I updated the plugin project I was working on to .NET 4.6.1.  Locally, everything was working great.  I was able to connect to CRM and make sure that all the methods I had written did what they where suppose to do using test driven development practices.

Then when publishing my plugin via the latest version of the plugin registration tool, I received an error and could not publish my plugin.  The error was due to the .NET version of my plugin project not being 4.5.2.  REALLY!!!!  I just had connection issues and needed to upgrade the .NET version to 4.6.1 to resolve them.  Now I am being told to downgrade my .NET version to upload the plugins to Dynamics 365 v9.

While researching this, I came across this thread in the Microsoft forums, where people are seeing the same issue and are confused as to what is happening.  Basically, CRM plugins need to use .NET 4.5.2 but the XRM tooling connector uses .NET 4.6.1.  We need to tooling connector in our unit tests, because we are connecting to CRM via an external source to create the organization service context for us.  This means that our unit test project needs to be built on .NET 4.6.1 and out plugin project needs to be built on .NET 4.5.2.  Don't worry, the nuget packages you need for both can work with both .NET versions without any problem and you will be able to connect to CRM from your unit test project and call methods from the plugin project to test your code.  You will then be able to publish your plugins to CRM and not receive a .NET error message in the plugin registration tool.
Labels:

Comments

Post a Comment

Popular posts from this blog

Validating User Input In CRM Portals With JavaScript

When we are setting up CRM Portals to allow customers to update their information, open cases, fill out an applications, etc. We want to make sure that we are validating their input before it is committed to CRM.  This way we ensure that our data is clean and meaningful to us and the customer. CRM Portals already has a lot validation checks built into it. But, on occasion we need to add our own.  To do this we will use JavaScript to run the validation and also to output a message to the user to tell them there is an issue they need to fix. Before we can do any JavaScript, we need to check and see if we are using JavaScript on an Entity Form or Web Page.  This is because the JavaScript, while similar, will be different.  First, we will go over the JavaScript for Entity Forms.  Then, we will go over the JavaScript for Web Pages.  Finally, we will look at the notification JavaScript. Entity Form: if (window.jQuery) { (function ($) { if ...
22 comments
Read more

Reusable Method To Get Record By Id

I have a handful of reusable code that I use when creating plugins or external process (i.e. Azure Functions) for working with DataVerse. The first one I am providing is Getting a Record By Id: 1: private static Entity GetFullRecord(string entityName, string primaryKey, Guid recordId, IOrganizationService service) 2: { 3: using (OrganizationServiceContext context = new OrganizationServiceContext(service)) 4: { 5: return (from e in context.CreateQuery(entityName) 6: where (Guid)e[primaryKey] == recordId 7: select e).Single(); 8: } 9: } entityName = The logical name of the entity primaryKey = The primary key field for the entity. If using late binding you can create this dynamically by doing: $"{target.LogicalName}id" recordId = Guid of the record to get service = Service to interact with DataVerse
4 comments
Read more

Understanding Managed and Unmanaged Solutions in Dynamics 365

Dynamics 365, Microsoft's robust suite of business applications, boasts a myriad of features that can be customized to cater to the specific needs of any business. A vital concept to grasp when working with Dynamics 365 is the difference between managed and unmanaged solutions. This blog post aims to clarify these two types of solutions, providing a comprehensive analysis of the advantages and disadvantages of each. Unmanaged Solutions Unmanaged solutions act as a dynamic development environment, enabling direct alterations and additions to system components. They are often employed during the development and testing phase of a customization project but are equally effective when implemented in production instances, particularly for internal organizational operations. Pros of Unmanaged Solutions: Flexibility : Unmanaged solutions provide a high degree of adaptability, permitting developers to modify system components, introduce new elements, or discard those that are no longer nece...
3 comments
Read more