We migrate from CRM desktop version to dynamics 365 cloud version.
I need to import buttons for entity. Can I export them from the old version by solution and import them to new version of CRM as an unmanaged solution? Please explain the flow I should follow. Thank you!
P.S Preferable via XRM toolbox
Do you mean you crm is been moved (migrated) from OnPrem to OnLine(cloud).
If you are migrating, it will contain your custom buttons as well. you do not need to export and import. But if you wish to explicitly move some buttons only you can do so with solution import and unmanaged as well.
If you want to export your Ribbon with buttons etc then you can simply ensure the components are including within a solution that you export from your OnPremise environment to Online.
Depending on your OnPremise version you may have to make some changes for this to work fully in the new UCI interface.
Just add in existing components to your main solution you are wanting to use for the migration, it will be under Client Extensions, Application Ribbons. You can also add the sitemap from here too if required.
Related
In MS Dynamics CRM how do we register a plugin or a workflow as part of a solution? whatever i register through registration tool, just goes to the root solution of the system.
Expanding on what #Henrik said, the process would be as follows.
For the sake of this example, let's assume you have a single assembly (dll) with two plugins and each needs two steps.
Register the assembly as usual with the Plugin Registration Tool.
For each of the two plugins, register the two steps they require. This should leave you with four in total.
Leave the Plugin Registration Tool and go to your solution in CRM. You will see two sections there: Plug-in Assemblies and Sdk Message Processing Steps.
You will need both of these to fully register a plugin with your solution.
Go to the Plug-in Assemblies section and use the Add Existing button. This will bring up a standard lookup dialogue that will let you select your assembly. Add it.
Next, go to the Sdk Message Processing Steps section and use the Add Existing button to add any plugin steps you want as part of the solution.
That's it. Your assembly, plugins, and steps are now part of the solution. Any step images that may exist are automatically added as part of the step so no need to worry about them.
One caveat though is that assemblies must be stored in the database and not as files for this to properly work. There is no specific limitation on sandboxed plugins (unless deploying to CRM Online) but using those would simplify solution deployment.
Finally, this walkthrough which was taken from the How To button in a solution.
Walkthrough: Register a plug-in using the plug-in registration tool
As for workflows, they need to be added in the Processes section of a solution. This section will cover workflows, dialogs, business process flows, and actions. As before, use the Add Existing button.
There is no direct support for adding plugin assemblies or plugin steps to solutions when registering with the Plug-in Registration Tool.
Your plugin steps and assemblies will always be present in the layer of unmanaged customizations ("root solution").
You can use the Plug-in Registration Tool as usual and only later manually add your assembly and steps to the relevant solution(s).
I am attempting to migrate from an on-premise installation of TFS 2012 to Visual Studio Online. I have a handful of projects that have been in existence since TFS 2005 and have been upgraded/migrated up to 2012. Only one of those projects has any significant work item activity that I really need to maintain.
That project is using the MSF for Agile Software Development 6.2 template. I have never made any customizations to the template to my knowledge over the years. However, since it has been upgraded / migrated I am not surprised that the template is causing the OpsHub utility issues.
For every Work Item Type in the project, the fields 'Area Id' and 'Iteration Id' show as red errors on the validation screen of the tool for this specific project.
I have already tried the solutions suggested here, but it seems to have made no difference whatsoever. The template on VSO is MSF for Agile Development 2013.3. After looking at the WIT definition files in that template I can see that there is no 'Area Id' or 'Iteration Id' fields (or 'AreaID' or 'IterationId' for that matter) defined. However, in the 6.2 templates that field is specifically defined.
I am sure this has something to do with those being System defined fields and no longer needing to be defined in the individual work item templates or something of that nature. The fields cannot be deleted because they are System fields.
In any case, I have not been able to find a solution to this problem so that I can complete running the OpsHub tool to migrate this main project over. Any help would be greatly appreciated.
As an aside, every one of my projects are showing 'Template Customization or Template Mismatch' errors. For the meantime, I am just trying to resolve the issues with this one main project. I may be able to forego migrating the Work Item Data for some of the other projects.
Thanks in advance!!!
In the move from 2008 to 2010 Microsoft changed a number of the built in fields. These fields do not appear in the template, but if you export the work item type from the instance of the process template you will see them.
Effectively an upgraded server has built in fields that never changed and the OpsHub tool craps out on fields that it should be ignoring.
The only solution, bar OpsHub fixing it, would be to try and change the field names to match what is expected.
You can use the witadmin.exe to make the change.
I have a local Sitecore instance where I made changes involving both code and the creation of a new sublayout.
After deploying the code I can see on the new environment the usercontrol (.ascx) file associated to the sublayout, but the corresponding item does not appear and cannot be used.
If I attempt to recreate the usercontrol, it tells me that the file already exists, and due to my lack of experience with the platform I found myself unable to import it.
What would be the optimal way to proceed?
To deploy your new sublayout correctly you should create a Sitecore Package. This is basically a zip file that allows you to move both items and disk files between Sitecore instances in a controlled manner. For basic installs of Sitecore, where you have not added any specialised tools, it is generally the preferred way to move resources between servers.
The "Package Designer Guide" on the Sitecore Developer Network will give you information about how to use the Sitecore UI on your development site to create a package containing both the Item(s) and the file(s) for your sublayout:
http://sdn.sitecore.net/upload/sitecore6/65/package_designer_admin_guide-a4.pdf
Once created, this package can then be imported onto whatever other servers you want to deploy your sublayout to.
-- Edited to add --
Derek Hunziker's answer makes a good point: As well as the basic Sitecore behaviour there are third party tools available which can enhance and extend the deployment experience if you wish. As well as Hedgehog TDS, you might also consider:
The "Sitecore Rocks" extension for Visual Studio allows the creation of packages from within the
Visual Studio UI. This tool is free to use. (https://visualstudiogallery.msdn.microsoft.com/44a26c88-83a7-46f6-903c-5c59bcd3d35b/)
There are also a variety of open source tools - Sitecore Courier is one example: (https://github.com/adoprog/Sitecore-Courier) This is designed to help automate deployment between Sitecore instances.
Both TDS and Courier are most suited to regular deployments, such as those during ongoing development cycles, since they both include automation to help decide what gets deployed. The standard Sitecore UI and the Sitecore Rocks extensions for package creation are better suited to ad-hoc deployments, since you generally pick the things to deploy manually.
A common best practice is to deploy your items along with your code using Team Development for Sitecore. This eliminates the need to create Sitecore packages every time you want to move items between environments, which in turn reduces issues caused by human error. As an added bonus, the items that you own as a developer (such as Templates and SubLayouts) can be checked into source control.
Full disclosure: I work for Hedgehog Development :)
Just stumbled upon this question today:
"Is there a way to know that MPP published to the project server is not created using a template available on the server?"
Basically this comes from the point that how to find out compliance of the project plans to the standard templates.
I am not aware how it can be done?
Actually there is no way to identify by one field that this project was created using that template.
You may assume that by Enterprise Project Type, but again there is a way to change EPT for existing project.
The only way I know is to compare a template and a project by tasks, by structure, etc. it works like finger print recognition: you select several points which the most probably tell that the project was created from the template.
The worst case I can imagine: a user creates a project by a template and after that removes everything from the project. Formally the project was created by the template but in real there is nothing from the template left in the project.
We've decided to create a custom bootstrapper for our deployment solution. We are currently re-writing and re-designing our deployment strategy for all of our products. Sadly, none of us are deployment experts.
Here's what we have so far:
A. The MSI packages will be authored in InstallShield. We will use whatever feature Installshield offers (IIS integration, COM registration, Registry, etc). The dialog's created by InstallShield will not be used (that is what the bootstrapper is for). The MSIs will be installed silently.
B. Whenever we need to write CA's for stuff that InstallShield can't handle, we will be writing them in managed code (C#) using DTF. We will be creating a "Custom Action Framework" that will "standardize" how we use custom actions.
C. We will create a custom bootstrapper (the "setup.exe") in C# to "handle" the installation.
We have decided to go with a multiple MSI approach and use MSI transaction to "chain" the installation from the boostrapper (inspired from Office 2007 installer)
The boostrapper that we are envisioning to create is inspired from Visual Studio's and SQL Server's bootstrapper. The boostrapper will be responsible for the following:
Prerequisite installation: Each application require a pre-requisite. These pre-requisites are listed in an XML file placed on the same folder as the MSI (inspired from Office 2007 installer) along with other metadata. Depending on current state of the system, the boostrapper will decide which pre-requisite to be installed or not.
Feature selection: We are planning to structure the "internal" MSI's feature in such a way that it will not be appropriate to be displayed right away to the end-user. We will have feature labeled as "Core_Files", or "Vista_Only" or "64bit_Only". Depending on the metadata on the XML file (on item 1) and the target system, the bootstrapper will be responsible in "populating" a "feature tree" that the user can customize (also inspired from Office 2007 bootstrapper).
Pre-installation Checks: The bootstrapper will be responsible in checking if the system is ready to receive the installation. For instance, if a machine needs to reboot prior to installation or if the user needs to manually install a service pack, patch or a windows component. Anything that needs to be done that needs user intervention should be displayed here. Think of it as a check list (a listbox) with checks and exes. (Inspired from SQL server's bootstrapper). The "rules" will be written in C#.
Application Configuration: For application that needs to be "configured" prior to installation. These "parameters" (user configuration) will be passed to the respective MSI via MSI Properties.
Actual Installation: The bootstrapper will then perform the installation. Proper "transaction" should be observed when necessary. All "products" that should be grouped together shall be displayed as one product in Add/Remove Programs (by messing with the ARP entries). Also, proper progress shall be reported by each MSI being installed.
-- That's what we have so far.
I think there are a couple of out-of-the-box solutions for creating a custom bootstrapper like dotNetInstaller and BMG. We've look into it but it's not as flexible as we've hoped. There's also BURN but we're not sure if it's ready for primetime.
So here we are... we've decided to create our own custom bootstrapper.
Question:
Are we crazy? Shouldn't we be creating our own bootstrapper? Which ideas listed above are not realistic? Is there a better approach?
Any input regarding our situation will be greatly appreciated. Also, if you have any questions, please don't hesitate to ask.
Frankly, Burn isn't going to be done for at least a year. You already have InstallShield and IMO it has the best off the shelf bootstrapper currently available. I'd scope your requirements back and make it fit the box. Pretty much everything I read from you can be done using InstallShield if you learn to push it to it's limits.
I would go for Burn anyway or some already existing solution.
I'm sure that after some time you'll face new problems that you can't now really imagine.
If you face them, that means that Burn's developers have already faced them and probably got them solved. If not, Burn has a large community that will fix the potential bug faster than you.
Focus on the software you're developing, not on writing installer/bootstrapper.
If I were in your shoes, I would give a burn a try. I'd get me a couple of days and see if it meets my requirements.