Versioning of AddIns and threading

This is another re-start of an email conversation.  Even though this has direct ties to the other thread I just started I'd like to discuss it seperately to avoid making these things even more confusing!  I'm also going to discuss a different part of our system to help keep them seperate, though the same issue will exist in all areas that we use VSTA.

Part of our to-be system involves the creation of text files that are sent out of the system and consumed by external systems.  The creation of these files, their data formats, record types, data types and actual data in each field need to be managed by a non-IT group. This is where VSTA comes in.  We have a DownloadFile object that has a number of properties, methods and collections that allows it to take in a set of data along with a temlpate and generate the text file in what ever format and style the template prescribes.  Of course, the logic in these events is going to be in an AddIn so the non-IT group can manage the behavior and business rules that dictate where to get the data for each field, whether or not to create certain records, etc.  This means that for every File Template we will have one AddIn dll.  For the purposes of this conversation we'll assume this AddIn has just one Host Object and no Host Items.

Another aspect of this is our support of versioning for File Templates.  So, if we have two versions of the same template and both are being used at the same time, they would have their own AddIns because we would potentially need different business rules for the second version.

At run-time we will instantiate a DownloadFile class, which is our HostItem and load the specified FileTemplate into it (let's call it Version 1).  This temlpate name and version number will be used to loate the matching AddIn dll and load it.  Then we will kick off the code in the DownloadFile class to build the text file.  In the process of building this file, several events will be raised and the AddIn code will handle them by setting properties of the Host Item and manipulating data in the EventArgs objects that are being passed in the event.

Before this process completes we may get a request to build another file using the same template and version, but using different data.  We would go through the same process, loading the same AddIn (because we are using version 1) and starting the logic again.

In our past use of VSA to do this type of thing, we had threading issues that forced us to "lock" the AddIn dll (not call an addin, but basically the same concept) and only allow one process in at a time.  This was to prevent them from stepping on each other's data that was passed in and out of the AddIn.

Will this scenario work in a multi-threaded world without locking the AddIns?  Will it be necessary to load each instance of the AddIn into a seperate process to get the isolation we need?

I have other questions relating to versioning AddIn's but I think it's important to get this basic stuff out of the way first.

Thx.

Terry,

It shouldn’t be an issue for two processes to use the same add-in assembly.  One add-in can be loaded and used by more than one process or multiple times in the same process.  Any process using the add-in will lock it to editing, so the add-in could be loaded but it shouldn’t be displayed in the IDE for editing. 

Here’s the testing I did to ensure this, if I am missing something please let me know.  This testing was done using the ShapeAppBasicCSharp unmodified load add-in method which loads the add-in into a new app domain.

IEntryPoint addIn = addInToken[0].Activate<IEntryPoint>(AddInSecurityLevel.FullTrust);

Test multiple threads using the same add-in:

1)      1)  Create an add-in:

Private Sub AppAddIn_Startup(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Startup

    System.Windows.Forms.MessageBox.Show("hello world!")

    AddHandler Me.ActiveDrawing.ShapeAdded, New AddedEventHandler(AddressOf ActiveDrawing_ShapeAdded)

End Sub

Private Sub ActiveDrawing_ShapeAdded(ByVal sender As Object, ByVal e As AddedEventArgs)

    System.Windows.Forms.MessageBox.Show("shape added! Number of shapes: " & Me.ActiveDrawing.Shapes.Count)

    Dim shapeAdded As IShape = CType(e.AddedItem, IShape)

    shapeAdded.Color = Application.CreateColor(System.Drawing.Color.SkyBlue.ToArgb())

End Sub

2)      2)  Run two instances of the ShapeAppCSharp application

3)      3)  Add a different number of shapes to each instance of the ShapeAppCSharp application

Result:  Message boxes were displayed showing the correct number of shapes for each instance of the application with the add-in loaded.

Hope this helps, please let me know if you have any questions.
Thanks!
-Melody

Thanks.  I agree that proves there are no issues running two at once.  I guess when you think about it, the AddIn has not real data or "context" information in it so it would make sense that it would be inherently thread safe.

Now to the comments about locking for editing.  I suppose what this means is that the Dll is locked once it's loaded and can't be modified until no vsta.exe has it loaded.  This would suggest that I should be doing an Unload of the AddIn when I'm done with it each time, even if I'm going to be re-loading it soon afterward.  This would also go for seperate processes loading the same AddIn since they are all pointing to the same physical DLL (probably, though not necessarilly).

>>I suppose what this means is that the Dll is locked once it's loaded and can't be modified until no vsta.exe has it loaded.  This would suggest that I should be doing an Unload of the AddIn when I'm done with it each time, even if I'm going to be re-loading it soon afterward.  This would also go for seperate processes loading the same AddIn since they are all pointing to the same physical DLL (probably, though not necessarilly).

Yes, that is correct -- release the add-in, modify, reload.