Search results matching tag 'devmsgteam'

The getVisible callback has no effect on Tabs with idMso when startFromScratch=true. Bug?

akash — Wed, 23 Dec 2009 08:00:00 GMT

This is another issue that I bumped into when startFromScratch is set to true. What I wanted to do was to show/hide tabs based on Message Class. If my Message Class was IPM.Note.Custom then I wanted to just show the “My Tab” otherwise I wanted to show the “TabReadMessage”.

Why did I set the startFromScratch to true? I had to customize the Quick Access Toolbar(QAT) also. Below is what my Ribbon XML looks like:

<?xml version="1.0" encoding="utf-8" ?>
<customUI xmlns="http://schemas.microsoft.com/office/2006/01/customui">
  <ribbon startFromScratch="true">
    <tabs>
      <tab id="MyTab" label="My Tab" getVisible="MyTab_OnGetVisible">
      </tab>
      <tab idMso="TabReadMessage" getVisible="TabReadMessage_OnGetVisible">
      </tab>
    </tabs>
  </ribbon>
</customUI>

When I opened a message with the IPM.Note.Custom message class, my callbacks(MyTab_OnGetVisible,TabReadMessage_OnGetVisible) fire and I return True from the MyTab_OnGetVisible callback and False from the TabReadMessage_OnGetVisible callback. Things are good this point.

Now I open a message with the IPM.Note(regular mail message) message class, my callbacks fire and I return False from the MyTab_OnGetVisible callback and True from the TabReadMessage_OnGetVisible callback and expect to the “My Tab” hidden and the “TabReadMessage” visible.. Right?

To my surprise, the callbacks fires just fine but the “True” that I return from the TabReadMessage_OnGetVisible callback has no effect on the visibility of the tab and I am left with no tabs on the screen. Bug?

From what I know this bug has been fixed in Office 14 and a fix for Office 12 has been requested for.

Did you ever have to re-sign the Application and Deployment manifest for a VSTO 3.0 ClickOnce add-in?

akash — Wed, 23 Dec 2009 08:00:00 GMT

My customer had written a VSTO 3.0 add-in but could not publish(ClickOnce) it directly as he did not have access to the production environment. Further more there was a need to change a setting in the config file. He create a Web Setup project to deploy all the file and also altered the config file using a custom action in the setup project.

Changing the config file invalidated the hash and now the application and deployment manifest for the add-in had to be resigned. In case you have never done it before, below are links to a very good blog post and a Channel9 video on how to re-sign the VSTO 3.0 manifests using MAGE.

Re-signing ClickOnce Application and Deployment Manifests with MAGE
http://channel9.msdn.com/posts/funkyonex/Resigning-ClickOnce-Application-and-Deployment-Manifests-with-MAGE/

Signing and re-signing manifests in ClickOnce
http://blogs.msdn.com/vsto/archive/2009/04/29/signing-and-re-signing-manifests-in-clickonce.aspx

Enjoy!

Can’t CopyTo a PST

Stephen Griffin — Thu, 17 Dec 2009 08:00:00 GMT

We recently had a customer who was copying messages around using CopyTo. They found that for certain messages, if the target message store was a PST, they’d get MAPI_E_NO_ACCESS (0x80070005). They saw this for the same messages every time, when other messages would copy to the same PST just fine.

When I debugged the failure, I found the root of the problem was that the source message had an attachment with the property 0x67100003 set on it. The PST provider does not allow this property to be set on a messages in its store, so any attempt to set it returns the error MAPI_E_NO_ACCESS. When they did the CopyTo of the message properties, because PR_MESSAGE_ATTACHMENTS was not excluded, one of the side effects was that MAPI looped through the the attachments and copied them, using calls to CopyTo at the attachment level. These CopyTo calls did not use an exclusion array at all, so every property on the source attachments were copied to the destination. When CopyTo reached the property 0x67100003, the PST provider returned an error, which caused the attachment level CopyTo to fail, which in turn caused the customer’s CopyTo call to fail.

By the way, 0x67100003 isn't the only property that causes this problem. In fact, most properties in the service provider defined non-transmittable range (0x6600-0x67FF) caused the same problem.

The fix we used was to add PR_MESSAGE_ATTACHMENTS to the exclusion list for CopyTo, then copy the attachments manually using OpenAttach, CreateAttach, and CopyTo, passing an exclusion array specifying that the non-transmittable properties should be excluded. Since this is the same logic CopyTo uses to copy attachments (without the exclusion array), doing the copy like this doesn’t have a performance hit.

Custom forms deployment : Where we can publish Outlook Custom forms?

deva — Wed, 16 Dec 2009 08:00:00 GMT

In Outlook, custom forms are typically published to a forms library so that only one copy of a form is stored on your computer. Individual items contain a Message Class field that indicates which form to use to display the data that is contained in the item. When you publish custom forms to a forms library, Microsoft Exchange Server-based computers and Outlook use considerably less resources and bandwidth because the form itself does not need to be stored within each individual item.

Considerations When You Are Deciding Where to Publish a Form:

There are many questions to take into account when you are deciding where to publish a form:

Is the form based on a folder solution, or is it an e-mail message form that is designed to be sent to recipients?
Are you using an Exchange Server-based computer? If you are using an Exchange Server-based computer, is it possible to publish the form to the Organizational Forms Library, or has your organization placed restrictions on what types of forms can be stored there?
How many people need access to the form?
Will the form be updated often, making it important to have only one copy of the form deployed centrally?
Does the form need to be available offline?
If this is an e-mail message form, will it be used only inside the organization, or will it be sent to other recipients outside of the organization?
How will the new form be opened?

Where we can publish?

Now we can see where we can publish these custom forms.

Outlook forms solutions can vary greatly, especially because Outlook has a number of different types of standard forms. It is often difficult to determine the best place to publish a form, and there are many factors to take into account when you make the decision. Forms can be published to three locations:
(1) A folder (or Folder Forms Library)
(2) Organizational Forms Library
(3) Personal Forms Library

We’ll discuss them in detail and how these three makes differences:

(1) A folder (or Folder Forms Library):

For most folder-based forms solutions, publish the form to the folder so that it is available whenever someone is using the folder.
If you publish the form in a public folder, the form is available to everyone who can access the folder.
If you publish the form to one of your personal folders, it is available only to you when you are using that folder.
Contact, Post, Task, and Journal forms are examples of the types of forms that are typically associated with a folder.
One advantage to publishing a form to a folder is that the form is available on the Actions menu when you are in the folder.

(2) Organizational Forms Library:

Publish the form to this library if you want to make the form available to everyone in your organization, such as a form to report vacation time.
This library is often used for e-mail message forms because they are typically not based on a specific folder.
You can publish a form to the Organizational Forms Library when you want to use the same custom form in more than one folder.
When you do this, you can maintain only a single published form.
Forms that are published to this library are accessible to everyone in the organization as long as they are given permissions to the library by the administrator.
The library is stored on the Microsoft Exchange Server-based computer.
The administrator must give you permissions to publish to the Organizational Forms Library.
This permission is typically given to only a few individuals or a department that manages the Exchange Server-based computer.

(3) Personal Forms Library:

Forms that are saved in this library are only accessible to you.
When you publish a form to the Personal Forms Library, the form is stored as a hidden item in the root folder of your mailbox or Personal Folders (.pst) file, whichever is your default mail delivery location.
Like forms that are stored in the Organizational Forms Library, these forms can be opened by using the Choose Form command.
Save a form to this library when you create a form for your own personal use, such as a standard e-mail message form that is pre-addressed to recipients.

Please note: It is also possible to store an Outlook form as a file in the file system or as an item in an Outlook folder. Microsoft recommends that you to avoid these approaches, because the form will be a one-off form.

Deciding Where to Publish Folder-based Forms:

