CRM Blog

December 2008 - Posts

State Code Attribute Data Type When Accessed Inside Plug-In
by Danny Varghese 12.29.08

Comments    No Comments

 How To Access Attributes Within Plug-In Code

When developing plug-ins, users can access fields on the form before and after the record has been updated, created, etc.  Developers can do this by first registering the assembly, then a step (configuring whether it's a post/pre update/create/etc., then finally by registering a pre/post image.  The image(s) is/are passed in with the execution context.  When configuring the image, one can select attributes that get passed in.

 

When developing the actual plug-in, these attributes can be accessed in the following manner:

 

entityImageName = (DynamicEntity)context.PostEntityImage[<postEntityImageName>];

attributeName = (DataType)entityImageName[<attributeName>].Value;

 

For example, if the attribute is a lookup…

 

DynamicEntity entityImageName = (DynamicEntity)context.PostImageEntity["testImage"];

Lookup testLookup = (Lookup)entityImageName["testLookupAttributeName"].Value;

 

If you look at the above code, the context has access to the pre/post images based on whatever you configured using the plug-in registration tool.  The name you configured is the "postEntityImageName," This is then all cast to a DynamicEntity.  Then you can access the attributes, much like an array or collection, using the attribute name.  However, since the ".Value" method returns an object, it must be cast to the appropriate data type.  The data type can be found in the customization section on the CRM client, or when registering a plug-in image, the data types are found when you need to select/de-select attributes to pass in.

 

State Code Attribute

For most attributes, the data types are straight forward.  The data type for the id of the record is a Key, for any referential or parental relationship attributes, the data type is a Lookup, and for the Status attribute, the data type is simply Status.  However, the State Code can be tricky and after trial and error, I've found that when you need to access the State Code attribute, you must cast this as a String.  The two possible values that is out-of-the-box is "Active," and "Inactive."

Filed under:
Microsoft CRM 4.0 and Windows Presentation Foundation
by Jeremy Hofmann 12.26.08

Comments    No Comments

Interesting in building a dashboard for CRM 4.0?  In this article, I’ll show you how to build your own custom CRM dashboards, using Microsoft’s Windows Presentation Foundation to construct the user interface.  This dashboard will run as a standalone Windows application in order to give your user’s the most optimal performance.

Please visit the Microsoft CRM Team blog for the whole article - http://blogs.msdn.com/crm/archive/2009/01/07/building-rich-client-dashboards-for-microsoft-dynamics-crm-with-windows-presentation-foundation.aspx

 Enjoy!

 

Developing Portable Code For Microsoft CRM - Part II
by Danny Varghese 12.23.08

Comments    No Comments

 Intro

As mentioned in one of my earlier blog articles: http://www.crowehorwath.com/cs/blogs/crm/archive/2008/03/05/gac-it-developing-portable-code-for-microsoft-crm.aspx one can register assemblies in the GAC to help build a portable custom CRM solution.  In CRM 4.0, with the introduction of registering assemblies on the database server, developing portable code has gotten a bit easier. 

 

Building A Common Library

When developing plug-ins, often times developers find themselves either re-writing or re-using some common functionality.  For example connecting to a database, executing stored procedures, logging to a log file, even creating/updating entities.  When encountering these situations, I would recommend extracting out this logic and placing it in it's own assembly file acting as a library.  This then can be called by multiple assemblies/plug-ins thus reducing the amount of overall code, and maintenance.

 

Referencing The Common Library
When developing a plug-in, the best way to reference the library you've built is adding it as a project reference.  According to MSDN (http://msdn.microsoft.com/en-us/library/wkze6zky(VS.80).aspx) you should avoid adding file references to outputs of another project in the same solution, because doing so may cause compilation errors. Instead, use the Projects tab of the Add Reference dialog box to create project-to-project references. This makes team development easier, by allowing for better management of the class libraries you create in your projects.

 

Putting It All Together

Once you've developed your plug-in/custom assembly for CRM and the library, it's time to put it all together.  **NOTE**  Since plug-ins need to be strong typed, so do any files that it references.  So the library, if you're using it for plug-ins, will need to be strong typed.  First register the plug-in assembly file either on the database/server.  Then place the library in the <crm-root>\server\bin\assembly directory.  By doing this, anytime the plug-in executes, it will check this directory for the reference.  What this allows you to do is very easily develop a library to be used by all plug-ins and you don't have to use the GAC!  Happy coding!

Filed under:
Using Fiddler for CRM Development and Troubleshooting
by Jeremy Hofmann 12.19.08

Comments    No Comments

Microsoft CRM is a web application.  That means it uses a variety of resources such as html pages, javascript, css style sheets, and images to render the user interface.  Occassionally during development or troubleshooting you will need to view these resources, the order they are streamed to the browser, and how long each request is taking.  Armed with this knowledge, you can fine tune your CRM application to optimal performance.  Or, you can determine where certain page elements are located which enables you to code some fancy customizations.

Fiddler is a web debugging proxy that allows you to inspect the traffic between the web server and the client.  It's quick and easy to install.  You can record and save your sessions for later viewing, or even save them as Visual Studio web tests for later analysis and playback.

Notice on the left, Fiddler shows you the exact url, size, and source of the file.  It also lists each HTTP response associated with the request.  You can use this information to tweak file cache and to see exactly what the browser is trying to do as you navigate CRM.  On the right, you can view statistics, session information, and the actual html pages that are sent from the server. 

Finally, you can use Fiddler to capture web service calls, which will help you author client side javascript.  For a tutorial on this, see the Microsoft CRM SDK article here.

Enjoy!

Filed under:
CRM Webinar
by Bryan Van Antwerp 12.17.08

Comments    No Comments

Crowe is providing a webinar on Microsoft Dynamics CRM on January 8, 2009 from 1:00 - 2:30 PM ET.  If you are interested, you can click here for more details: 

https://www.crowehorwath.com/crowe/AboutUs/Events/detail.cfm?id=413

Filed under:
Changing the Domain and/or Username in CRM 4.0
by Luke Simpson 12.16.08

Comments    1 Comment(s)

Microsoft has changed the way administrators may alter an existing user's Domain and/or Username in CRM 4.0.  A knowledge base article exists with detailed instructions, which can be found here: http://support.microsoft.com/kb/930853.

 Here is a quick synopsis of the procedure:

  1. Modify the user account in Active Directory. For example, change the user name, and then change the logon name.
  2. Open Microsoft Dynamics CRM 4.0 as a System Administrator user.
  3. Click Settings, click Administration, click Users, and then open the user record that you want to change.
  4. In the Domain Logon Name box, type an Active Directory user account that is not used by a Microsoft Dynamics CRM 4.0 user record.
    ~~This should just be any AD user on the network that is not using CRM.  It is just a placeholder.

    Note If all the Active Directory user accounts are used by Microsoft Dynamics CRM 4.0 user records, create a temporary Active Directory user account.
  5. Click Save.
  6. In the Domain Logon Name box, type the Active Directory user account. Then, click Save and Close.  
    ~~This should be the new Username that you wish to use.

    Note The Active Directory user account that you type in this step is the account that is used by a Microsoft Dynamics CRM 4.0 user record. The Microsoft Dynamics CRM 4.0 user record is the record for which you want to change the user name and the logon name in Microsoft Dynamics CRM 4.0.
Filed under:
Modifying the Planning Tasks View on a Marketing Campaign
by Shelley Lane 12.14.08

Comments    No Comments

Each Campaign created using the CRM Marketing Module can have Planning Tasks associated with it. Sorting for the default view of these Planning Task is on the column Name. For many, it may make more sense to sort this view by Due Date, with those Due in the nearest future (or past) at the top of the list (ascending).

Simple, right? We'll just follow the examples in the Microsoft Team Blog post, and.... Wait a minute! There's no "Planning Tasks" view - anywhere. Now what?

Well after looking through various possibilities, The Planning Tasks view under Campaigns actually uses the "All Tasks" view. Modifications to the All Tasks View will be reflected in your list of Campaign Planning Tasks.

Filed under:
Modifying Additional CRM Views
by Jeremy Hofmann 12.12.08

Comments    No Comments

When you need to modify a view in CRM, nine times out of ten you will modify the view in the Settings | Customization | Customize Entities area of CRM.  Occassionally however, you will find the need to modify additional views that are not available through this area.  Jim Schumacher on the Microsoft Team blog has a great post describing how to access and modify these additional views.  The example is for marketing list members - check it out!

Filed under: