Microsoft Dynamics CRM Team Blog: Web Resources Generated During Upgrades: Don't Ship Them!

[Blog bot]

Источник: http://blogs.msdn.com/b/crm/archive/...ship-them.aspx
==============

Since Microsoft Dynamics CRM 2011 shipped, it has been common practice for ISVs to upgrade their development organizations from CRM 4.0 to 2011 so that they can ship their customizations via solutions. After upgrade, most of you may have already noticed that some newly upgraded orgs contain web resources in the default solution that were generated by the upgrade process (such as Opportunity_main_library.js or contract_ribbon.js).

This short write-up can be summarized in a few words: don't ship these auto-generated web resources in your solutions. I'm going to talk about the problems this may cause, the consequences, and a recommendation in managing these web resources.

What happens during upgrade?

Web Resources is a new feature introduced in Microsoft Dynamics CRM 2011 and one convenience it provides (among many) is it decouples images and JavaScript code from the components that require them. For example, before CRM 2011, client side scripts used to live in FormXml data. This can be painful to maintain. If the JavaScript code is used in different forms, updating it will require updating all forms that have it. With the web resources feature in place, once the web resource is updated, the change will be reflected in all the forms and other components referencing it.

During server upgrade, the system goes through the customizations and does the following:

Action

Generated Web Resource Name Pattern

Example

Wraps the entity icons into new web resources and updates the entity metadata to point to these icons

Icon[Entity Name][Icon Size]

IconNew_FooLarge

Pulls the JavaScript code off the customized entity forms and into new web resources and updates the FormXml to reference the JavaScript library. This is done per entity.

[Entity Name]_main_library.js

Account_main_library.js

Pulls the JavaScript code off the customized ISVConfig and into new web resources and updates the ribbon customizations to reference the JavaScript library. This is done for the main application ribbon and all other entity ribbons.

[Entity Name]_ribbon.js

quote_ribbon.js

If they all work fine, why not ship them?

The main reason why it is strongly recommend NOT to ship these web resources is that their generated names, particularly the JavaScript libraries, are not unique and could cause a name collision! Here are two scenarios that illustrate the consequences:

Scenario 1: Multiple managed solutions installed in a fresh CRM 2011 organization - 2 managed solutions containing web resources having the same name cannot coexist in a single organization

1. ISV1 upgrades his CRM 4 server to CRM 2011. He has client side code running in the form events of Account entity, hence Account_main_library.js was generated post upgrade.

2. ISV2 (second ISV) does the same thing. Note that ISV1 and ISV2 are totally independent ISVs and their customizations are totally different. However, they now both have Account_main_library.js

3. ISV1 and ISV2 both create managed solutions and upload them to the Dynamics Marketplace

4. Customer1 sees both solutions and decided to try both. In any order that customer imports both solutions, it is doomed to fail on the second import with the following error: "Cannot import component WebResource: a810bab4-8477-e011-ac11-00155db059be. The publisher of the solution that is being imported does not match the publisher of the solution that installed this component."

Scenario 2: Converting customer's own code to managed - it should not be assumed that these web resources do not exist in the customer's org. Their own customizations will be deleted and replaced with yours.

1. ISV3 upgrades his CRM 4 server to CRM 2011. He has client side code running in the form events of Account entity, hence Account_main_library.js was generated post upgrade.

2. Customer2, a Microsoft Dynamics CRM 4 user, upgrades to CRM 2011. Customer2 has customizations done in-house. After upgrade, Account_main_library.js was generated as well.

3. ISV3 ships managed solution, Customer2 buys it and installs

4. ISV3's solution overwrites Customer2's Account_main_library.js

What should we do to prevent this?

Simply move all contents of auto-generated web resources into new ones with unique and more descriptive names. Don't forget to test before shipping to make sure that all references to the new web resources are updated.

Cheers,

Greg Alicbusan







Источник: http://blogs.msdn.com/b/crm/archive/...ship-them.aspx