Tuesday, May 30, 2017

CRM Developer Extensions - Where's VS 2017 Support?

In the process of a rewrite for Visual Studio 2017.

Why a rewrite? There were some changes to be made to make the original extension work in VS 2017, it wasn't going to be a major effort but I thought this would probably be a good time to re-evaluate what was done so far and make some improvements. When I started out originally I really didn't have any plan, I just started coding. It didn't help either that I had no previous experience developing extensions for Visual Studio so I was learning as I went. Ultimately though in the end, it was a mess and it was amazing anyone at all contributed (big thanks to those that did).

As a quick refresher for those that maybe aren’t familiar with this project. In the 2011/2013 days Microsoft shipped the Developer Toolkit for Visual Studio with the SDK which had templates, deployment tools, etc. to make a CRM developer’s life easier. When 2015 rolled around it took a hiatus. Preferring not to not waste time on the tedious tasks I built my own set of extensions (VS Marketplace / GitHub) with templates, deployment tools, and other things. It seemed to fill the gap and may people got value out of using it – nearly 26k downloads thus far. Now we’ve come full circle and with Dynamics 365, Microsoft has released a new version. It’s got some cool features but ultimately isn’t getting the love it needs. Microsoft probably needs to hire someone that’s beyond outgoing and is an authority on Azure to work on it – there’s a not funny joke in there BTW :)
So what's the plan this time around? Here's what I had in mind so far.

  • Visual Studio 2017 compatibility – still thinking about supporting back to 2012 as the new VSIX v3 is supposed to support that
  • Still avoiding proprietary project types – this is one of the things I dislike most about the Microsoft offering, some of the projects won’t open unless the Developer Toolkit is installed which makes it headache in multi-developer scenarios where every person might not have the same tools installed
  • Removing the custom login and replacing with the SDK Xrm.Tooling login control – one of the things people have the most problems with and to this day I can’t explain why many still end up with an empty OrganizationService after connecting –also this removes the need to handle credentials and puts the onus on Microsoft to make sure it connects for everyone
  • Solution level mappings – should prevent having to re-connect when switching between projects in a solution, also out with the XML and in with JSON
  • Better code structure – since I didn’t know what I was doing last time out there were many things replicated and/or poorly implemented making it difficult for anyone else to pick it up and make changes – adding some level of abstraction to the core interactions that extensions rely on the work within the solutions system so it’s easier to consume without prior extension knowledge
  • Better NuGet support – to try and guide people down the right path I was choosing which versions of the various SDK assemblies got in installed when creating a new project, it worked well but relied on a lot of hardcoded stuff to make work and required updating when new major versions were released, putting stress on me to get an update out right away – this time new projects will be presented with a dynamic list of the required packages straight from NuGet, any version can be selected and will always be up to date
  • Web resource deployer – probably not too many fundamental changes from the previous version but still hoping to incorporate previous feedback I’ve received
  • Plug-in deployer – the current version is pretty basic and only handles moving the actual assembly and doesn’t address anything associated with the registration – what I’d like this time around is to address those gaps (effectively re-building parts of the Plug-in Registration Tool) and/or incorporating what Scott Durrow is doing with his SparkleXrm task runner, specifically around putting the registration details directly into the plug-in code and using it during deployment to handle setting up all the steps, images, configurations, etc. – as a person that often has to look at other people’s code I can tell you that having the registration details readily available in the code without having to open and click through another tool to figure out when it’s being executed is darn useful
  • Solution packager – probably not too many changes from the current implementation, maybe adding a deploy solution option
  • Report deployer – may get dropped, feels like it’s usefulness is lessened if you can only create reports in VS 2012
  • Early bound class creation – would love to have this functionality, hoping maybe to maybe see if Daryl LaBar will allow a port of his XrmToolbox implementation
  • Templates – would definitely like to explore other options, specifically around unit testing, maybe including some of the community testing frameworks – would really like to see someone develop a framework for JavaScript unit testing that incorporates CRM – maybe even VB templates for that 1 guy who gave the project 1 star on the VS Marketplace because it didn’t have them – also had thoughts about a tool that would capture data from a live CRM instance to incorporate into unit tests
  • Localization – would like to get all text into resource files so it can eventually support multiple languages
  • Documentation – provide better documentation how the project is put together and where to find things in hopes it makes it easier for others to contribute
  • Unit tests – actually including some - again hoping this will work toward being able to merge changes with more confidence and get quicker turn around

