This is a follow up on my earlier project CRM Customization Manager, CRM Configuration Manager is a Windows application to create an Export / Import selection that can later be exported as a command prompt string for later use, or execute directly inside the application. The main features of CRM Configuration Manager are,

• Easy access to the features of CRM Customization Manager
• Possible to select a CRM server as destination, allowing one click export and import.
• Create advance export/import selections for later use inside scripts / installations

This release includes CRM Customization Manager v2.0 that contains fixes and few new features,

• JavaScript Export/Import, This allows you to extract JavaScript to a local folder, where you can work in a proper script editor, and later import them back. You can also create new javascripts in the same folder, just follow the name convention and they will also be imported to the correct entity / event.
• Zip support, Now all features works with zipped customizations
• Include Related Entities, This features will automatically include related entities to the selected entities, so their relationships are exported and can be reviewed for conflicts. This is recommended during the development process when relationships may change.
• Publish Workflows, Publish operation now also publishes workflows

Previous key features...

I’m wondering, is there any interest in creating your own operations? That is, using a Plug-in model to add custom arguments to the application that will call your code before/after execution. If you find the application useful, please donate to keep the development alive :)   CcmSetup1.01.exe (907,26 kb) Update: v1.01 Import filename fix   Happy Customizing!

If one would like to change a relationship lookup field name on a entity, then it is important to change the name of the relationship.

For example, We have an entity called “EntityA” and it has a N:1 relationship with “EntityB”, the lookup attribute is currently called “entityb_conntectedid” and we would like to change the lookup attribute to “entitybid”. Then you normally would remove the relation, and add a new one setting the new name “entityid” to the lookup attribute.

Then you have to change the “relationship name” from the generated name “new_new_entitya_new_entityb” to for example “new_new_entitya_new_entityb2”. Otherwise there will be a conflict when importing the customizations to a CRM system that contains the old attribute making it impossible to publishing the entity if the old field exists on a form.

In the upcoming version of CRM Customization Manager (v2.0) I’ve included a warning message if one tries to import a customization that has a different name of the lookup to the same relationship so one can spot this before CRM gets broken. Also if the relationship is exported CRM Customization Manager solves the problem.

If you already have imported the new relationship and cannot publish / import the Entity, you can fix it by editing the CRM database. Access the table “OrganizationUIBase”, filter it by the ObjectTypeCode of your custom entity, then removing all the references to the old attribute in the “FormXml” column.

Related errors:
Cannot Export Customizations From Microsoft Dynamics CRM 4.0

Update:
CRM Configuration Manager now handles this.

Validation of Social Security Number (Personnummer) or the Organisation Number is very common validation when working with business systems, here is a small method to validate the Swedish identification numbers. If you by any chance have done a similar check for your country social security number, would be nice if you post a link to your site or send the code and I will update this post.

IdNrCheck.zip (832,00 bytes)

Generics is a very nice feature of C# language, and can be used to simplify the CRM Web Service method calls. One of my responsibilities at Logica is to develop a framework for CRM development, and one of the main classes in this framework is called CrmSystem, it wraps the CrmService methods among other things. Using generics one can then type,

account acc = CrmSystem.Retrieve<account>(myAccountId);

also we use a special NameValue class CrmConditions to one of our Execute overloads, here is how it can look

List<account> acc = CrmSystem.Execute<account>(new CrmCondition("emailaddress1", "daniel@logica.com"));

This would retrieve all accounts that got the email "daniel@logica.com"

Here is one of the overloads for the Retrive Method that uses Generics, it calls an other overload that does the actual call to CRM Web Service using the EntityName string that we get thru typeof(T).Name

public T Retrieve<T>(Guid id, params string[] columnSet) where T : BusinessEntity { 
     return (T)Retrieve(typeof(T).Name, id, new ColumnSet(columnSet));
}

Hope this gives some inspiration for your own CrmApi wrappers :)

During my time with Microsoft CRM 4 I’ve found some limitations of the import & export process of customizations, which led to the curiosity if one could fix those with a custom application. Thanks to the open architecture of Microsoft CRM with Web Services and Xml for customization management it was pretty easy to create a small application to improve the import and export process of customizations.

Here follows the main features of CrmCustomizeManager.

• Console Application, Making it possible to import and export inside nant, msbuild or bat scripts, for example to export the customization each night and “check in” to a source code repository, enabling version control of the customizations. Also to import customizations directly from a MSI installation.
• Export Only Modifications, You can export a “clean” customization xml in the beginning of a project and save it in the application folder as “CleanCustomization.xml”, the application will compare the current state and only export the entities that are modified or added.
• Remove Deleted Attributes, This feature only applies when importing a customization. When this operation is selected one will be prompted with all attributes that has been removed in the new customization, given the possibility to remove them from the CRM instance.
• Changes Attribute data type, When changing an attributes data type and then trying to import it to a CRM instance that still contains the old attribute would normally generate an error. This is now handled and the data inside the old attribute will be converted to the new data type (when possible and logical)
• Publish, You can publish the customizations, can also be used at it’s own, for example assigning it to a system wide hotkey for fast access.
• Node & Entity Selection, you can select what nodes and entities to import and export. For example only export ISV Config or the Site Map. Possible items to select,
  
  

  Entities	Workflows	Roles	ISV Config
  Sitemap	Templates	Calendar Settings	General Settings
  Email Settings	Marketing Settings	Outlook Synchronization	AutoNumbering Settings
  And more…

