My team and I are using the SolutionPackager tool from the CRM SDK to being able to version CRM 2011 solutions.
We’ve come through many problems; for example the order in which the languages are exported depends on each organization, another problem was the entity type code of each entity also depends on each organization, etc., etc.
In my team we also use the same kind of organizations UR (Update Rollup) 6, each develop have its Virtual Machine to develop, all VMs have the same configuration, the same languages packs installed, I mean, we also work in the same environments.
But now we are facing another problem that we cannot figure out. From one organization, let’s say OrgA, I export a solution, apply the solution packager and then from one of our entities I get an XML like:
<attribute PhysicalName="OrganizationId">
<Type>lookup</Type>
<Name>organizationid</Name>
<LogicalName>organizationid</LogicalName>
<RequiredLevel>none</RequiredLevel>
<ImeMode>auto</ImeMode>
<ValidForReadApi>1</ValidForReadApi>
<IsCustomField>0</IsCustomField>
<IsAuditEnabled>1</IsAuditEnabled>
<IsSecured>0</IsSecured>
<IsCustomizable>1</IsCustomizable>
<IsRenameable>1</IsRenameable>
<CanModifySearchSettings>1</CanModifySearchSettings>
<CanModifyRequirementLevelSettings>1</CanModifyRequirementLevelSettings>
<CanModifyAdditionalSettings>1</CanModifyAdditionalSettings>
<ReferencedEntityObjectTypeCode>1019</ReferencedEntityObjectTypeCode>
<LookupStyle>single</LookupStyle>
<LookupTypes />
<displaynames>
<displayname description="Organisations-ID" languagecode="1031" />
<displayname description="Organization Id" languagecode="1033" />
<displayname description="ID d'organisation " languagecode="1036" />
<displayname description="ID da Organização" languagecode="1046" />
<displayname description="Id. de la organización" languagecode="3082" />
</displaynames>
<Descriptions>
<Description description="Eindeutiger Bezeichner für die Organisation." languagecode="1031" />
<Description description="Unique identifier for the organization" languagecode="1033" />
<Description description="Identificateur unique de l'organisation" languagecode="1036" />
<Description description="Identificador exclusivo da organização" languagecode="1046" />
<Description description="Identificador único de la organización." languagecode="3082" />
</Descriptions>
</attribute>
The problem is, that from another organization, let’s say OrgB, I export THE SAME solution and when I go to the XML for same entity as before, that file does NOT contain the line
<LookupStyle>single</LookupStyle>
The solution from both organization IS THE SAME, the configuration is also the same, so my question is why when I export the solution each VM/Organization generate a different XML file?
We've experienced the same glitch in our project. I think the problem is that single is a default value of <LookupStyle> (in other words <LookupStyle/> == <LookupStyle>single</LookupStyle>. So it might appear from the UI that the configuration of both organization is the same (in fact it is) but the data stored in the database are different. Unfortunately export of a solution takes into account only what is stored in the DB.
I'm quite sure that exporting/importing solution with a given entity won't help. What might help is resaving the entity.
Btw - I found this approach of comparing packages very useful. Only I use BeyondCompare...
Related
We want to create lists in our tenant on developer site. We want do develope it in our developer site and than deploy on client side using package (maybe sppkg).
We tried to create lists in visual studio 2017 using Sharepoint Add-in and in Visual studio code by using SPFX framework, with tutorials based on microsoft spfx documentation link - https://learn.microsoft.com/en-us/sharepoint/dev/spfx/web-parts/get-started/provision-sp-assets-from-package.
<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
<Field ID="{060E50AC-E9C1-4D3C-B1F9-DE0BCAC300F6}"
Name="SPFxAmount"
DisplayName="Amount"
Type="Currency"
Decimals="2"
Min="0"
Required="FALSE"
Group="SPFx Columns" />
<Field ID="{943E7530-5E2B-4C02-8259-CCD93A9ECB18}"
Name="SPFxCostCenter"
DisplayName="Cost Center"
Type="Choice"
Required="FALSE"
Group="SPFx Columns">
<CHOICES>
<CHOICE>Administration</CHOICE>
<CHOICE>Information</CHOICE>
<CHOICE>Facilities</CHOICE>
<CHOICE>Operations</CHOICE>
<CHOICE>Sales</CHOICE>
<CHOICE>Marketing</CHOICE>
</CHOICES>
</Field>
<ContentType ID="0x010042D0C1C200A14B6887742B6344675C8B"
Name="Cost Center"
Group="SPFx Content Types"
Description="Sample content types from web part solution">
<FieldRefs>
<FieldRef ID="{060E50AC-E9C1-4D3C-B1F9-DE0BCAC300F6}" />
<FieldRef ID="{943E7530-5E2B-4C02-8259-CCD93A9ECB18}" />
</FieldRefs>
</ContentType>
<ListInstance
CustomSchema="schema.xml"
FeatureId="00bfea71-de22-43b2-a848-c05709900100"
Title="SPFx List"
Description="SPFx List"
TemplateType="100"
Url="Lists/SPFxList">
</ListInstance>
</Elements>
With SPFX we created webpart and in code we created 2 lists in elemnts.xml and schema.xml. Than we had problem with some content type IDs. So our problem is to create list by code. Can anybody give us advice what and how is best option to develope these lists?
Etc this two simple lists
Employee -name,surename
Vacation -employee, numberOfDays
Unfortunately, documentation for the XML is a bit hard-to-find. Here is an overview of what I've learned thus far working with SPFx:
Fields
Let's start by creating some Fields. If you want to create a SharePoint list, Fields would represent the columns of the list. The basic outline of a Field is as follows (note that the #1 through #5 are for reference purposes only, and should not be included in any final code):
<Field
1 ID="{DAFF97CE-C27D-4D27-9863-4422526CC395}"
2 Name="EmployeeName"
3 DisplayName="Name"
4 Description="Column for the employee's first name."
5 Type="Text"
/>
ID: GUID (Globally Unique IDentifier) for the Field. You need to generate one. Use an online generator such as this one - make sure it is uppercase, with hyphens, and with braces (reference). Visual Studio has a generator built-in, if you are using it.
Name: The Internal Name for the Field. This is the name that exists "under the hood". If you interact with the Field programmatically, this is the name you would use.
DisplayName: The Display Name for the Field. This is the name that is shown in SharePoint. It is usually for presentation purposes only.
Description: A text description of the Field. Useful for remembering what a field is for, but not important otherwise.
Type: This is the important one. It defines what kind of column you will create. As you have likely seen when creating columns in the SharePoint web interface, there are a lot of different types, such as "Single line of text", "Date and time", "Person or group", "Calculated", etc. The Type attribute directly maps to these allowed choices.
Types
The hard part is figuring out what the allowed values for Type are. Thankfully, these are documented in the Field element specification. Scroll down to the row for Type.
Examine the documentation for whether there are other required or optional attributes based on the Type you selected. For example, for a Number type, you can have extra attributes Decimals, Min, and Max. Below, we can specify that for Number Of Days, you can only pick a whole number, cannot take less than 1 day off, and cannot take more than 30 days off.
<Field
ID="{B34A7173-5AB7-4ABC-812B-EF8D0386498F}"
Name="NumberOfDays"
DisplayName="Number of Days"
Description="The number of days employee will take off."
Type="Number"
Decimals="0"
Min="1"
Max="30"
/>
List Fields vs. Site Fields
Once you have created the Fields, you have a choice to make: Should these fields be List Columns or Site Columns?
Fields that are entered into a schema.xml will become List Columns; in other words, limited to that List.
Fields that are entered into elements.xml will become Site Columns.
Keep this choice in mind, and keep the Field definitions you created. We will come back to them.
Lists
Now let's create a List Schema. You will not (and should not) have to create this thing from scratch - look at and copy-and-paste the boilerplate below into your solution (again, numbers on the left are for reference purposes only):
<List xmlns:ows="Microsoft SharePoint"
1 BaseType="0"
Direction="$Resources:Direction;"
xmlns="http://schemas.microsoft.com/sharepoint/">
<MetaData>
<ContentTypes />
2 <Fields></Fields>
<Views>
<View BaseViewID="1"
Type="HTML"
WebPartZoneID="Main"
DisplayName="$Resources:core,objectiv_schema_mwsidcamlidC24;"
DefaultView="TRUE"
MobileView="TRUE"
MobileDefaultView="TRUE"
SetupPath="pages\viewpage.aspx"
ImageUrl="/_layouts/images/dlicon.png"
Url="AllItems.aspx">
<XslLink Default="TRUE">main.xsl</XslLink>
<JSLink>clienttemplates.js</JSLink>
<RowLimit Paged="TRUE">30</RowLimit>
<Toolbar Type="Standard" />
3 <ViewFields>
<FieldRef Name="<FIELD_1>" />
<FieldRef Name="<FIELD_2>" />
<FieldRef Name="<FIELD_3>" />
</ViewFields>
<Query>
<OrderBy>
<FieldRef Name="ID" />
</OrderBy>
</Query>
</View>
</Views>
<Forms>
<Form Type="DisplayForm"
Url="DispForm.aspx"
SetupPath="pages\form.aspx"
WebPartZoneID="Main" />
<Form Type="EditForm"
Url="EditForm.aspx"
SetupPath="pages\form.aspx"
WebPartZoneID="Main" />
<Form Type="NewForm"
Url="NewForm.aspx"
SetupPath="pages\form.aspx"
WebPartZoneID="Main" />
</Forms>
</MetaData>
</List>
BaseType: This represents the type of list you want to create. See this documentation for the allowed values. Generic List (the type you would create if you clicked "Add Custom List" or "Create List" in the SharePoint web interface) would be 0, and is probably most common. Another common option is Document Library, which would be 1.
Fields: If you have chosen to create your Fields as List Columns, this is where you would paste your Field definitions. Field definitions added here will be automatically created in the list, when the list is created. (If you want Site Columns, leave the Fields as-is, and save your Field definitions for later.)
<!-- ... -->
<ContentTypes />
<Fields>
<Field
ID="{DAFF97CE-C27D-4D27-9863-4422526CC395}"
Name="EmployeeName"
DisplayName="Name"
Description="Column for the employee's first name."
Type="Text"
/>
<Field
ID="{AA4D083E-1B32-4AF5-B572-DA06B3996A94}"
Name="EmployeeSurname"
DisplayName="Surname"
Description="Column for the employee's surname."
Type="Text"
/>
</Fields>
<Views>
<!-- ... -->
ViewFields: ViewFields define the columns that will be visible in the View in which it is associated. (Playing around with Views is a more advanced topic for another post.) For now, ensure that you have a FieldRef for each Field that you add to your list. Make sure to specify the Internal Name of each Field. (Always do this, regardless of whether you want List Columns or Site Columns.)
<!-- ... -->
<Toolbar Type="Standard" />
<ViewFields>
<FieldRef Name="EmployeeName" />
<FieldRef Name="EmployeeSurname" />
</ViewFields>
<Query>
<!-- ... -->
Now you have a List Schema which defines everything you need to know about a List.
Note: If you want multiple different lists, you must create multiple List Schema files. Just copy-and-paste the boilerplate schema, and add modifications in the same way as above.
Elements
Finally let's tie everything together. elements.xml is where you tell SPFx every item you want provisioned.
To create a list, you need a ListInstance element. Here is the documentation. Below is an example of an elements.xml file (once again, the numbers on the left are for reference only):
<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
<ListInstance
1 CustomSchema="schema-employees.xml"
2 Description="List for employee name and surname."
3 FeatureId="00bfea71-de22-43b2-a848-c05709900100"
4 TemplateType="100"
5 Title="Employee Names"
6 Url="Lists/EmployeeNames"
/>
</Elements>
CustomSchema: Name of the List Schema file that we worked on earlier. In this case I have called it schema-employees.xml - you can name it whatever you like, just make sure the names match.
Description: A text description of the list. Not too important.
FeatureId: Recall that earlier in the List Schema we decided that we were making a Custom List with BaseType="0". A Custom List has a corresponding Feature ID, which must match the type of List created. See here for a list of feature IDs. Find the Feature Name for CustomList to double-check that the Feature IDs are the same. If you were provisioning another kind of list, such as a Document Library, you would have to come here to find the corresponding FeatureId.
Template Type: This is another part that must match the type of List created. See here for a list of template types. In this case, see that GenericList maps to a TemplateType of 100. A Document Library would be 101, etc.
Title: Visible title of the list, which will be shown in the Site Contents of a site. Not too important.
Url: This dictates the web URL where you will find this list. Usually, as you may have noticed while creating lists using the SharePoint web interface, Custom Lists are placed under /sites/YOUR_SITE/Lists/. The example above follows this convention, but you can set the URL to other values as well.
That's all for the ListInstance. Additionally, if you had decided to implement your Fields as Site Columns, elements.xml is where you would paste the Field definitions. Just make sure you paste the Fields before the ListInstance, because otherwise SharePoint will not know what Fields you are referring to (they would not have been created yet!).
<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
<Field
ID="{DAFF97CE-C27D-4D27-9863-4422526CC395}"
Name="EmployeeName"
DisplayName="Name"
Description="Column for the employee's first name."
Type="Text"
/>
<Field
ID="{AA4D083E-1B32-4AF5-B572-DA06B3996A94}"
Name="EmployeeSurname"
DisplayName="Surname"
Description="Column for the employee's surname."
Type="Text"
/>
<ListInstance
CustomSchema="schema-employees.xml"
Description="List for employee name and surname."
FeatureId="00bfea71-de22-43b2-a848-c05709900100"
TemplateType="100"
Title="Employee Names"
Url="Lists/EmployeeNames"
/>
</Elements>
Having specified the elements.xml, we have successfully created an XML definition for the Lists we want to create!
A Final Note
Don't forget that in order for SPFx to know about the schema-employees.xml and elements.xml, you must include them as part of a Feature definition in the package-solution.json. This is addressed in the tutorial linked in the original question, but I wanted to make note of it anyway.
thank you a lot for perfect info, it's what we are looking for!
You recommend copy and paste list definition i VS (or other IDE). I would to ask you is there some way to design lists with person, lookup, compute and another "advanced" columns and download XML schema definition to copy and paste into VS because I need on the end package solution to sppkg? It's because I find this way to much faster than code all in VS.
Thank you.
I am having problem in publishing my custom project in Acumatica ERP. It prompts me the following message.
Conflict control ID:phG_tab_Items#0_grid_Levels#0 from page
~/pages/so/so303000.aspx Validation failed.
Here is what my code looks like in the Invoices page (ScreenID: SO303000)
<Page path="~/pages/so/so303000.aspx" ControlId="2" pageSource="711Ft7m6F+foDk0z4+/8B">
<PXGridLevel DataMember="Transactions" ParentId="phG_tab_Items#0_grid_Levels#0" TypeFullName="PX.Web.UI.PXGridLevel">
<Children Key="Columns">
<AddItem>
<PXGridColumn TypeFullName="PX.Web.UI.PXGridColumn">
<Prop Key="DataField" Value="UsrContractID" />
<Prop Key="Width" Value="70" />
</PXGridColumn>
</AddItem>
<AddItem>
<PXGridColumn TypeFullName="PX.Web.UI.PXGridColumn">
<Prop Key="DataField" Value="UsrPhoneNumber" />
<Prop Key="Width" Value="70" />
</PXGridColumn>
</AddItem>
<AddItem>
<PXGridColumn TypeFullName="PX.Web.UI.PXGridColumn">
<Prop Key="DataField" Value="UsrSIMCardID" />
<Prop Key="Width" Value="160" />
</PXGridColumn>
</AddItem>
</Children>
</PXGridLevel>
</Page>
I have shortened the pageSource value for readability.
Since, I have another custom project as well, and got answer that that could cause this, I have no idea what changes should I do to make this work.
When you publish more that one customization project, the system merges the content of all projects into a single customization project. If different projects include customization for the same ASPX page, the platform tries to merge the changes. For example, the platform can merge different properties of the same control in an ASPX page.
On the Customization Projects form, you can specify an optional number (level) for each customization project, assigning the highest number to the most important change. The level can be used to resolve conflicts that arise while you are publishing customization projects if multiple modifications for the same ASPX page are merged. As a result, the customization from the project with the highest level is added to the merged project.
For more information on this topic, please check Acumatica Customization Guide
I don't know if it's the best way to do it, but here is what I did.
I copied the changes from the my one custom project to another custom project in the same page screen. And it worked!
This worked for now. But please let me know if there is better way to do this.
I have UML diagrams created long ago with JBuilder, a Java IDE apparently defunct since 2008. I am unable to download previous installers, as the product is not even mentioned anymore on the editor website.
The files are XML-based with the extension txvpck, here's an example of their contents:
<?xml version="1.0" encoding="UTF-8"?>
<nodeSet version="1.0">
<view uin="id5n25le5bftm2ge5bfvjng">
<property name="$metaclass" value="Package Diagram"/>
<property name="#__options" value=""/>
<reference df-class-name="reference" referencedUin="design:view:::idv3x1e5bftm2ge5bfvkxc">
<property name="$shortcutReference" value="true"/>
<property name="#__fqn" value="uml:package:MyProduct:src:com"/>
<property name="bounds" value="10,10,102,184"/>
</reference>
<property name="$defaultDiagram" value=""/>
</view>
</nodeSet>
Is there a way to open these files with another UML tool or library, and convert them to an usable format?
A while ago I also worked with Borland/Embacadero tools,... . Usually it is possible to open the UML files from one of those tools with an other one, and I expect that they still support those legacy files. So youcan open it with any newer version of a Borland/Emba tools that has integrated UML support. Maybe an professional edition, e.g, Delphi, would be sufficient to view your old model.
I'm trying to leverage Import/Export module to import taxonomies and taxonomy terms like so
<Orchard>
<Data>
<Taxonomy Id="/Identifier=Product-Categories" Status="Published">
<AutoroutePart Alias="eshop/categories" UseCustomPattern="false" />
<IdentityPart Identifier="Product-Categories" />
<TitlePart Title="Product Categories" />
<TaxonomyPart TermTypeName="ProductCategoriesTerm" />
</Taxonomy>
<ProductCategoriesTerm Id="/Identifier=Category-1" Status="Published">
<AutoroutePart UseCustomPattern="false" />
<IdentityPart Identifier="Category-1" />
<TitlePart Title="Test category" />
<TermPart Count="0" Selectable="true" Weight="1" TaxonomyId="/Identifier=Product-Categories" Path="" />
</ProductCategoriesTerm>
</Data>
</Orchard>
ProductCategoriesTerm when created through dashboard has default pattern
{Content.Container.Path}/{Content.Slug} ### my-taxonomy/my-term/sub-term
but importing terms makes them to use just {Content.Slug} ... How do I instruct AutoroutePart to use the default pattern? Tried UseCustomPattern="false" or exclude AutoroutePart with no effect it's just test-category instead of eshop/categories/test-category and won't regenerate even if if I set AutouroutePart to automatically regenerate when editing content and disable custom patterns and it won't revert to default pattern even if I try to publish it through dashboard.
Also it's mandatory to include "Count" for the TermPart when importing, does it affect anything? Sounds like something that should be dynamic and relevant only with export.
When importing taxonomy terms (and I guess any other part that has a container) it's necessary to specify Container for the common part. Without it Container for the part is null and therefore can't resolve {Content.Container.Path} in the alias pattern.
<CommonPart Container="/Identifier=Product-Categories" />
Or if it's nested term then Container is the parent term.
So I'm trying to install a web application and I stumbled upon this question: Using WiX to create an IIS virtual directory. When I try to adapt this for my own app, I get an error:
W:\projectlocation\IssInstallationComponents.wxs(6,0): error LGHT0204: ICE18: KeyPath for Component: 'SiteInstallationComponent' is Directory: 'WEBDIRECTORY'. The Directory/Component pair must be listed in the CreateFolders table.
I'm stuck trying to figure this out. Here's what I have in the affected file:
<?xml version="1.0" encoding="UTF-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi"
xmlns:iis="http://schemas.microsoft.com/wix/IIsExtension">
<Fragment>
<DirectoryRef Id="WEBDIRECTORY">
<Component Id="SiteInstallationComponent" Guid="MY GUID">
<iis:WebVirtualDir Id="ProductVirtualDirectory" Alias="[PRODUCTVERSION]" Directory="WEBDIRECTORY" WebSite="DefaultWebSite"/>
</Component>
</DirectoryRef>
<iis:WebSite Id='DefaultWebSite' Description='Default Web Site' Directory='WEBDIRECTORY'>
<iis:WebAddress Id="AllUnassigned" Port="80" />
</iis:WebSite>
</Fragment>
</Wix>
A couple of notes on my example. First, I know that the GUID is wrong, I removed it from the sample above so that it doesn't get indexed by google and reused by someone looking to figure out something similar. In my code, I have a correct GUID. I also changed the product name to "Product" to avoid any kind of IP issues.
Any ideas on what I need to do to get this code working?
sigh
Okay, I went digging through the interwebs and found the following thread: http://www.mail-archive.com/wix-users#lists.sourceforge.net/msg03483.html
Basically I need to change my component so that it looks like this:
<Component Id="SiteInstallationComponent" Guid="MY GUID">
<CreateFolder />
<iis:WebVirtualDir Id="ProductVirtualDirectory" Alias="[PRODUCTVERSION]" Directory="WEBDIRECTORY" WebSite="DefaultWebSite"/>
</Component>
I love Wix, but sometimes it drives me crazy.
Thought I'd add a bit to this. In my case I needed to modify a config file as part of a patch with an XmlConfig action. I ran into the original problem and also tried to work around it by just sticking a CreateFolder element in there. But there's a hitch with that. If your component is part of a patch, putting a CreateFolder entry in there makes it not uninstallable. That means you can't roll back the patch.
What I ended up doing was creating a different KeyPath for the component. I gave it a registry key as the KeyPath and it stopped bothering me about the CreateFolder entry. This means that it will do whatever you want it to do on install and uninstall and use the registry key you gave it to track whether or not the component is installed.
<RegistryKey Root="HKLM" Key="[REGISTRYKEY]\Settings\[TITLE]" Action="createAndRemoveOnUninstall">
<RegistryValue Action="write" Type="integer" Name="MACHINEMEMORYLIMIT" Value="1" KeyPath="yes"/>
</RegistryKey>
(In this case REGISTRYKEY and TITLE are two properties we passed into the installer)