That brings us to what people could to do to help. But first let me share my opinion on something. It’s easy to sit back and call out Microsoft for not updating their tools to VS 2017 fast enough or to complain about this, that, or the other thing not working. As hard as I tried I’m not able to aid that cause (and I did try), but what I can do is solve the problem from a different angle which is delivering this alternative. So if you’ve made it this far and weren’t turned off by what I just said and are willing to help, this is what I’m looking for:

  • Ideas – I’d really like to hear about what other people are doing or what kinds of things would make CRM development easier or better. As this progresses, feedback on functionality is welcomed.
  • Code – Ideally I’m hoping a few people will actually want to get in and submit some pull requests. Willingness to learn a little about Visual Studio extensions is helpful but probably not required as most of that I’m willing to handle and/or expose in some manner. If there’s something you’re interested in and it isn’t in place, let me know and I’ll get it there. If you aren’t able or comfortable in submitting directly and have something like project or item templates or functionality built in WPF (user controls) that doesn’t rely too heavily on interaction with Visual Studio you can always send over something partially finished and I can try to get it added that way. Even going through and refactoring code or moving text to the resource files would be helpful.
  • Unit tests – probably a long shot but if you like writing them there’s plenty of opportunity.
  • Testing – I’ll try and get some early builds out that can used prior to final release to the VS Marketplace that can be installed manually.

If you’ve got something to say or are willing to help – post it on the GitHub Issues page for the project and I’ll be in touch. Or if you just think I'm nuts then I guess you could mention that too.

I love Dynamics 365/CRM as a platform and want to see others adopt it. My contributions are really meant to take away some of the barriers for entry into the space and get people solving business problems faster.

Work in progress:
https://github.com/jlattimer/CrmDeveloperExtensions2







Friday, March 3, 2017

Using Azure Key Vault to Store Configuration Data

There’s lot of ways to store things like username, passwords, urls, etc. for use in CRM code. I’ll be comparing some of those methods in a future blog post, but the more common approaches usually lack 2 things.

First, if you place a value inside some CRM construct and that data changes then you need to track it down in each and every environment and make updates. Maybe doesn’t sound so bad if you’ve only got a couple environments and a little bit of code but as you expand into larger organizations with multiple orgs for Dev, Test, QA, Training, Production, etc. and you start having multiple developers each take their own approach to handling this data, well you can see where this suddenly gets hard to manage.

The second thing is that these usernames and password stored in CRM really aren’t secure. The data isn’t encrypted unless you’re handling it yourself. Sure you can control which users have read access to the plug-in configurations or custom entity records but that probably won’t satisfy that guy from IT security.

One possible solution is to use the Azure Key Vault to store this sensitive information. You can read the finer points for yourself but these are some of the key takeaways:
  • Encrypted storage
  • Centralized management – keep track of all your configuration data in 1 place
  • Logging of key use
  • Simple REST API
Of course there’s some not so good points:
  • Some performance hit – need to make requests outside CRM to get the data
  • Can only retrieve 1 key at a time (unless you’re tricky and combine values)
  • Cost – $.03 per 10,000 operations, not free but not terribly expensive
  • Still need to manage some configuration values inside CRM in order to retrieve data
Still interested?

Getting Set Up

Create a Key Vault in Azure – should be pretty self-explanatory when you click through the portal

image

Create a Secret in the Key Vault

image

Register an application with Azure AD in order to get a Client Id & Client Secret – no different than generating values for CRM Web API use

image

image

Authorize the application – in your Azure AD application you’ll need to give it delegated permissions to Azure Key Vault

image

Allow application access to your secret by created an Access Policy – choose the application you registered as the Principal and give it Secret – Get Access, if you plan on trying to retrieve a Secret based on the name as you’ll see later on, also assign Secret - List Access

SNAGHTML21dd96db

In your Secret, grab the Url as you’ll need it to access it later

image

Finally back in Azure AD under Properties, get your Directory (Tenant) Id as this is also needed later

image

Retrieving A Key Vault Secret In Code (Part 1) Get The Access Token

  1. Use the Client Id, Client Secret, and Tenant Id to request the access token needed for the Key Vault requests
  2. Deserialize the JSON response and extract the token


Retrieving A Key Vault Secret In Code (Part 2) Retrieve A Secret By Url

Earlier in the set up steps you were able to grab a url corresponding to the specific version of the Secret you stored. In cases where you don’t plan on changing the value (revising), using the url should be OK.
  1. Use the url of the Secret and make a HTTP GET request including the access token in the authentication header
  2. Make sure you’re also including the API version at the end of the url
  3. Deserialize the JSON response and extract the value


Retrieving A Key Vault Secret In Code (Part 3) Retrieve A Secret By Name

The problem with using a url is that if you ever want to change the Secret value, you’ll need to make a new version, which in turn creates a new url. I’m sure being able to maintain versions is helpful in many cases but if it’s something like a password, then not so much. The Key Vault API doesn’t have any type of query functionality but it does allow retrieving all versions of a given Secret. So what do we do when a Secret changes and we don’t want to go through CRM environments and update urls? The Key Vault API does provide a means to retrieve all versions of a Secret based on the name. We can do this and then determine which is the most recent, enabled version and use it to retrieve the current value. Admittedly this ends up being at least 3 requests to get the actual value but I guess it’s a small price to pay for security and convenience.
  1. Use the name of the Secret and make a HTTP GET request for the versions including the access token in the authentication header
  2. Max of 25 versions are returned so paging may be required
  3. Deserialize the results and determine which is the most recently created that is also enabled
  4. Use the “id” property (which is the Secret url) to retrieve the Secret value
  5. Deserialize the JSON response and extract the value


