By Johan Küstner
Take a look at my utility that I have created to extend the Dynamics CRM Developer Toolkit:
https://visualstudiogallery.msdn.microsoft.com/b6aa76d0-a6fc-43a3-8d09-3ae383d30458
I created this utility to extend the functionality of CrmSvcUtil.exe and the Generate Wrapper functionality within Crm Explorer in Visual Studio when the Dynamics CRM Developer Toolkit is installed.
This utility adds the ability to generate the Enum for Option Sets and to generate Option Set Value Properties as well as State and Status Properties.
This utility also removes the Publisher Prefix when naming Classes, Fields and Properties and uses the Display Name instead. All spaces are removed from the Display Name in order to create the name.
This utility also enables generation of specific Entities only, using the includedEntities Key in CrmSvcUtil.exe.config. The default is *.
The CrmSvcUtil.exe.config installed by this utility includes the servicecontextname Key with a Value of XrmServiceContext. See https://msdn.microsoft.com/en-us/library/gg327844.aspx?f=255&MSPPError=-2147217396 for more details on parameters for CrmSvcUtil.exe.
The main component of the utility is CrmDeveloperToolkitExtender.CrmSvcUtil.dll.
The utility files are installed to %ProgramFiles(x86)%\Microsoft Visual Studio XX.X\Common7\IDE\Extensions\Microsoft\Dynamics CRM XXXX Developer Tools\1.0, where XX.X is the version of Visual Studio and XXXX is the version of Dynamics CRM. For example, for Visual Studio 2015, XX.X is 14.0. Please note that for the Dynamics CRM Developer Toolkit that ship with the SDK of Dynamics CRM 2011 and 2013, XXXX is always 2011, except for my version of the Developer Toolkit from https://visualstudiogallery.msdn.microsoft.com/8b4445bc-5cef-422c-9921-f52a137e3882, where XXXX is 2016.
I did originally have functionality that injected Create, Update, Delete and SetState Methods into every Entity Class. However, I decided to take this out as I now believe the best approach is for a developer to create their own Repository using the OrganizationServiceContext.
Originally, I created this utility for Visual Studio 2010. I then updated it to work with Visual Studio 2012, then Visual Studio 2013 and now Visual Studio 2015.
I had added quite a lot of other functionality, but have subsequently removed a lot of it as it has been superseded.
I had originally added functionality to automatically use ILMerge to merge Plug-in and CWA assemblies with all referenced assemblies. However, since the release of NuGet packages such as MSBuild.ILMerge.Build, I felt that this was now obsolete. It took a lot of work to develop the functionality and it didn't always work very well, as Visual Studio likes to lock files when compiling. I had to create a few workarounds to copy compiled assemblies to temporary folders for merging and then to set a delay and retries for copying the merged assembly back, attempting to replace the unmerged assembly that was locked by Visual Studio during compilation. This functionality ran as a MSBuild Task and I created a .targets file, adding an Import statement to the Dynamics CRM Developer Toolkit .targets file.
When merging assemblies and during deployments with the RegisterFile.crmregister file, I had problems with these files being read-only if not checked out of TFS Source Control. These files were not being automatically checked out of TFS Source Control when being updated. This was a particular problem with Visual Studio 2010. I therefore developed functionality to check files out of TFS Source Control and then back in again. However, with later versions of TFS and Visual Studio, this wasn't so much of a problem anymore. Also, with removing of the assembly merge functionality, I felt that this was no longer needed.
I also created functionality to publish customisations in Dynamics CRM after a deployment from Visual Studio. This functionality also ran as an MSBuild Task in my .targets file. There was also functionality to export the Dynamics CRM solution from Visual Studio with a timeout of 10 minutes. The out-of-the-box Developer Toolkit has functionality to export the Dynamics CRM Solution, but this has a timeout of 2 minutes and I therefore overrode this functionality with my own. There was some Dynamics CRM solutions that took longer than 2 minutes to export and timeout exceptions were being thrown. I ended up taking this functionality out when removing the rest of the functionality, mainly due to technical issues around the Import statement in the .targets file. I have not had the opportunity to add this functionality back, but will look at it at a later stage.
Part of the job that the installer performed was to inject an Import statement into the out-of-the-box Developer Toolkit .targets file to import my .targets file. However, I was having technical issues with the uninstaller not removing the Import statement as the out-of-the-box Developer Toolkit .targets file was either being locked or set to read-only.
Take a look at my utility that I have created to extend the Dynamics CRM Developer Toolkit:
https://visualstudiogallery.msdn.microsoft.com/b6aa76d0-a6fc-43a3-8d09-3ae383d30458
I created this utility to extend the functionality of CrmSvcUtil.exe and the Generate Wrapper functionality within Crm Explorer in Visual Studio when the Dynamics CRM Developer Toolkit is installed.
This utility adds the ability to generate the Enum for Option Sets and to generate Option Set Value Properties as well as State and Status Properties.
This utility also removes the Publisher Prefix when naming Classes, Fields and Properties and uses the Display Name instead. All spaces are removed from the Display Name in order to create the name.
This utility also enables generation of specific Entities only, using the includedEntities Key in CrmSvcUtil.exe.config. The default is *.
The CrmSvcUtil.exe.config installed by this utility includes the servicecontextname Key with a Value of XrmServiceContext. See https://msdn.microsoft.com/en-us/library/gg327844.aspx?f=255&MSPPError=-2147217396 for more details on parameters for CrmSvcUtil.exe.
The main component of the utility is CrmDeveloperToolkitExtender.CrmSvcUtil.dll.
The utility files are installed to %ProgramFiles(x86)%\Microsoft Visual Studio XX.X\Common7\IDE\Extensions\Microsoft\Dynamics CRM XXXX Developer Tools\1.0, where XX.X is the version of Visual Studio and XXXX is the version of Dynamics CRM. For example, for Visual Studio 2015, XX.X is 14.0. Please note that for the Dynamics CRM Developer Toolkit that ship with the SDK of Dynamics CRM 2011 and 2013, XXXX is always 2011, except for my version of the Developer Toolkit from https://visualstudiogallery.msdn.microsoft.com/8b4445bc-5cef-422c-9921-f52a137e3882, where XXXX is 2016.
I did originally have functionality that injected Create, Update, Delete and SetState Methods into every Entity Class. However, I decided to take this out as I now believe the best approach is for a developer to create their own Repository using the OrganizationServiceContext.
Originally, I created this utility for Visual Studio 2010. I then updated it to work with Visual Studio 2012, then Visual Studio 2013 and now Visual Studio 2015.
I had added quite a lot of other functionality, but have subsequently removed a lot of it as it has been superseded.
I had originally added functionality to automatically use ILMerge to merge Plug-in and CWA assemblies with all referenced assemblies. However, since the release of NuGet packages such as MSBuild.ILMerge.Build, I felt that this was now obsolete. It took a lot of work to develop the functionality and it didn't always work very well, as Visual Studio likes to lock files when compiling. I had to create a few workarounds to copy compiled assemblies to temporary folders for merging and then to set a delay and retries for copying the merged assembly back, attempting to replace the unmerged assembly that was locked by Visual Studio during compilation. This functionality ran as a MSBuild Task and I created a .targets file, adding an Import statement to the Dynamics CRM Developer Toolkit .targets file.
When merging assemblies and during deployments with the RegisterFile.crmregister file, I had problems with these files being read-only if not checked out of TFS Source Control. These files were not being automatically checked out of TFS Source Control when being updated. This was a particular problem with Visual Studio 2010. I therefore developed functionality to check files out of TFS Source Control and then back in again. However, with later versions of TFS and Visual Studio, this wasn't so much of a problem anymore. Also, with removing of the assembly merge functionality, I felt that this was no longer needed.
I also created functionality to publish customisations in Dynamics CRM after a deployment from Visual Studio. This functionality also ran as an MSBuild Task in my .targets file. There was also functionality to export the Dynamics CRM solution from Visual Studio with a timeout of 10 minutes. The out-of-the-box Developer Toolkit has functionality to export the Dynamics CRM Solution, but this has a timeout of 2 minutes and I therefore overrode this functionality with my own. There was some Dynamics CRM solutions that took longer than 2 minutes to export and timeout exceptions were being thrown. I ended up taking this functionality out when removing the rest of the functionality, mainly due to technical issues around the Import statement in the .targets file. I have not had the opportunity to add this functionality back, but will look at it at a later stage.
Part of the job that the installer performed was to inject an Import statement into the out-of-the-box Developer Toolkit .targets file to import my .targets file. However, I was having technical issues with the uninstaller not removing the Import statement as the out-of-the-box Developer Toolkit .targets file was either being locked or set to read-only.
Hello Johan,
ReplyDeleteI cannot connect to Dynamics 365 Online using this tool.
Do you have any ideas or where can I check the log?
Thanks for your help,
Kim Anh