My utilities are now on the Visual Studio Marketplace

Just a quick update to say that all of my Visual Studio extensions are now on the Microsoft Visual Studio Marketplace, and are available to download and install direct from Visual Studio.

Visual Studio Marketplace

Simply go into the Tools menu and choose Extensions and Updates, select Online and search for me, James Hall.  My extensions are the top two in the list.

In theory, if you install them this way, you should get notified of when I update them.

Diagnostics and Information page, a reminder

As I keep forgetting that these pages exist, I am re-blogging the following information as its very useful :), and maybe I will eventually remember these URL’s.

Diagnostics
 
http://<ServerName>/<OrganisationName>/tools/diagnostics/diag.aspx
 
Debug Information (on premise only)
 
http://<ServerName>/<OrganisationName/home/home_debug.aspx

Here are some bookmarklets that you can drag to your bookmarks bar which should allow you to just click on them while on a CRM instance, and the appropriate pages should pop up.

LinqPad Utilities for Microsoft Dynamics – New Release

Today I have just released the first official version of my LinqPad Utilities for Microsoft Dynamics plugin library.

I use this tool in my everyday life working with CRM and its gradually grown in to a fully fledged tool.

It allows you to configure a number of reusable CRM Connection Strings to connect to Microsoft Dynamics (all versions) and has a number of useful utilities for working with Dynamics.

Feel free to download and try it.

LinqPad Utilities for Microsoft Dynamics

To begin with, you will need LinqPad (which is free, but you can also purchase a license) from the following site.

https://www.linqpad.net/

 

FormXML solution layering

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.

Fixing a WCF Web Service for Cross Domain/Browser Support

I had an issue recently where I was attempting to make my CRM 2011 customisations cross browser compatible. The issue was when I was calling a Web Service via Jquery’s AJAX methods. It was working fine in Internet Explorer, but when I was trying to access it from a Web Resource within Chrome, I was getting an issue that was suggesting it was a cross domain problem.

Although the web service was running on the same host, as it was on a different port, it was being classed as a cross domain ajax call and Chrome was stopping it.

I spent a while trying to find out how to fix the client JavaScript assuming the issue was how I was calling it, and then I stumbled on some useful information about Web Services and a nice little piece of code to enable the web service to work perfectly, leaving the client alone.

The issue boiled down to some extra calls being made to gather OPTIONS around the safety of the request.

“OPTIONS” Request called as “Preflight Request” – “preflighted” requests first send an HTTP OPTIONS request header to the resource on the other domain, in order to determine whether the actual request is safe to send and this request expects appropriate headers saying that service is allowing to access the service as a Response

The fix is to add a global.asax file to the web service project and include the following code which handles this OPTIONS request. Build, and deploy and all of a sudden it was working fine in Chrome as well 🙂

protected void Application_BeginRequest(object sender, EventArgs e)
{          
    HttpContext.Current.Response.AddHeader("Access-Control-Allow-Origin", "*");          
    if (HttpContext.Current.Request.HttpMethod == "OPTIONS")
    {               
        HttpContext.Current.Response.AddHeader("Cache-Control", "no-cache");
        HttpContext.Current.Response.AddHeader("Access-Control-Allow-Methods", "GET, POST");
        HttpContext.Current.Response.AddHeader("Access-Control-Allow-Headers", "Content-Type, Accept");
        HttpContext.Current.Response.AddHeader("Access-Control-Max-Age", "1728000");
        HttpContext.Current.Response.End();              
    }
}

LinqPad for testing plugin development and workflow activities

We all know that developing and debugging plugins with Microsoft Dynamics CRM 2011 (and 2013) can be troublesome.  Having to code blind and expecting it to work when you deploy it to your server to test it.

I have recently started using LinqPad to develop my plugin and workflow code, testing to make sure the logic works, before copying the code into Visual Studio and deploying.

LinqPad is a very handy tool that reminds me of days before where you could just write code straight into an editor, and run it, not having to create projects, and building and debugging.

Its fully extendable, and once you have it set up, makes writing straight forward C# code and Linq queries very easy.  There are a couple of ways to use it depending on if you prefer early or late bound approaches to manipulating and retrieving your Dynamics Entities.

First things first though, download and install it from the LinqPad website.

LinkPad

Install it on your machine, and run it.

There are two ways of using it, late bind and early bind.  I prefer Late bind (where you reference your entities in a generic fashion) but early bind (where you can reference your entities and attributes by name) has its uses.  For plugin development, late bind is bar far the easiest to get started with as you dont have to generate class files for your Dynamics deployment, and your assemblies are much smaller.

To set up early bind, you simply add the Dynamics URL as a data connection within LinqPad, and your ready to go.  To use late bind, you have to write some C# code to enable a connection to your Dynamics Server (but don’t worry, I am going to provide you with some sample code).

Adding a connection for Early Bind

To add a connection so that you can reference your entities via name, simply click on the Add Connection link at the top left to bring up the “Choose Data Context” window.

LinqPad2

Choose WCF Data Services 5.5 (Odata 3) and on the next screen, enter the following URI :

LinqPad3

http://<servername>/<organisation>/XRMServices/2011/OrganizationData.svc/

You can leave the username and password section blank if your logged in with Active Directory, ad you can also select either XML or JSON. When you hit OK, the data connection will now appear and you can expand it out to show all of your entities, and their attributes.

LinqPad4

You can now begin writing code as long as the code window has the connection set to use the connection you have just created.

Adding a connection using custom code

In my opinion, the best way to use LinqPad is to write your own connection. If you are a registered user of LinqPad, you can use NuGet to download all of the CRM assemblies ready to roll, but I am going to go through the steps required in case you are just using the free version.