Get Latest version.

When registering plug-ins, CRM doesn't always look for referenced assemblies where you think it would. It can look for "some" dll's in CRMWeb\bin folder (but not all references for some reason) as Gustaf explained in his blog.

But there is one more deviation, and that is when registering Workflow plugins, CRM looks for referenced dlls in "x:\Program Files\Microsoft Dynamics CRM\Server\bin", and not the "assembly" folder where you put your Plug-in assembly. 

Was looking for a standard way of merging two XML Documents using XDocument objects, but found none with duplicate checking. You can use this short snippet bellow to merge two XDocuments, but then duplicate elements will also populate the merged document, so here comes a handy little method that also checks for duplicate items.

Recently I was working on a dynamic Fetch XML query that was adding a lot of conditions. During a batch run the CRM Service started to crash when the xml size got around ~135kb. My first thought was that there were a size limit of the SOAP message that we'd cross, but after further testing it would become evident that fetch queries has a limit of 2097 <condition> elements. That is 2097 per <filer> element. If a query has linked entities that has 0-2097 conditions then the main entity can have a maximum of 2095 conditions.

I've lately changed focus from MOSS 2007 to work with Microsoft Dynamics CRM solutions, anyhow. As Microsoft doesn't use the .NET 3.5 web extensions AJAX functionalities in CRM 4, and that is something that you may like to use in your ISV solutions, you need to change the "C:\Program Files\Microsoft Dynamics CRM\CRMWeb\web.config" to include all the references to the .NET 3.5 libraries. As you may know changing the web.config is not a supported customization, as after an upgrade your changes won't be there. So I have a plan of writing a small consoleapp that will add the changes to the web.config but until then here is a web.config with them included.

As WM-data just became Logica here in Sweden we have changed our laptops and entered a new domain, with that there came new policies and rules. One of them is the enforcement of using the User Account Control (UAC) on all Vista machines, which is pumped out each time logging into the Logica domain.

This presented a problem that needed to be solved, how to be able to work inside the domain and still be effective? Solution: A NT Service that continuously turns off the UAC.

Here is an install for the small service that just checks so the UAC is not turned on when the computer is shutting down.

DisUacSetup.msi (392,00 kb)

A very good article about the consequences of hiring inexperienced programmers for buildig new systems. Don't get me wrong, we all were inexperienced at some point. But inexperienced programmers should start of their carrier by administrating / fixing bugs on "finished" systems, where they can get experience without causing a mess.

A Guide to Hiring Programmers: The High Cost of Low Quality

Creating new files in a Document Library is a pretty simple task as copying the template located in the "Forms" folder. But creating a new Form is a bit harder as the template is a binary file, and what we want is a new Xml file.

The template file (with extension XSN) created by InfoPath is actually a CAB archive, that contains your form logic compiled, schemas and your xml template. So what you have to do is extract the CAB file, and copy the "template.xml" file to your Form Library. You can find a CAB extractor at The Code Project.

Here is a example of a method to get the template Xml:

private byte[] GetXmlForm(SPDocumentLibrary list) {
  byte[] data = null;
  SPFile file = list.ParentWeb.GetFile(list.DocumentTemplateUrl);
  Extract cab = new Extract();
  string szFolder = string.Concat(System.IO.Path.GetTempPath(), list.Title, "\\");

  if( !Directory.Exists(szFolder) )
    Directory.CreateDirectory(szFolder);

  cab.ExtractStream(file.OpenBinaryStream(), szFolder);
  FileStream fs = new FileStream(szFolder + "template.xml", FileMode.Open);
  try {
    data = new byte[fs.Length];
    fs.Read(data, 0, data.Length);
  } finally {
    fs.Close();
  }
  return data;
}

There is one more thing that has to be done before saving the template, which is to add a hyperlink to your InfoPath Template. The href should be added in the processing instruction tag "mso-infoPathSolution" ie.
<?mso-infoPathSolution href="http://server/site/library/Forms/myTemplate.xsn" ?>

Here is a snippet on how to do it:

frm.SetTemplateUrl("http://Server/Site/{0}"+list.DocumentTemplateUrl);

