Monday, August 21, 2017

Easy Plug-in Logging Using IL-Weaving

So what is IL-weaving or Aspect Oriented Programming (AOP)? At a high level, it’s the process of "magically" injecting additional code into what you’ve written at some point during the assembly’s life cycle. But why the need? Using an automated and repeatable process to examine the code that’s written and add to it can be beneficial because it’s less code the developer has to write in the first place (so less potential mistakes) and can also address things the developer forgot (like disposing of objects). For the purposes of this post I’m not going to get into the specifics on how any of the techniques work under the hood, but if you’re interested in more detail on these processes you can read more about approaches in .NET, run-time weaving and compile-time weaving.

The example I’m going to run through stems from something that happened a few months ago and how injecting code would have made dealing with the situation easier.

Scenario, things are processing slower than the client would like. There are plug-ins, lots of plug-ins. Those plug-ins fire other plug-ins which fire other plug-ins. Also everything is running synchronously. When reviewing the code the plug-ins are quite complex. It’s fairly clear there are extra executions happening that shouldn’t be but based on the amount, complexity, and state of the code it’s hard to tell where to begin looking. My colleagues I was working with decide to add some timers to the methods that are most likely the ones that are the root of the problem to see where the bottlenecks are. The result was adding Stopwatch code to the beginning and end of methods all over the place. Not terribly difficult, just time consuming and messy when done in mass.

Well after the fact I ran across this notion of AOP and saw an example of dynamically injecting this Stopwatch code without having to actually write it. To demonstrate I’m using the open source library Fody (specially MethodTimer) which uses compile-time weaving to inject the Stopwatch code.

Walking through the example:

ManualTimer method: This might be what your code would look like when you add Stopwatches to each method’s execution today. While I'm sure you could probably simplify this some, there are still many extra lines of code.

IlWeavngTimer method: This produces the same result only by adding an attribute to the method. There is some code to support this. Toward the end there are 2 internal classes, one for the attribute and one for the actual logger. In the Execute method of the plug-in I’ve created a static instance of the logger and gave it the CRM Tracing Service to write to.

IlWeavngTimerCompiled method: If you decompile the assembly, this is what actually ended up being compiled. As you can see it added the Stopwatch code around my existing code.

The process of adding code is done during the build process and doesn’t take any dependencies on any third-party libraries – so it’s safe for CRM/D365 Online. The 2 internal support classes are also removed in the compiled assembly – assuming you’ve designated them internal.

Now for every method you want to time execution on you can simply add the [Time] attribute (including Execute) and it will write the execution time to the plug-in trace log.


You can see the full solution here:

https://github.com/jlattimer/D365FodyLogging

Wednesday, August 9, 2017

Dynamics CRM/365 Yeoman Generator

As a result of a recent Twitter exchange I spent a few hours this past weekend and came up with a Yeoman generator for CRM project templates. Now you can create CRM projects from the command line – what fun! But really the potential benefit is being able to work using Visual Studio Code. Maybe not something you’d do for your day to day development but when you’re just trying to do a quick POC of something, firing up VS Code and generating a template here is probably going to be a lot faster then opening up the full version of Visual Studio. As long as you’ve got the C# extension installed you’ll get intellisense and the project templates are configured so you can start running and debugging code right away.

If you aren’t familiar with Yeoman it’s really just a framework for scaffolding out templates for various types of projects and files. It allows you to pull in dependent packages from sources like NuGet or npm as well as to manipulate the items you end up creating.

A few of the features of what I’ve built

  • Choose from a number of different templates:
    • Console 2016+ Project (CrmServiceClient)
    • Console 2011-2015 Project (CrmConnection)
    • Plug-in Project
    • Plug-in Class
    • Custom Workflow Project
    • Custom Workflow Class
  • Pick from the latest version of each major/minor version of the SDK Core Assemblies from NuGet
  • Console projects will get the latest XrmTooling.CoreAssembly or CrmSdk.Extensions version from NuGet corresponding to the SDK Core version that was selected 
  • Console projects will get an appsettings.json file with ready to update connection strings
  • All projects can be used with VS Code or Visual Studio
  • Plug-in and workflow projects will have a new strong name key file generated and assigned to the project
  • Optionally create a Visual Studio solution file

You can check out the code on GitHub:
https://github.com/jlattimer/D365Yeoman

Or on npm:
https://www.npmjs.com/package/generator-d365


If you’re looking to install:
npm install -g yo

npm install -g generator-d365

And then to run:
yo d365

Have fun!

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: