We Keep Coding

Getting source location from TypeDefinition with Mono.Cecil

I would like to determine which source file defines a specific type using Mono.Cecil.
For methods, I can use the SequencePoint collection (for example, I could grab the first SequencePoint and fetch the Url of it's Document). I'm assuming this would always work as long as the PDBs are loaded since even empty methods should have at least one instruction (nop):
if (methodDefinition.DebugInformation.HasSequencePoints) {
var firstSequencePoint = methodDefinition.DebugInformation.SequencePoints[0];
return firstSequencePoint.Document.Url;
}
However, for types, I am not sure how this would work. Do the PDB files even contain the mapping between a type and a document? Obviously a type can be defined across multiple documents (in case of partial classes, for instance) which is fine - but is this information actually available? If yes, is it exposed in Mono.Cecil? Mono.Cecil.Cil.PortablePdbReader does read CustomDebugInformation for a module but I don't think this is it (I looked at the raw data and it doesn't contain anything of interest).

Storing the state of a VSTO Outlook plugin with a draft message

I'm working on a VSTO plugin for Outlook (C#) and find nothing about saving or embedding the state/options of my plugin with a draft message.
Is there any mean to do that ?
Ex: if my plugin makes the message to be displayed in red, I want to have my draft re-opened written in red.
Any idea ?

Use the UserProperties.Add method which creates a new user property in the UserProperties collection. Use the UserProperties property to return the UserProperties object for an Outlook item. This applies to all Outlook items except for the NoteItem.
Use the Add method to create a new UserProperty for an item and add it to the UserProperties object. The Add method allows you to specify a name and type for the new property. When you create a new property, it can also be added as a custom field to the folder that contains the item (using the same name as the property) by setting the AddToFolderFields parameter to true when calling the Add method. That field can then be used as a column in folder views.
To set for the first time a property created by the UserProperties.Add method, use the UserProperty.Value property instead of the SetProperties and SetProperty methods of the PropertyAccessor object.
If you need to keep the data for the folder or Outlook account in general (not per item) you may consider the StorageItem instead. That is a message object in MAPI that is always saved as a hidden item in the parent folder and stores private data for Outlook solutions.
The Outlook object model does not provide any collection object for StorageItem objects. However, you can use Folder.GetTable to obtain a Table with all the hidden items in a Folder, when you specify the TableContents parameter as olHiddenItems. If keeping your data private is of a high concern, you should encrypt the data before storing it.

As Eugene advised, you can use MailItem.UserProperties collection to set/read your custom properties.
A couple points to consider - since named properties are a finite resource, you can have at most 32k of them per mailbox. Once you go over, the mailbox is pretty much dead. So use as few unique properties as possible, and definitely do not use anything dynamic, such as the message subject in the property name.
If you set a user property on an outgoing message, Outlook might force it to go out in the TNEF format. To prevent that from happening, set the property value using MailItem.PropertyAccessor.SetProperty. You can use the same DASL property name that your user property uses, but the point is to avoid using the UserPropeties collection. You can see the DASL property name in OutlookSpy (I am its author) - select a message with your user property set, click IMessage button, select your property, see the DASL edit box.

Unique identifier for Interop.ListObject from VSTO - C#

I need a way to insert (or use an already implemented property that could serve as) a unique identifier into a Microsoft.Office.Interop.Excel.ListObject instance.
The problem is that when I'm creating a new ListObject as:
var excelTable = worksheet.ListObjects.Add(ExcelInterop.XlListObjectSourceType.xlSrcExternal, DUMMY_CONNECTIONSTRING, false, true, cellRange);
I cannot rely on the Name property of excelTable to browse for it in the collection since the user could change the value of that property anytime afterwards.
After browsing trough the object properties I found nothing I could use out of the box (like a Tag property for example, which exists in a Microsoft.Office.Tools.Excel.ListObjecttype of object I cannot use at this point due to dependencies) ...and other weird stuff like a DisplayName that appears not only unable to be set directly but also to reflect the exact same value that the Name property has at all times (Why would you want to have 2 properties that reflect the same value at any time?).
I've thought on either creating my own implementation of this class or probably use the Comment property to store a GUID (which I don't know why kinda feels wrong):
excelTable.Comment = Guid.NewGuid().ToString();
Can you suggest of another way to accomplish this task?
Thanks a lot!