When you create a folder-based solution where the primary focus of the form is to display the items in a single folder, typically publish the form to the folder itself.
When you publish the form to the folder, the folder is a self-contained entity and the form is available on the Actions menu.
However, there are scenarios where you may not want to publish a typical folder-based form to a folder.
If you use a form in more than one folder, and each folder always uses the same version of the form, consider publishing the form into either the Organizational Forms Library or the Personal Forms Library. When you do this, there is only one copy of the published form and it is easier to update if you need to make changes.
If you are the only person who needs access to this form, publish the form in Personal Forms Library.
If other people need to access to the form, and the form is typical in a public folder on an Exchange Server-based computer, investigate whether or not you may be able to publish the form to the Organizational Forms Library.
Note: One potential disadvantage to this approach is that the form will not be available under the Actions menu unless it is published to the folder. However, if it is the default form for the folder, as is typically the case, this will not make too much of a difference because you or the users can use a toolbar button to open new items.

Deciding Where to Publish Message-based Forms

If the form is based on an e-mail message and it is used by you and only a couple of other users, publish the form to the Personal Forms Library for all of the users. However, if you are going to create new items based on this form, you may want to publish it to your Inbox so that you can access it on the Actions menu.
If the form is going to be used by many people within an organization, publish it in the Organizational Forms Library so that there is only one copy of the form to maintain and all of the users have access to it. This approach, however, can make the form more difficult to open.

PR_SEARCH_KEY and Draft Messages

Stephen Griffin — Mon, 14 Dec 2009 08:00:00 GMT

It used to be that if you wanted to track a message through various Object Model events such as NewInspector and ItemSend, one way to do it was to grab PR_SEARCH_KEY. A customer recently discovered that this doesn’t always work after applying a recent hotfix. Before applying the hotfix, PR_SEARCH_KEY would remain unchanged during the various events. After applying the hotfix, if they were in cached mode they would see the search key change during the send event, but only if the user saved the message, or autosave kicked in, before submitting.

The hotfix in question is 973404. More specifically, the change that broke the customer’s code was to address the issue outlined in 974413. This issue is in how Outlook relates Read Receipts to the sent items using PR_SEARCH_KEY. In this issue, if a user created an item as a draft, perhaps to use as a template for commonly sent mail, then copied the message before sending, the draft item and the new item would have the same search key. This in turn broke the read receipt logic.

The fix we made was that whenever we copy a message in the Drafts folder, we don’t copy the search key, which allows the copy to get a new search key and allows the read receipt logic to function. Couple this with the user saving the message to Drafts while they’re working on it – under this new behavior the saved message now has a new search key. Some of the object model events the customer’s code would see would be for the message actually being submitted, and some were for the item in the draft folder. Before the read receipt fix, these different message objects would all have the same search key. But after the fix, the search keys can be different.

The fix here is not to rely on PR_SEARCH_KEY at all. In the customer’s scenario, they were using PR_SEARCH_KEY to ensure they didn’t “stamp” a message with their properties more than once during the submission process. However, since they were already stamping data on the message, it made sense to just look for their stamp before stamping again.

MAPI Now Likes Exchange 2010

Stephen Griffin — Thu, 10 Dec 2009 08:00:00 GMT

We just announced a new release of the MAPI Download that’s pretty much mandatory if you want to work with Exchange 2010. You’ll also need to get and apply Rollup 1 (RU1) for Exchange 2010.

Details about the MAPI Download:

The first version of the MAPI download which is compatible with Exchange 2010 is 6.5.8147
If you already have a version of the MAPI Download installed, you must unininstall it before installing the new version. The installer does not upgrade, nor does it warn you if you try to install it without uninstalling the previous version.

The new MAPI Download fixes a number of problems MAPI had with Exchange 2010:

You no longer need to disable encryption to make a connection.
Notifications, which had not been working, now work.
We no longer crash during certain SetProps calls.
Access to the RSG (now called Recovery Database) now works again.
Admin privilege access to Public Folder stores (OPENSTORE_USE_ADMIN_PRIVILEGE) works again. This fix is actually in RU1.

If I identify other issues fixed by the updated MAPI download, I’ll add them in here.

Enjoy!

[Update: 12/14/09] Forgot to mention that you'll still need these tweaks for your profile, but you don't have to disable encryption anymore.
[Update: 12/21/09] Added information about admin access to PF.

Exchange 2010 RU 1 has been released

dvespa — Wed, 09 Dec 2009 08:00:00 GMT