public void SetTemplateUrl(string url) {
  foreach(XmlNode n in m_Doc.ChildNodes) {
    if(n.Name == "mso-infoPathSolution") {
      string szHref = string.Format("href=\"{0}\"", url);
      Regex r = new Regex("href=\".*\"");
      if(r.IsMatch(n.Value))
        n.Value = r.Replace(n.Value, szHref);
      else n.Value = string.Concat(n.Value,szHref,' ');
    }
  }
}

The documentation on MSDN defines 11 different field types, but inside SharePoint administration you can specify more types when creating a column. such as "Person or Group" and "Calculated". These types are not documented but are possible to set in the type attribute. Here is the whole list:

AllDayEvent
Specifies an all day event. 

Attachments
Contains attachments. 

Boolean
Contains Boolean values that are stored in the database as 1 or 0. 

Calculated
Contains calculated values. 

Choice
Specifies a predetermined set of values that can be used to enter data into the field. 

Computed
Specifies an abstract field type that depends on other fields for its content and definition. 

ContentTypeId
Contains a content type ID.  

Counter
Contains an integer used for internal ID fields. 

CrossProjectLink
Specifies a link between projects in a Meetings Workspace site. 

Currency
Contains currency values formatted based on a specific locale. 

DateTime
Contains date and time values. 

Error
Contains errors. 

File
Contains files. 

GridChoice
Specifies a Choice field for a data sheet. 

Guid
Contains GUIDs. 

Integer
Contains positive or negative integer values. 

Lookup
Contains references to values in other lists. 

MaxItems
Contains the maximum number of items. 

ModStat
Specifies Content Approval status. 

MultiChoice
Contains multiple values per list item. 

Note
Specifies a field that can contain multiple lines of text. 

Number
Contains floating point numbers. 

PageSeparator
Inserts a page break in a survey list. 

Recurrence
Specifies a field used in calendars for recurring events and, like computed fields, an abstract field type that depends on other fields for its content and definition. 

Text
Contains a single line of text. 

ThreadIndex
Contains the ID that indicates the relative position of a message within a conversation thread. 

Threading
Specifies a field that is used in the creation and display of threaded Web discussions. 

URL
Contains hyperlinks. 

User
Specifies users of a SharePoint site. Same as "Person or Group" in STS.

WorkflowEventType
Specifies a workflow event type. 

WorkflowStatus
Specifies workflow status. 

Example:
<Field ID="{04436D2F-67D9-48bd-9B56-B3D27EA6D3EF}"
            Name="Verifiers"
            DisplayName="Verifiers"
            Type="User"
            ...
            />

UPDATE: Found a more complete definition of the Field Element (then the one in CAML documentation), in MSDN List Schema documentation.

Microsoft has published a very good Walkthrough on how to create a Workflow for SharePoint 2007 and using InfoPath Forms for custom user interaction.

But they where a bit vague on explaining the configuration surrounding the InfoPath Forms, as they left out how to register the Form in SharePoint. Here are some clarifications.

- The InfoPath Form Template ID that are used in workflow.xml/Elements/MetaData/*_FormURN elements are found in InfoPath, 
File > Properties. The "Properties" menu item exists only when opening InfoPath in Design-mode, todo that right click on the xsn file and select "Design" in the context menu.

- Before installing your feature it's always good to verify that the published form will work correctly in your SharePoint instance using the StsAdm tool:
"stsadm -o verifyformtemplate -filename MyFeature\MyForm.xsn"
If you have created your Workflow project from the Visual Studio 2005 "SharePoint Server Seq. Workflow" project there is an installation .bat file created called PostBuildActions.bat which contains this line, but it's commented. You just need to uncomment it and change the path to your form.

- When installing the feature you should put the Template Form(s) inside your feature folder. (...\web server extensions\12\TEMPLATE\FEATURES\MyFeature\)

- You need to register your InfoPath Forms in SharePoint, which is done thru the feature.xml, by putting a Property element with the "RegisterForms" directive, and the relative path to the form(s) from your feature folder. This example registers all forms in the feature root folder.

<Feature Id="54178F4E-80E6-4c26-835C-2533060FFD74" .... >
  <Properties>
    <Property Key="RegisterForms" Value="*.xsn" />
  </Properties>
</Feature>

References:
Walkthrough: Creating Office SharePoint Server 2007 Workflows in Visual Studio 2005
MSDN Articles: InfoPath Forms for Workflows

There is often that one need to get an assembly’s full name, while one can do it quite simply in C# by instancing the assembly and calling GetName(), but when setting up applications outside the development environment, You can use SN.exe to retrieve the PublicKeyToken using the -T parameter, but still it would be nice to get the whole Assembly Name, so here is a small command prompt app that does the job.

Example of an Assembly full name:
"GetAsmName, Version=1.0.0.0, Culture=neutral,
PublicKeyToken=efc52db0448864e8"

Download the compiled application:
GetAsmName.zip (2,83 KB)

Download the source code:
GetAsmName-src.zip (2,51 KB)