I have updated my extension to support publishing of files from Visual Studio to Microsoft Dynamics Portals.
The tool now supports publishing files to Web Templates and Web Files, allowing you to use Visual Studio to edit and track changes of your portal related files, and quickly update Dynamics with the appropriate Portal files.
Web Files and Web Templates are simply listed within the Web Resource linker dialog for you to select. You can then publish the appropriate files within your Visual Studio solution to Dynamics.
If you have installed the extension from the Marketplace, then it should prompt you to update, but if not, you can get it from the below link.
I have decided to release my Visual Studio Template for Microsoft Dynamics. This allows you to quickly create a Solution within Visual Studio that holds separate projects for keeping your assemblies, web resources and data organised.
Most CRM Developers either use, or have at least heard of CrmSvcUtil for generating early bound classes for developing code and using the resulting classes to manipulate CRM data. I personally do not like working with early bound entities as the resulting class files are huge, and I personally prefer working with the standard Entity Framework for creating and updating entities, and for Linq queries.
Often, I use some helper class libraries that I can use to represent the custom entity names and attributes, so that they can be referenced in code and provide a degree of separation from the actual Schema names and to make code easier to write, and support Intelli-sense.
Something like the code sample below:
public static class Contact
public static const string EntityName = "contact";
public static const string Name = "fullname";
This would then allow you to do the following:
public void createContact()
Entity contact = new Entity(Contact.EntityName);
contact[Contact.Name] = "Joe Blogs";
I was offered a suggestion by a fellow developer that wouldn’t it be good if my CRM Utilities for Visual Studio allowed you to generate this kind of Class file automatically. Well, I thought it was a brilliant idea, and so thanks to the wonderful gentleman of XRTSoft, here it is.
Its split into two options, one to generate classes for your Custom Entities, and one to do the Standard CRM entities.
The resulting file will look something like this:
Notice that for each Entity, it will add the Logical Name, Primary ID Attribute, and the Primary Name Attribute as standard, and then all of the attributes as well. It will also add sub classes for any Option Sets to allow you to reference specific Option Set Values without having to look them up in CRM.
I have decided to release a small utility that I developed and have been using for a long time when developing Web Resources for CRM within Visual Studio.
It allows you to publish Web Resources to CRM straight from within CRM, and if you attach it to a Keyboard Shortcut, means you can publish it with a press of a key as soon as you have finished editing it.
It allows you to edit JS, HTML, XML and images as part of a Visual Studio Solution. It saves your connection string locally within a project, and remembers which files relate to which CRM Web Resources. It also allows you to run FetchXML queries, and you can save your queries as part of your Project.
It can be downloaded from here, and full instructions on how to use it are also available.
When working with Managed Solutions, and layering them on top of each other, be mindful of one very important fact.
If you include an entity in a solution, that is also present in another solution, then the most recent solution to be installed in a system will take precedent over others when it comes to certain things such as entity forms.
For example, if you have solution A containing entity 1 and install it managed onto a server, and then later install solution B which also contains entity 1, then it’s solution B’s customisations that will be applied. If you later edit entity 1’s form within solution A and try and install it onto the server containing both solutions, the form customisations will not take.
You must always try and ensure, where possible, that each entity only exists in one solution. This would not apply if you were always going to be providing both solutions as a pair to be installed.
To safeguard, always attempt to create a new form in each solution so that customisations are carried out in each solutions specific form, and always try to avoid accidentally including entities in solutions where they don’t need to be as you can’t always roll them back due to dependancies.
Good news is that with CRM 2016, you can include only the bits you need in a solution making it easier to avoid these kind of layering issues.