We offer multiple packages with features for our clients with Microsoft Dynamics CRM.
Is there a way where we can publish our sollutions with our modifications for certain entities without overwriting the form layout that already existed.
How should we organise our sollutions so there will be no conflicts within the entities in our sollutions nor with the entities that were already modified by our clients where we want to install our sollution?
now we have to modify most entities manualy...
I hope you have some experience you want to share with us.
We broke up each section of our project into solutions. For example, entities, reports, plugins, etc.
This allowed us to deploy bits and pieces of our project as we went along (moving from dev -> test -> production).
You can't break out pieces of entities (or exclude things like the forms), but you could export the existing solution, make your changes and then re-import (as a manage or unmanaged).
There's a really good diagram here under "Conflict Resolution".
Related
I'm working on Dynamics CRM online 2016, the requirement is to create a new entity field inside all the entities that we have in a third party vendor solution (unmanaged).
I'm wondering what is the way to solve this requirement. Because that Solution is huge and it has more than 20 entities.
The third party vendor told me that I have to create a new solution and add all the entities to this new solution and then add the field in each entity. I guess that they want to keep separately new configurations and customizations.
However, my boss told me; you are free to choose working in that solution (third party solution) or to create a new one.
I think it's better and easier to work in the third party solution (because at the end, when I need to migrate these changes to our other instances, I will export and import this solution), however I'm fairly new in Dynamics and in terms of migration process, I do not know what is the best approach.
I really appreciate any suggestion from you guys.
It is fine to work in the third party solution, which I would recommend. If for some reason you prefer, it is also fine to work from a new solution you create.
The key is to understand that solutions do not really matter: The entities themselves exist in the layer of unmanaged customizations of the system. Solutions are simply containers that point to these unmanaged entities.
No matter how many solutions you have that point to a given entity, any modification made will be made directly to the entity.
Since you are using CRM 2016 you have the possibility of choosing which fields from an entity to include in your solution. This could be used if you for some reason really want to have one solution with and one solution without your newly added field.
MSDN has the following note about having multiple solutions with shared components:
Some components can be included in more than one solution as long as
any changes that were made to them are compatible with all other
solutions that use them. It is important that all the solutions share
the same solution publisher. If the solution publisher is not
identical, organizations will not be able to install more than one of
your solutions.
I am starting to do a lot of sharepoint development lately, and some of the things that I have done and I dont like is to use sharepoint designer directly for things like pagelayouts, lists definitions, master pages, etc.
From my point of view I think its more organized to do everything in Visual Studio. In that way you can connect each solution to a source control database and deploy/retract/upgrade easier with scripts.
My idea is to create a vs solution like this:
1. One for list and content type defintions.
2. One for webparts.
3. One for branding
but maybe this approach has any disadvantage, what other approaches are you using?
The real answer is going to be: it depends.
I do not think there is one best way to organize a Visual Studio solution or SharePoint solution packages. In the end, you need to find what works best for your organization and go with that.
The only guidance I have seen is from the SharePoint Online documentation:
If the development team is designing a solution that requires more than 10 WSP files, the team should reconsider its architecture. It is difficult to manage and deploy so many WSP files within a single deployment window, and the solution risks rejection because of the complexity for SharePoint Online of managing it.
A large number of solution packages (WSP files) that need to be tracked and managed pose a challenge for deployment. The more solution packages in a customization, the greater the possibility that something will not be installed correctly, the longer the solution will take to deploy, and the easier it is to mix incompatible versions of solution packages. We recommend that customers scrutinize their deployment plans and keep the number of solution packages to the minimum number needed for the project. Keep in mind that a solution package can contain several features, so there is no necessity to have one solution package for each feature.
And I would agree with this. You seem to be outlining 3 Visual Studio solutions and/or SharePoint solution packages for what really are 3 Features within a single SharePoint solution package.
I tend to create one Visual Studio solution for each project. For a very large project, that single Visual Studio solution might contain several projects where each represents a SharePoint solution package.
For Farm solutions, each SharePoint solution package will contain a number of Features and files that are all related in terms of functionality or application. If two or more SharePoint solution packages share common Features, I will put those shared Features into a separate solution package.
Sandbox solutions tend to be much smaller than Farm solutions. While my Farm solutions usually represent an application, my Sandbox solutions are more focused to solve one particular issue. So my Sandbox solutions usually only contain one Feature that does not rely on other custom Features or solutions.
As I said in the beginning, I do not believe there is one hard or fast rule. It is usually determined by the preferences and style of a particular development team. Try a couple different ways in the beginning and eventually you will find what fits your team best.
we are currently working on a specific CRM development. As part of this development we are working with a different supplier who have provided us with a 'core' managed solution, a toolkit of sorts. This toolkit contains a number of entities/web resources etc but crucially contains the case and contact (renamed to customer) entities. As part of our development we need to extend these entities by adding attributes/amending form layout etc for both these entities.
should i create a new unmanaged solution - select add existing - choose the customer entity.
I can then make my changes (new attributes, form layout changes etc)
I then publish my unmanaged solution as a managed solution to import into a UAT/Prod environment.
Would this approach work ok?
What if the supplier make changes to their core entity and provide us with an updated release? what happens then or what should i do?
There are a couple of attributes (title and ethnicity) that are part of their entity but i need to work of global option sets so i have create 2 new attributes and these are displayed on the form in place of their's. I have not removed theirs but could this cause issues?
any help appreciated
chris
You are right on in the first paragraph, you would need to create a new solution and amend their entities. When you import their changes it will add on any additions to those entities. Importing customizations should never remove anything, you have to do that manually. Although unlikely, it is possible that the vendor may release a new version that requires you to roll back your customizations and reinstall it. In this instance you would need to come up with an upgrade plan and take into account all of the dependencies of the system.
I would imagine that those attributes would be dependencies of their managed solution and suspect that CRM won't let you delete them. If you are able to delete the fields and recreate them using global option sets there should be no issues so long as you use the same picklist integer values and schema names for the fields. Microsoft CRM basically copies all of the global option set values to the entity that you put them on so externally there is no difference between the standard and global option sets. Obviously a future upgrade by the vendor may force you to delete it all and recreate everything again manually (or via code using the CRM web services), but that is something you would have to take into account.
What the disadvantage here is, is if you create an entity, attribute or relationship in Dev and deploy to forward facing entity, if you then remove that entity, attribute or relationship in Dev, you must "uninstall" that solution. Of course, if you have critical data in that forward facing environment, it is gone when that solution is removed. So, if you deploy from Dev to forward facing, if in the future you no longer need that entity, attribute or relationship, although you can remove it from forms, it will always remain an artifact in your system. This is a disadvantage when working with Managed solutions.
I am trying to sort out a best practise approach to organising solutions and more specifically what should be included in the 'base solution' or 'library solution'.
The SDK says the following:
Solution Libraries For an ISV with multiple solutions or a large
enterprise deployment, it is expected
that many solution components will
have to be shared. The best ways for
solutions to share components is to
create solution libraries. You create
a solution library by creating an
unmanaged solution in a separate
organization and then package those
components into a managed solution.
Install the managed solution into
another organization and let
developers reference these shared
components from the solutions they
create.
The Microsoft Dynamics CRM Solutions
Framework lets you build layers of
solutions that depend on each other.
Typically, you create a solution
library representing a ”base”
solution. Other solutions can be built
on top of this base solution.
What components should ideally be placed in the base/library solution? Core business entities and option sets? Core functionality and workflows?
There doesn't seem to be a great deal of guidance on the dynamics documentation.
If you have any functionality that you plan to share across multiple organizations that will be revisioned separately from the rest of your organization, then I would consider putting that in a separate solution.
For example, say you have multiple regions in your business that will each have their own CRM organization, but each of them uses a standard way of scoring and assigning leads. In this scenario, I'd create a solution that encompasses that functionality and install it on each organization, and that way when the process changed, the same solution could be pushed out to all the orgs and everyone would get the same changes.
Another possibility would be a common set of JavaScript libraries and plugins that you'd use across multiple organizations, maybe for things like autonaming or autonumbering records, or some custom business logic validation. That way if you found any bugs in them, you again could push the same changes to all orgs.
If you don't have multiple CRM organizations or you're not an ISV, I wouldn't bother with solutions. They're a great leap forward for CRM, but it's definitely the first pass around, and there are some quirks and headaches to working with them.
So, maybe I'm a bit old-school, but when we created websites in the past, we'd develop the site on a development server, then publish or promote the pages and files to the production server. This has always seemed to be a good way to go so that users didn't see messed up pages or (God forbid) a downed server because one of us screwed up.
But it doesn't seem that Microsoft had this idea in mind when they created SharePoint...at least, I haven't been able to find a way to do this in the infrastructure as it's defined.
Does anyone know if there's a management strategy for SharePoint development? I've read online that we can make a backup of the development environment and restore to the production server. That might work the first time, but any updates to the production server can't do that without risking data loss on the production server. I've seen some tools out there for migrating list contents, pages and documents from one server to another--although, admittedly, I've not yet investigated them.
But, another concern of mine is custom content types. It seems that once a list is using a content type, you can't update it without deleting the items from the list, disassociating the content type, and reassociating the content type. Shouldn't there be some way to UPGRADE a content type?
Anyway, if you have any suggestions for any of these current dilemas, I would LOVE to hear from you.
Thanks in advance,
Dan
Thank you for your quick reply.
We already have several features created for our site and a solution package bundling features directed at the fundamentals (content types, columns, etc), and another solution for features having to do with branding (page layouts, master pages, etc.)
But it seems like this is a one-time-shot...basically, it gets our server set up, right? Once people have started using the production environment, we're going to have documents, pages, list items all existing in our content database, and it'll be impossible to update things like content types, columns.
Features you have to deactivate and uninstall before you can install and activate the new feature, right? I've seen a Version property on the feature definition, but as near as I can tell, this doesn't do anything. Solutions seem like they can be upgrade by incrementing the version number, but it doesn't seem to modify things like content types and columns--especially if they're in use. Plus, I'm not sure how extensive the upgrade with solutions is.
There's precious-little documentation out there for this sort of thing. It seems like everything I'm reading is how to get your SharePoint server set up initially...not managing it long term.
Do you have any advice or suggestions?
Thank you all for your suggestions.
But we've been working on this site for over a year now. I'm pretty confident that we're already setup according to what most of you are recommending. We already have several features that install things like content types, columns, master pages, page layouts, and workflows. Most of these features are contained within solution packages. We have all of our development environments set up as VPC servers.
So, I have the initial deployment pretty much set. What I'm REALLY hoping to find out is how I can upgrade things like content types and columns and stuff down the road. Is it possible to change content types once they're in use? Because it doesn't seem, based on my initial testing, that this is possible. I'm not to worried about the assemblies because it looks like they swap out just fine, but the only way I've gotten a content type updated is by deleting any items referencing them (i.e. all the pages in my pages library), removing the content type, then re-adding it.
Do any of you know if there's a way to update a content type AFTER the initial deployment? ...when users have already created items based on the content types we've already deployed?
(The other part of my question was actually moving existing pages from the development server to production, but I can live without that. My major worry is the content types.)
The best way to go is developing with features. Once the features are done, you ca deploy them with Solution package (called WSP).
The only thing left to do is to reactivate those features. That way, you can progressively roll-out new features without having to do everything in production.
WSPBuilder is an application that helps you build WSP.
For automating all of this... good luck. There is a lot of work involved.
UPDATE:
Deploying Content Types and Columns are tricky. Once the website has been created, you can't update them anymore through features. You need to go through the code and recursively go through all the sites and modify the specific content type that match the name.
We've tried and it's not possible to do that normally with features. This need to go through something I call "deploying with code".
You really really need to define your content types using a feature because that way each content type will have a set GUID and will be stored in the database using the same name. This becomes important when running CAML queries over the site and there are a few other little gotchas when content types are created "will nilly" if you will.
I prefer STSDev for rolling out solutions using custom content types.
There are two ways to edit pages on the server. You can define the page library to have major and minor versions. This allows editors to edit the page and a defined publisher to publish them. This is good on an internal site, but is not recommended for a public facing site.
For a public facing site you will need to use Content Deployment
I cannot stress enough that before going ahead with a production release you make sure you have features for the content types.
As mentioned here, Chris O'Brian has a post saying that you should not use features unless necessary. One of his reasons is that it slows developement.
I disagree with this. Developement is slower if you are unfamiliar with features, but once a level of knowledge is reached, it is not a major factor.
Do listen to him about the backup and restore method of moving the content.
If you do that, all mess in the content types and fields and webs you may have created during developement (for me that is always quite a bit) will be moved to your production site.
Instead of having a nice clean site where everything is consistent, you will end up with little bugs and some areas of the site behaving differently to others simply because of old development cruft.
I recommend taking a look at Chris O'Briens most recent post, and his great Content Deployment Wizard: it's not all about Features!
Maxim is right in that most items should be deployed via features that are wrapped in solutions (WSP files). Your strategy should be to make sure your solutions and assemblies are broken into related bits of functionality. This is also beneficial in that features can be isolated at certain levels like sites and webs. Feature activation code, deactivation code and feature stapling should be used when updating any content updates. Content deployment can also make sense.
Once thing to remember is that if the updates are only in code then the assemblies can be updated without requiring the feature to be reactivated or the solution retracted and redeployed. All that is required is the Application Pool to be reset.
Microsoft has a couple articles on Dev environments and you can Google many others who recommend environments. We do development on virtual machines and deploy most items to an virtual integration server. Once we smoke test it we then deploy our solutions to QA so on and so forth. The benefit i sthat features and solutions are easy to retract. Once it goes out to production it should be thouroughly tested.
Developing in SharePoint has it's issues, that goes without saying, but so far I have found that the benefits outweight the problems.
Team-Based Development in Microsoft Office SharePoint Server 2007
We developed a custom solution which would update content types and fields for a Site Collection. Underneath the covers, through code, SharePoint allows us to modify the Fields as well as values in the Fields and Site/List Content types.
For moving the actual content from QA to Prod we use Echo