Solutions have nothing to do when we’re working with queries, right?
So why is this the best feature I have released this last year, or longer?
I know, the subject seems like a crazy big blog…
…anyway, go on and see why you should know it!
My recent article Case closed: Managed or Unmanaged solutions in Microsoft Dynamics 365 / CRM received a lot of attention, and sparked writers, podcasters, tweeters and commenters around the world to give feedback, yell at me, agree with me, or simply continue the discussion both publicly and privately.
I have received virtual hugs and probably lost quite a few followers.
I really enjoy following and participating in the discussion, and one comment I got today from Anthony Ellis (read it here) inspired me to write a follow-up article. So here it goes.
Continue reading “Managed or Unmanaged solutions – a hot case still slightly open”
If you have problems shifting gears in your car, you don’t call Volvo to say “Hey, I don’t like how this gear shifting thing works, so I’m just going to use reverse and drive backwards from now on.”
What you probably do is call them to say “I’m having trouble shifting, you need to fix the problems or show me how to use it properly.“
Ever since Microsoft introduced the Solution platform with Dynamics CRM 2011, there has been an ongoing and never ending discussion about whether to deploy managed or unmanaged solutions.
I can’t say I can end the discussions or solve all problems. But I will try to convince you – there is no discussion.
Continue reading “Case closed: Managed or Unmanaged solutions in Microsoft Dynamics 365 / CRM”
If you want the full story – these are the articles describing the background and technology behind our tools:
Part I – Background and how our DevOps tools evolved before we knew about it
Part II – Automation of the build and deploy process using custom VSTS Build Tasks
Part III – Demo of complete build and release definitions taking you from A to Z
Part I – Background and how our DevOps tools evolved before we knew about it
Part II – Automation of the build and deploy process using custom VSTS Build Tasks
Part III – Demo of complete build and release definitions taking you from A to Z
After the first two articles we have now got a handful custom VSTS Build Tasks to help us take the build and deployment automation all the way. This final article demonstrates how we do that with VSTS builds and releases. Finally raising the questions of why we did all this and where to go from here.
Below is a sample of a full build process that not only builds and packs a new CRM solution, but updates the individual assemblies and webresources in DEV environment, exports solutions and data, and then publishes the files exported from DEV together with Shuffle Definitions and Package Definition, which is the resulting build artifact.
Continue reading “Build and Deploy Microsoft Dynamics 365 projects using VSTS – part III”
Part I – Background and how our DevOps tools evolved before we knew about it
Part II – Automation of the build and deploy process using custom VSTS Build Tasks
Part III – Demo of complete build and release definitions taking you from A to Z In the previous article I described the background of our struggles with moving configuration data and later scripted export and import of solutions and the CRM Deployer tool. This article takes these features to the next level by packing those and some other missing features into custom VSTS Build Tasks.
We now had the tools we needed to automate the central parts of the build/deploy process. But it still involved lots of manual or script based steps. To describe it simply, the following steps were required to produce a full deploy of a Customer Solution (CS) that has a prerequisite in one of our Product Solutions (PS), assuming we wanted the latest available code and customizations for both PS and CS.
Some of the steps above would be possible to encapsulate a bit more with scripting or tailored tools, and some of them possible to perform using Microsoft’s Developer Toolkit, Jason Lattimer’s CRM Developer Extensions or Wael Hamze’s CI FrameWork. But with the legacy of our Shuffle and later the CRM Deployer, that both have well proven technology and still save us literally hundreds of hours every month, we decided to add the few missing pieces in our puzzle ourselves. Continue reading “Build and Deploy Microsoft Dynamics 365 projects using VSTS – part II”
Part I – Background and how our DevOps tools evolved before we knew about it
Part II – Automation of the build and deploy process using custom VSTS Build Tasks
Part III – Demo of complete build and release definitions taking you from A to Z My hope is that these articles will inspire you to take your delivery process to the next stage by implementing automation through CI and what is usually called DevOps. If you are already there, these articles should provide an alternative solution, which may or may not suit your needs today, but might be worth considering.
Back in the days of CRM 4.0 we started delivering systems that were based more and more on generic configurable functionality. The benefit of having an automated way of delivering and moving configuration data between CRM environments was becoming increasingly obvious. This was long before utilities like the Configuration Migration Tool, so we started to draw the blueprints to develop the functionality we needed. Basically, what we needed was to grab a bunch of data from a source environment to persist it in a file, and later push it into another CRM organization.
Continue reading “Build and Deploy Microsoft Dynamics 365 projects using VSTS – part I”
For us as an ISV this is a huge improvement. We can now deliver solutions that are completely “plug and play” and still leave a minimal footprint on the whole customer system.
There is however one thing that is still not possible to separate with enough granularity. To include the ribbon definition of an entity, you need to check the Include entity metadata checkbox. 
Unfortunately this also includes the entity display name, plural name, and all other “entity wide” settings such as Notes, Connections, Mail merge etc. The result of this is that if we include the Contact entity just to be able to add a solution specific button to the command bar, we must also include the entity settings.
When a customer has developed their own solutions, or got solutions from other third parties, we quite often face the situation where they have changed the name of an entity, e.g. Contact is renamed to Person. Now importing our solution to add this button to the contact command bar, will also change the name of the contact entity back to default, or rather to whatever it is called in our solution.
This could be solved by allowing a separate option for the RibbonDiff part of the entity definition when selecting components for the solution.
If you agree with this proposal, you can contribute by voting up this item on Microsoft Connect.
MVP Jukka Niiranen recently wrote an excellent article describing Solution Segmentation in Microsoft Dynamics CRM.