The first thing you need to do is to select the My Extensions document in the bottom left window. This is where you can write some code that will allow you to connect to Microsoft Dynamics.  I have enclosed a sample below which you should just be able to copy and paste into the window once you have set up the environment.

First things first, in the My Extensions window, hit the F4 key to bring up the windows properties. In this window, this is where you need to add all of the MSCRM SDK DLL’s you will be requiring, such as

LinqPad5

Simply browse to the files (assuming you have already download the SDK) and add them in to your extensions window. You then also need to set up your namespaces so that you can access them.

Microsoft.Xrm.Client
Microsoft.Xrm.Sdk
Microsoft.Xrm.Sdk.Client
Microsoft.Xrm.Sdk.Deployment.Proxy
System.Collections.Specialized

Now for the code that you will use to connect to Dynamics. Simply Paste the following :

void Main()
{
	// Write code to test your extensions here. Press F5 to compile and run.
}

/// My Extensions is a class to allow a connection to MS Dynamics 2011	
public static class MyExtensions
{
	// Stores a number of specific connection strings
	public static  NameValueCollection ServerConnections = new NameValueCollection();
	// Populates the connection strings
	public static void PopulateConnectionStrings()
		{
			ServerConnections.Add("HALL2013","url=http://crm2013/HALL2013/XRMServices/2011/Organization.svc;");
			ServerConnections.Add("HALL2011","url=http://crm2011/HALL2011/XRMServices/2011/Organization.svc;");
		}
	// GetOrgContext - return a connection 
	public static OrganizationServiceContext GetOrgContext(string connectionString)
		{
			PopulateConnectionStrings();
			CrmConnection connection = CrmConnection.Parse(ServerConnections[connectionString]);
		
			var result = new Microsoft.Xrm.Sdk.Client.OrganizationServiceProxy(
				connection.ServiceUri,
				connection.HomeRealmUri,
				connection.ClientCredentials,
				connection.DeviceCredentials);
		
			result.EnableProxyTypes();
			Microsoft.Xrm.Sdk.Client.OrganizationServiceContext orgcontext = new OrganizationServiceContext(result);
			return orgcontext;
		}
	// GetOrgService - return a connection
	public static IOrganizationService GetOrgService(string connectionString)
		{
			PopulateConnectionStrings();
			CrmConnection connection = CrmConnection.Parse(ServerConnections[connectionString]);
			
			var result = new Microsoft.Xrm.Sdk.Client.OrganizationServiceProxy(
			connection.ServiceUri,
			connection.HomeRealmUri,
			connection.ClientCredentials,
			connection.DeviceCredentials);
			
			result.EnableProxyTypes();
			return result;
		}
}

Hit the green play button, and in theory, it should build and compile.

I have coded this so that you can add extra connection strings in case you have multiple environments. You can then simply instantiate a connection by using :

var conn = MyExtensions.GetOrgContext("HALL2011");

Writing Code

Now, to begin, create a new query by clicking on the plus sign at the top of the main text window. A query will be set up and it should be ready to go with all of the assemblies and namespaces you set up within your extension.  Make sure you have C# Statements selected, and type in the following as a simple test to make sure everything is working :

var conn = MyExtensions.GetOrgContext("HALL2011");

var response = (WhoAmIResponse)conn.Execute(new WhoAmIRequest());

response.Dump();

Should give you the following

LinqPad1Res1

The results, by default are rendered as XML, but you can click the grid button just along from the run button to display the data as a grid. You will notice the line response.Dump().  LinqPad extends everything with this command, and will output it within the results pane.  You can use this to output variables and objects so you can see what it looks like.

LinqPad1Res2

And your set. You can now right code, linq queries etc and run them straight away.  If you change the Language selector to C# Program, you can even create functions and test them just as you would in Visual Studio.  This allows you to test all of your plugin and workflow activities logic within LinqPad before putting the code into your CRM server. You can easily add other reference assemblies and namespaces to your queries as you see fit.

Another example (using an email template and then finding the attachments)

InstantiateTemplateRequest instTemplateReq = new InstantiateTemplateRequest

{

TemplateId = new Guid("CE6E9346-8FFB-E311-8997-005056A507B0"),

ObjectId = new Guid("995623E6-58F8-E311-8997-005056A507B0"),

ObjectType = "incident"

};

InstantiateTemplateResponse instTemplateResp = (InstantiateTemplateResponse)conn.Execute(instTemplateReq);


Guid id = new Guid("CE6E9346-8FFB-E311-8997-005056A507B0");

var files = from f in conn.CreateQuery("activitymimeattachment")

where (Guid)f["objectid"] == id &&

(string)f["objecttypecode"] == "template"

selectnew {f};

files.Dump();

Debugging within Visual Studio

And it gets better, why not just use LinqPad to set up some test data, and then call your plugin code directly and debug within Visual Studio.

In LinkPad, within your query window, hit the F4 key and add your plugin assembly and its namespace to your query properties.

In LinqPad, you can set up any variables your plugin code may need. As an example, I have started to place my plugin logic within a separate static class with various methods that take parameters.  This way, the plugin can deal with the input and output parameters, but I then have separate code blocks that do the processing.  In LinqPad, you can then simply call this logic with the appropriate parameters.

If you then use the command

Debugger.Launch();

It will kick off Visual Studio’s debugger and you can step through your plugin code. Simples.

Shared Data Source for reporting

When developing reports for Microsoft Dynamics using SQL connections, it is recommended to use a shared data source so that you can include your reports within a solution and allow them to be promoted across different environments without having to amend the data source.

Microsoft Dynamics provides a Data Source called MSCRM_DataSource which always points to its SQL environment, so if your reports use a shared data source called the same, it doesn’t matter which environment it is installed on, it will be using the correct Data Source for your SQL server.

Shared Data Source in Report Project
Shared Data Source in Report Project