It is quite frustrating that there is no "Tag" (or similar) property that you could set on Excel objects. I'm facing the same issues as you. Here are two options that you can use:
alternative text property (for the table it is only visible by right clicking the table, selecting table and alternative text). This is probably a bit cleaner than Comment since the UI for comment is always visible.
you could also generate a wrapper object that contains a direct reference to the ListObject. So one wrapper object for each created ListObject. This works fine until you save / open the workbook again. If you need to be able to identify the table again after reopening the workbook you would still need to write some id to Comment or Alternative text. You could probably do a clean implementation by using events like BeforeSave and AfterSave (add alternative text before save so it saves to disk, then remove it again after save so that the user doesn't see it. When the workbook opens you load up your wrapper objects and remove the alternative text).

MEF update exported part metadata (the metadata view is invalid because property has a property set method)

I have an application and I'm using MEF to compose it. I want to know if it is possible to update the Metadata information of the parts after they were imported.
The reason to do this is the following: I display the imported parts' name and an typeof(int) property in a ListBox, and they are not loaded until the corresponding ListBoxItem is selected (pretty standard). Now I want to update the Metadata info of one part when some event raises, so the displayed info in the ListBox is somethind like "[Part name] ([new number])".
I'm importing the metadata as an Interface that defines it's info, but when I set the int property to be editable (with a set accesor) I receive the following execption at composition time:
"The MetadataView 'myMetadataInterface' is invalid
because property 'myInt' has a property set method."
Is there ANY way to achieve this? Or is the metadata ALWAYS read only once the part is created?
I know this question looks weird, but it doesn't make it any less difficult and therefore interesting ;-)
EDIT (based on Lee's answer, in order to keep people to the core of the question)
I just want to know if it is possible to update a Metadata property after the part is composed, but before it is actually loaded (HasValue == false). Don't worry about filtering or finding the part.
I added a property to the export inteface, which is meant only to be represented in the UI and to be updated, this property has no other function and the parts are not filtered by it.
Thanks

Metadata filtering and DefaultValueAttribute
When you specifiy a metadata view, an implicit filtering will occur to
match only those exports which contain the metadata properties defined
in the view. You can specify on the metadata view that a property is
not required, by using the
System.ComponentModel.DefaultValueAttribute. Below you can see where
we have specified a default value of false on IsSecure. This means if
a part exports IMessageSender, but does not supply IsSecure metadata,
then it will still be matched.
citation
Short Version (EDITED in after question edit).
You shouldn't ever need to update metadata at runtime. If you have some data that should be updated and belongs to a mef part, you need to choose to either have it be updated by recompiling, or store that data in a flexible storage outside of the dll. There's no way to store the change you made in the dll without recompiling, so this is a flawed design.
Previous post.
Altering values on the view would by lying about the components loaded. Sure the metadata is just an interface to an object that returns initialized values; sure you can technically update those values, but that's not the purpose of metadata.
You wouldn't be changing the Name field of an instance of Type. Why not? Because it's metadata. Updating metadata at runtime would imply that the nature of the instance of real data is somehow modified.
This line of code, if possible, wouldn't introduce the Triple type.
typeof(Double).Name = "Triple";
var IGotATriple = new Triple();
If you want to alter values, you need to just make another object with that information and bind to that. Metadata is compiled in. If you change it after a part is loaded, it doesn't change anything in the part's source, so you'd be lying. (unless you're going to have access to the source-code and you change it there and recompile).
Let's look at an example:
[Export(typeof(IPart))]
[ExportMetadata("Part Name","Gearbox")]
[ExportMetadata("Part Number","123")]
[PartCreationPolicy(CreationPolicy.NonShared)]
public class GearBoxPart : Part { public double GearRatio ... }
Now, let's assume that you had a UI that showed available parts and their numbers. Now, the manufacturer changes the part number for whatever reason and you want to update it. If this is possible, you might want to consider storing part number in a manifest or database instead. Alternatively you'd have to recompile every time a part number changes.
Recompile is possible. You have a controller UI that does the above, but instead of updating the metadata, you submit a request to rebuild the part's codefile. The request would be handled by parsing the codefile, replacing the part number, then sending off for a batch recompile and redistribute the new dll. That's a lot of work for nothing IMO.
So, you setup a database. Then you change the object metadata to this.
[ExportMetadata("OurCompanyNamePartNumber","123")]
Then you have a database/manifest/xml that maps your unique permanent static part number that your company devises to the current part number. Modifications in your control UI update the database/manifest/xml.
<PartMap>
<PartMapEntry OurCompanyNamePartNumber="123" ManufacturerPartNumber="456"/>
...
</PartMap>
Then the end-user UI does lookups for the part by manufacturer part number, and the mef code looks in the PartMap to get the mef part number.

Locate parent folder of NotesDocument instance

Attempting to locate the parent folder/view of a given instance of the NotesDocument class within a C# application using the Domino interop.
The goal is to use the AllDocuments property on the NotesDatabase and then ignore any documents which have been discarded by the user. It appears the AllDocuments view returns documents which were deleted out of the $Trash and thus remain within the database as a point of reference; I want to ignore those documents. In addition ParentView and ParentDocumentUNID are both null.

When you say "deleted out of the $Trash" do you refer to soft-deleted documents that appear in the $Trash or hard-deleted documents that have left deletion stubs?
Assuming that through the interop you have access to the mentioned properties:
For soft-deleted documents, FolderReferences might help. However it requires the database to have the $FolderInfo and $FolderRefInfo hidden views.
Hard deleted documents (deletion stubs) should only appear in the AllDocuments NotesDocumentCollection if they were deleted after you obtained the collection. In this case IsDeleted NotesDocument property might help.
ParentDocumentUNID returns empty string for documents that are not responses, it has nothing to do with deletion though. ParentView returns the view the document was retrieved from, in this case Nothing, because the document was not retrieved from a view.