We have been using a PDM Task Add-In that I wrote that saves a pdf or dxf from Solidworks or the other CAD system we use and it's working fine, but just because it works doesn't mean it's the best way or correct way to accomplish the objective. And yes, we did start with the Solidworks add-in for the pdf and dxf from SW however I still had to make a task add-in to get pdfs and dxfs from the other CAD system, so I put them together so I could just have one action in the transitions. I do the which CAD logic in the add-in instead of workflow transition task action conditions, ie the task is ran on either CAD system drawing then the add-in reads file extension and proceeds accordingly.
In the task setup dialog (PDM Admin Tool) I have the option to save pdf or dxf, then that is saved the mpo.Extra so when I get to the OnCommand call I can read it back with GetValEx and check which to do. This is the only experience I have with writing task add-in so I don't know if it's best to put various functions all in one add-in then use the task vars at run time to select what to do or break the functions out into separate add-in dlls so each on only does one function.
Since what I have is working I would probably just leave it, but I'm about to add some more automated functionality and I cannot decide if I should make a new project in my Visual Studio Solution for a separate add-in or just keep one add-in and use the task setup dialog in the Admin Tool to choose which function is run.
As a side note I try to follow Object Oriented practices so I have several class libraries that are loaded when I add the add-in in the admin tool. Example, the API stuff for the two CAD systems are each in their own library.
Your approach looks good. I just serialize the view model of the EdmTaskSetupPage and then deserialize it back using GetValEx. Be careful not to make your PDM task a one-stop shop for every other things someone wants. I think the single responsibility principle is applicable in this case.
If you end up pushing a lot of updates like I do with custom task add-ins, it might worthwhile to start using a framework to speedup the process of developing and testing task add-ins (Because they are super annoying to write and test). Check this thing I wrote: GitHub - blue-byte-llc/BlueByte.SOLIDWORKS.PDMTaskFramework: Framework for the development of SOLIDWORKS PDM task add-in… (Keep in mind that it is work-in-progress!). It has a nice logger and it will help you debug your setup pages by loading them into a WPF hosted elementhost. You will need to mock the IEdmTaskProperties interface.
Best,
Amen
SOLIDWORKS PDM API Programming services