Removing a Code Analyser from your machine during development

This post is just a quick tip for anyone that may be developing a Code Analyser withing Visual Studio using the Roslyn Compiler.

I got in a position where I was developing a code analyser using Visual Studio and the Roslyn SDK, I abandoned a project that was broken, but, whenever I launched Visual Studio afterwards, the analysis package would still be loaded and start crashing all over the place.

I really struggled to find a standard way of removing it from my machine (there probably is a way, but I could not find it), until I discovered this.

If you navigate to the following folder, you can simply delete the appropriate folder and it will be gone forever (I hope) :).


C:\Users\{username}\AppData\Local\Microsoft\VisualStudio\15.0_a85fe1c6Roslyn\Extensions\{user}

The actual file path may differ depending on versions of SDK and VS, but I am sure you can work it out ūüôā

Debugging Visual Studio Extensions

Whenever I set up a new machine, re-install Visual Studio, or simply re-download my Visual Studio Extensions from TFS, I always have to remember how to set up the environment so that I can debug the extension from within Visual Studio.

To be able to do this, here is the solution, in case you were wondering.

Problem

When hitting F5, or running/debugging the VSIX extension, you get a message in Visual Studio, something like:

a project with output type of class library cannot be started directly

Solution

In Visual Studio, in the project properties for your VSIX extension, the following options tell Visual Studio that when building the project, the VSIX compiled executable is created so that it can be run directly from Visual Studio.

To be able to run an “experimental” instance of Visual Studio which will then allow you to debug and set breakpoints in the original Visual Studio Instance that you have run the project from, you need to set the following options in the Debug tab of the Project Properties.

Note that the Start external program box is actually pointing to:

C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\devenv.exe

 

This allows you to debug the extension by pressing F5.  A new clean instance of Visual Studio will launch and allow you to test your extension.

CRM Utilities for Visual Studio – Generating Entity Classes

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";
    service.Create(contact);
}

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.

 

Download
Please note this feature is only available in the Visual Studio 2017 version. This version may still install on VS2015, although I have not personally tested it.

 

CODIAD – Self hosted cloud IDE for Microsoft Dynamics

When developing web resources for use in Microsoft Dynamics, I am a big fan of using Visual Studio with Visual Studio Team Services (VSTS), but for smaller organisations, or less experienced developers, sometimes this is overkill. ¬†I know a lot of people who just make do with Notepad++, and why not, as it’s perfectly capable of editing code, syntax highlighting and formatting.

In my journey to discover and use as many self hosted web-based systems as I can (stay tuned for an upcoming post for more information), I wondered if there was anything that might help Dynamics developers (and other small project developers).

That’s when I happened upon CODIAD (¬†http://codiad.com/¬†) which is an online IDE for developing JS, HTML, CSS, XML and many more file formats. ¬†It offers full syntax highlighting, project collections and an extensible plugin system.

Continue reading “CODIAD – Self hosted cloud IDE for Microsoft Dynamics”

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/

 

Dynamics CRM Utilities for Visual Studio

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.

CRM Utilities for Visual Studio

There are two versions, one for Visual Studio 2017 and one that is compatible with Visual Studio 2013 and 2015.

Forcing Internet Explorer out of compatibility mode

While developing some web resources¬†for Dynamics, and also an external Web Portal, I was struggling with getting Internet Explorer to display properly, specifically¬†using older browser versions such as IE7,IE8 and IE9. If I listen closely, I can probably hear you say “use the latest version of IE, upgrade, update and be done”.¬† Well, if I were in a position to make that happen, I probably would, however, like a lot of people out there working for structured companies, their base “corporate” desktop install never has the latest version of anything on it.

After much googling, I discovered that there is a specific meta tag you can use that causes Internet Explorer to use the latest standards, thus preventing any display issues.

So, in my web resources, I have added the following to the HEAD section and it seems to do the job quite nicely.

<meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1">

For my web portal, I was able to achieve the same across all pages by adding the tag into the IIS settings. I used the GUI to do this, but I did notice that all it did was add it to the web.config file.

In IIS, within your web site/application, select the following option :

ieStandards1

And then add the following :

ieStandards2

The resulting web.config for the web site/application now contains the following :

<httpProtocol>
     <customHeaders>
           <add name="X-UA-Compatible" value="IE=edge,chrome=1" />
     </customHeaders>
</httpProtocol>

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();              
    }
}