When trying to compile a FetchXML-based report in Visual Studio 2015 which had been developed in an earlier version of Visual Studio, we were getting the following error:
While you can’t ordinarily log in as another user through the Dynamics CRM/365 front end, as a System Administrator it is possible to impersonate another user when making calls to the CRM API.
This is very useful if you want to be able to do the following:
LINQPad automatically makes available any snippets which are configured in Visual Studio. For example, if you type ‘cw’ (for Console.Writeline), LINQPad will inform you that it is aware of the snippet and prompt you to press Tab to insert the snippet at the cursor.
Whilst there is no built-in source control integration in LINQPad, it is still easy to keep your LINQPad scripts under source control. This means that scripts can easily be shared amongst your team and you can take full advantage of the benefits of source control, such as versioning and safe file storage in an external repository.
In the first article in this series, I demonstrated how to use the Dynamics CRM LINQPad Driver to connect LINQPad to CRM. In this follow-up I will show how to create a ‘manual’ connection, and why you might want to do this.
LINQPad is an invaluable tool for any .Net developer, and it will greatly enhance your ability to write and support applications using Dynamics CRM. There are two ways with which to connect to an instance of Microsoft Dynamics CRM using LINQPad. This two-part article will describe these two different methods and examine the reasons why you might choose one over the other.