http://www.microsoft.com/downloads/details.aspx?FamilyID=371add31-d7a0-4c8b-8325-a6fced2d05e6&displaylang=en

Along with a new version of the MAPI download:

http://www.microsoft.com/downloads/details.aspx?familyid=e17e7f31-079a-43a9-bff2-0a110307611e&displaylang=en

Once the new MAPI download has been installed you should no longer have to disable MAPI Encryption on the Client Access Server

How to create recurring tasks using Exchange Web Services for Exchange 2007/2010?

deva — Tue, 08 Dec 2009 08:00:00 GMT

Earlier i got a chance to play around creating recurring tasks. I followed the article from MSDN and it worked like charm for me.

public TaskType CreateRecurringTask()

    // Create the task item and set property values.

    TaskType task = new TaskType();

    task.Subject = "Recurring Task";

    task.Body = new BodyType();

    task.Body.BodyType1 = BodyTypeType.Text;

    task.Body.Value = "Occurs every week";

    task.StartDate = DateTime.Now;

    task.StartDateSpecified = true;

    // Create the regeneration pattern.

    WeeklyRegeneratingPatternType regenerationPattern = new WeeklyRegeneratingPatternType();

    regenerationPattern.Interval = 1;

    // Define the recurrence pattern.

    NoEndRecurrenceRangeType recurrenceRange = new NoEndRecurrenceRangeType();

    recurrenceRange.StartDate = task.StartDate;

    // Set the regeneration and recurrence patterns.

    TaskRecurrenceType recurrence = new TaskRecurrenceType();

    recurrence.Item = regenerationPattern;

    recurrence.Item1 = recurrenceRange;

    task.Recurrence = recurrence;

    // Create the request to make a new task item.

    CreateItemType createItemRequest = new CreateItemType();

    createItemRequest.Items = new NonEmptyArrayOfAllItemsType();

    createItemRequest.Items.Items = new ItemType[1];

    createItemRequest.Items.Items[0] = task;

    // Send the request and receive the response.

    CreateItemResponseType createItemResponse = this.Service.CreateItem(createItemRequest);

    // Access a response message.

    ItemInfoResponseMessageType responseMessage = createItemResponse.ResponseMessages.Items[0] as ItemInfoResponseMessageType;

    // Return the new task item.

    return responseMessage.Items.Items[0] as TaskType;

public ExchangeServiceBinding Service

get

        if (this.service == null)

            this.service = new ExchangeServiceBinding();

            this.service.Credentials = new NetworkCredential(

                this.UserName,

                this.Password,

                this.Domain);

            this.service.Url = this.Url;

            // Set the request version.

            this.service.RequestServerVersionValue = new RequestServerVersion();

            this.service.RequestServerVersionValue.Version = ExchangeVersionType.Exchange2007_SP1;

            // Specify the time zone for the DateTime properties of tasks.

            TimeZoneDefinitionType tzdt = new TimeZoneDefinitionType();

            tzdt.Id = "Eastern Standard Time";

            TimeZoneContextType tzct = new TimeZoneContextType();

            tzct.TimeZoneDefinition = tzdt;

            this.service.TimeZoneContext = tzct;

        return this.service;

Push Notifications broken in Exchange 2010

pcreehan — Wed, 02 Dec 2009 08:00:00 GMT

We recently found a bug in the way Exchange 2010 calls into your EWS Push Notification endpoint. You may see errors on the Exchange server indicating that it received HTTP 500 errors when calling into your client. Basically, the SOAPAction header is not being sent along with the request. I’ll update this post when this issue is resolved.

Outlook 2010 And Bitness

Stephen Griffin — Mon, 30 Nov 2009 08:00:00 GMT

Angela’s put together a good set of guidelines for developing for Outlook 2010, particularly as it relates to whether your code is built for 32 bit or 64 bit (what we’re calling Bitness). To summarize, all MAPI or Outlook Object Model based apps and non-managed add-ins will need to be built in both 32 and 64 bit flavors to support both target environments, managed add-ins can be built as Any CPU, and VB 6 based add-ins and apps need to be scrapped and rewritten entirely. Read the full article to get the finer points, along with a good collection of links to more resources.

Enjoy!