In conclusion, this might not be the best solution when performance is your primary concern but it you’re looking for security and manageability then this might be worth taking a look at.

You can download the complete sample here:
https://github.com/jlattimer/CrmAzureKeyVaultExample

Wednesday, January 4, 2017

Show SharePoint Documents on the Main Form

Here’s an easy way to embed the SharePoint document window you’d normally get by navigating to “Documents” under related records, which includes all the native functionality like search, upload,
This might fall under the area of semi/not supported but if it happens to break one day you won’t have invested too much.

You’ll need to create an iFrame for the SharePoint content, probably within it’s own tab. Remember what you name the iFrame as you’ll need to modify with that value.

When configuring the iFrame...

On the General tab:
  • Restrict cross-frame scripting… to Unchecked
On the Formatting tab:
  • Number of Rows to 34
  • Scrolling to Never
  • Display Border to Unchecked
You could set the rows to a lower number, you’d just end up with a scrollbar despite the never scroll setting.

Take this code and update the iFrame name and add it to the form. Call SetDocumentFrame during the form’s OnLoad event.

If you’re doing this, you might also consider turning on the option to auto-create SharePoint folders. Otherwise people are going to be getting prompted. You can find this under:

Settings –> Document Management –> Document Management Settings and then it’s on the 2nd page.

With any luck, you’ll end up with something like this:



Friday, December 30, 2016

New Tool - CRM Code Editor

If you’ve ever tried to make a quick change to some JavaScript code inside CRM you’ve probably come to the conclusion that the experience isn’t so great, in fact it’s terrible. Not being able to tab to indent code alone drives me nuts. Of course you can’t blame the product as it wasn’t designed to be an IDE and all the development money goes into things like editable grids and such. If you keep up on some of the news on the developer front you’ve probably heard of Visual Studio Code, Microsoft’s newish IDE which lets you edit a huge variety of code and runs on Windows, Linux, & Mac. The reason they can be able to support versions for multiple different operating systems is that it’s ultimately built on HTML & JavaScript which runs anywhere. I stumbled across a reference to the Monaco Editor which happens to be what VS Code is built on. If you follow the link you’ll see the editor running in your browser. And as it turns out, all the code is available on GitHub, so I decided to try and incorporate it into a CRM solution because it didn’t look like it would be all that hard. So in the the tradition of generically my named solutions I’ve created the CRM Code Editor.

For those that care, this was built using AngularJS and TypeScript.

To display the  web resources to edit I built my own grid to list the items. Remembering that natively finding a web resource is also difficult, I added the ability to filter by type, filter by managed/unmanaged and search on the name fields. At the grid level I also added some buttons to quickly:
  • Delete
  • Copy a link to the file
  • Copy a script tag (which in hindsight shouldn’t be available for non-JS files)
  • Open the native dependency window



As you would expect the editing experience is top notch now that we have a real editor. We no longer have to worry about tabbing out the code, it actually indents! There are the obvious things like syntax highlighting, intellisense, code folding, formatting code, etc. If you right-click inside the editor you’ll see a similar window & command palette like in VS Code which lets you do all kinds of things. Since CRM only supports a finite number of files types, I’ve enabled editing of JS, HTML, CSS, and XML files. FYI - if someone figures out a way to transpile TypeScript in a browser let me know as I’ll add that in as well.



I also enabled the diff. editor so you can easily compare the published version of a file to the working copy.



A few more features I added on top of everything else:
  • Save/Save As/Save & Publish
  • Copy code
  • Drag/drop files into the editor to upload/edit
  • Code snippets
If you follow my blog you probably saw that I created an extension for VS Code which contains code snippets for the entire CRM JavaScript SDK. I took all those and included them in this editor. You can find a full list of what’s available on that project’s site. For the most part if you start typing part of a known function like “getValue” you’ll be prompted with some options to choose from.



This solution probably isn’t for the full-time developer as I would expect they are already using a desktop based editor with source control integration to do all their work but this might be of use for those that aren’t or something you can keep installed in a sandbox to play around with and test things out easily.

Checkout the project on GitHub:

 https://github.com/jlattimer/CRMCodeEditor

For 2015 & 2016 use the v2.0.0.0 release
For 2011 & 2013 use the v1.0.0.0 release

https://github.com/jlattimer/CRMCodeEditor/releases

Friday, December 9, 2016

CRM REST Builder v2.5.0.0

New in this release:
  • Added 8.2 endpoint
  • Changed functionality to reload CSDL when endpoint changes to ensure metadata is correct
  • Added 8.2 option to return full entity on create & update
  • Added option to retrieve, update, and delete via alternate keys
  • Added header options for upsert (prevent create & prevent update)
  • Added ability to optionally select non-required parameters for actions & functions
Checkout the project on GitHub:

https://github.com/jlattimer/CRMRESTBuilder

For 2015 & 2016 use the v2.5.0.0 release
For 2011 & 2013 use the v1.5.0.0 release

https://github.com/jlattimer/CRMRESTBuilder/releases