Are you saying that your add-in is called 100 times (once for each part) or is it actually being called 100 times for each part (10,000 times in all)?
1. Just because the file is opened in memory does not mean that it's the ActiveDoc.
2. If the document that the user is trying to open is an assembly, that assembly may contain subassemblies.
3. FileOpenPostNotify passes you the path of the file it opened. Check that string for ".sldasm" at the end.
i was saying 1 for each part for a total of 100 times. After some more experimentation i now realize that i was wrong, and the add in isn't being run 100 times. Like you said, the parts in the assembly are not being made ActiveDocs, but are still being affected. When it process the assembly it works with the ActiveDoc which in this case is the Assembly being opened, and adds properties, but for some reason the parts in the assembly are also being considered as being edited and changed, but no properties added. This is what lead me to believe that the Add in was running for each part, but was running incorrectly and causing longer load times. It seems my issue of load times are something else. So i guess, now that i have a better idea of whats going on i should revise my question to be; one, does changing/adding assembly properties in the custom and config specific properties in turn affect or change the parts in the assembly in any way; and two, is it possible that the add in could be conflicting with another add in that gets called by the FileOpenPostNotify event, causing long load times. Sorry for the confusion