One of the most common themes in the programming forums for Microsoft CRM are related to connecting to your CRM.  For a little background, there are three primary deployment models supported by Microsoft Dynamics CRM 4, and four ways to connect to them.

On-premise and partner-hosted installations are installed in an Active Directory environment.  The only difference between the two is that in a partner-hosted environment, the CRM is outside of your own Active Directory forest and is installed in it's own forest.  A partner hosted CRM is always configured for internet-facing deployment (IFD), where you have the choice of configuring IFD for your own on-prem installation.  The IFD configuration will allow your CRM to use forms authentication for clients that are outside of your network.  The other CRM installation (which none of us get to install) is CRM Online, and CRM Online uses Live ID exclusively for authentication.

When you are building applications that integrate with CRM, you have to consider what user context your application is running in, where your CRM is deployed, and which authentication mechanism your application will be required to use.  If your application and the CRM are in the same network and using the same Active Directory forest, you have the choice of using integrated security (use the credentials of the current process), or you can provide alternate network credentials.  If your application and CRM are in seperate networks and the CRM is configured for IFD, you will have to use what is known as SPLA authentication (SPLA is the name of the licensing program that the CRM partners are required to purchase the CRM server license from).  Finally, if you are connecting to CRM Online, you will have to authenticate with Live ID, which is the new name to the old API called Passport. 

Each of these authentication mechanisms requires a different authentication mechanism.  Unfortunately, Microsoft has not really made it easy for customers to connect to their CRM, and this is evidenced by the sheer number of posts in the newsgroups related to the topic.  The first thing I have to say is that I use a completely different pattern than most of the basic examples that are given for customers to use, but I still use methods that are officially supported.  I don't attach service references in my project to the CRM deployment.  In my opinion that is insane.  I use the dll files that are provided in the CRM SDK and I have a connection library in our CRM Developer's Toolkit that makes connecting to the CRM very easy.

The basic premis that we have is that connecting to a CRM server should be like connecting to a SQL database.  The pattern that Microsoft has integrated directly into ASP.NET is to use connection strings with name/value pairs and to store those connection strings in the configuration file of your application.  This is a very powerful pattern.  The main benefit is that there is no connection code required in your application, and the values can be changed at deployment time.  After all, you dont' develop against your production database do you?  Another handy feature is that the connection string section of your config files can be encrypted.

Most community example that have CRM connections read the settings from application variables in the config file, but instead of using many custom application variables, we have decided to use a single connection string with the parameters as name/value pairs.  Most developers easily understand this as they are already used to doing this with SQL database connection strings.  Our connection library in the CRM developer toolkit reads the connection string and connects with your CRM server based on the values in the connection string.  All connection mechanisms are supported (integrated, Active Directory, SPLA, and Passport).  The connection string also contains the base url for the CRM, but the developer toolkit will know where to get the discovery service, meta data service, and service urls from the base url.

Here is the format of our connection string:
 "Authentication Type={auth-type}; Server={url}; User ID={username}; Password={password}"
where:
auth-type can be one of AD, Integrated, SPLA, or Passport
url is the base url for your CRM deployment
username is in domain\username format for AD authentication type, or a Live ID for passport authentication

Connecting to the CRM in your code is as simple as:

var crm = new CrmConnection();
var service = crm.CreateCrmService();
var metadataservice = crm.CreateMetaDataService();

It simply does not get any simpler than that.  The above code will connect using the default connection string named "Microsoft-CRM", but you can also provide a specific connection string name or even a full connection string in the CrmConnection constructor as parameters. These service handles are fully authenticated and will work against all CRM deployments.  The only thing that you have to change when you move your app from dev/test/prod is to change the connection string in your configuration file.  In addition to the obvious benefits of the above mechanism, I would also like to point out that the CRM developer toolkit also uses connection pooling, which addresses the performance issues that are typically faced when programming against CRM Online.

The instructions in the SDK that demonstrate how to connect to CRM Online are very complex.  They require that you add an unmanaged dll to your solution and call back out to that unmanaged dll from within your application.  Connecting to CRM Online is done by first authenticating with Live ID and retrieving an authentication token, then that authentication token can be used with the CRM discovery service to obtain an authentication ticket for the CRM services.  All of this is handled under the covers for you by the CRM Developer Toolkit and it does not use any unmanaged DLLs.  Connecting to CRM Online uses the same mechanism you use for all other CRM deployments with the only difference being different values in your connecton string.

If you follow the samples that are given in the SDK documentation you will end up with connection logic in your code, and for most of the code samples, that means your code will be hard-coded to an on-premise deployment.  Locking the deployment model into your code is a bad idea - the choice of where your CRM is should be a deployment choice and it may change over time.  It is better for your application to allow for all of the CRM deployment models without requiring any code changes.  I am very surprised that even the recent CRM accelerators only support on-prem deployments.  Solutions written using the CRM Developer Toolkit will support all deployment models without exception.