Office Shared Add-ins: Issues - Part 1
If you ever had the opportunity (more like misfortune) to create add-ins for Microsoft Office, chances are good that you might have found deployment to be rather cumbersome at times.
You're faced with all kinds of issues (and red tape), some obvious, some not so obvious.
In this post we're going to have a look at some of the issues / requirements you might face.
Here is a list of some of the things you can check:
-
PIA (Primary Interop Assemblies)
The PIA needs to be installed/registered on the target machine
Office 2003 | Office 2007
Note: You will notice if you use any of the office interop's the setup includes the PIA assemblies within the "Detected Dependencies" of your setup - you will need to exclude them (right click on the assembly, click on exclude), since we're going to use the assemblies registered/installed to the GAC.
It makes sense to include PIA as prerequisite in your setup.
Click here for more information.
-
Disabled
Handling exceptions in our add-in is paramount.
Office applications disable add-ins that misbehaves, there are two methods of disabling add-ins - according to the severity of the misbehavior.
If an add-in causes Office to crash for example, the add-in gets hard-disabled, if an add-in crashes without managing to crash Office, the add-in gets soft-disabled.
Its possible to re-enable the add-in via the Office interface, or by changing registry entries.
For hard-disabled add-ins, one can simply delete the resiliency key, in the following key 12.0 is the office version, and "Word" the office application.
HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Word\Resiliency
For soft-disabled add-ins you need to set the LoadBehavior of an add-in from 2 (unloaded) to 3 (loaded), depending on if the add-in was installed only for the current user or all users, you can find the LoadBehavior inside one of the following keys:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\Word\Addins\SomeAddin
HKEY_CURRENT_USER\Software\Microsoft\Office\Word\Addins\SomeAddin
-
Profiles
During install an user's got the option to install the add-in for the all profiles or only the current profile - which obviously makes the add-in unavailable to other profiles.
-
References
We need to ensure that all assemblies required to run the add-in is available, this is something one can include in our primary output (if possible) of our setup or as a prerequisite.
Assuming that we're using .NET, we need to ensure that we've got the correct version of the framework on the target machine - which we can include as prerequisite.
-
Other Add-ins
In the case of shared add-ins developed in .NET, you'll find that add-ins run on the mscoree which is like an universal "shim" - which means that other add-ins running on this "shim" (same app pool) may affect our add-in negatively.
It might become prudent to develop your own "shims"
Posted by - Christoff Truter
Date - 2010-11-29 11:33:48
Comments - 0
Date - 2010-11-29 11:33:48
Comments - 0
Microsoft Dynamics CRM 4.0: C# - Add file to an account
I recently had the opportunity to do some integration with Microsoft CRM 4.0 (for the first time) for a client - which proved to be quite straightforward.
Microsoft provides a SDK (with tons of examples and documentation) and WebServices (soap based) to aid us with integration etc.
In this post we're going to have a quick look at how to add a file programmatically (using C#) to an account located within CRM.
Step 1: We need to connect/authenticate to CRM.
First of all add a web reference to the crm service e.g. http://cstruter/MSCRMServices/2007/CrmService.asmx".
Observe the following snippet:
CrmService crmService = new CrmService(); void Authenticate() { CrmAuthenticationToken token = new CrmAuthenticationToken(); token.AuthenticationType = 0; token.OrganizationName = "CSTruter"; crmService.Credentials = System.Net.CredentialCache.DefaultCredentials; crmService.CrmAuthenticationTokenValue = token; }
The preceding snippet makes a few assumptions:
- That we have/know the organization
- Know the location of the WebService for that organization
- That we're running in context of an user authenticated against active directory(known as On-premise authentication in CRM)
Now I am not going to go into too much details about authentication in this post, but basically (point 1-2) you'll be able to extract the organization name and webservice url via the CRM discovery service.
With regards to point 3, we could use IFD (internet facing deployment) - for authentication outside the network, or just simple On-premise authentication for users inside our network.
You can read more about it over here:
Web Form (IFD) Authentication
On-Premise Authentication
Step 2: Find the account
BusinessEntity[] GetAccount(string value) { ConditionExpression condition = new ConditionExpression { AttributeName = "name", Operator = ConditionOperator.Equal, Values = new object[] { value } }; QueryExpression query = new QueryExpression { EntityName = "account", ColumnSet = new ColumnSet { Attributes = new string[] { "name", "accountid" } }, Criteria = new FilterExpression { Conditions = new ConditionExpression[] { condition } } }; return crmService.RetrieveMultiple(query).BusinessEntities; }
In the snippet above we "build" a query in order to retrieve an account that we wish to add a file to. In SQL terms the query would perhaps look something like this:
"SELECT name, acccountid FROM account WHERE name = value"
Step 3: Attach the file
In the following snippet (which should be fairly generic for adding files to objects in CRM), we add a file to our account.
Guid? AddAttachment(string filename, EntityName ObjectType, string ObjectId) { FileInfo fileInfo = new FileInfo(filename); if (fileInfo.Exists) { TargetCreateAnnotation target = new TargetCreateAnnotation { Annotation = new annotation { filename = fileInfo.Name, isdocument = new CrmBoolean { Value = true }, documentbody = Convert.ToBase64String(File.ReadAllBytes(filename)), mimetype = "application/octet-stream", objectid = new Lookup { type = "annotation", Value = new Guid(ObjectId) }, objecttypecode = new EntityNameReference { Value = ObjectType.ToString() } } }; CreateRequest request = new CreateRequest { Target = target }; CreateResponse response = (CreateResponse)crmService.Execute(request); return response.id; } return null; }
In the final snippet we tie it all together, observe:
static void Main(string[] args) { Authenticate(); string somedoc = @"c:\6.xls"; BusinessEntity[] account = GetAccount("dude"); if (account.Length > 0) { string accountid = ((account)account[0]).accountid.Value.ToString(); AddAttachment(somedoc, EntityName.account, accountid); } }
Basically we authenticate and search for an account with the name "dude", if we're able to find it, we attach a file to the first account containing that name (a bit crude, but it gives one the basic idea of how to add a file to an account).
Additional Reading
Microsoft Dynamics CRM 4.0 Software Development Kit (SDK)
AuthenticationType Class (CrmHelpers)
Developing ISV Applications using Microsoft Dynamics CRM 4.0
Posted by - Christoff Truter
Date - 2010-11-23 19:02:25
Comments - 0
Date - 2010-11-23 19:02:25
Comments - 0
First 11 12 13 14 15 16 17 18 19 20 Last / 62 Pages (124 Entries)