.NET Scripting with TeamSite

System

Has anyone had success in using .Net to script for TeamSite? We have been using perl for all TeamSite scripting and would like to get away from using perl since we don't carry very many people with perl expertise.

Migrateduser

I have been working with TeamSite for about three years (since 4.2), mostly in Perl. I have done two projects with C#/.NET and TeamSite 5.5.2. I thought both were highly successful. For one thing, Visual Studio .NET is probably the best IDE I have ever worked with. For another, having a compiled environment, strong typing and especially objects were invaluable. These tools provide a level of productivity that cannot be matched with Perl. I also believe the performance is better with compiled code, though in most environments this is negligible. XML parsing (even DCRs) is very easy in .NET and Java and I like the .NET convention of XML documentation better than the PerlDoc format. Finally, the integration of the .NET framework with Windows and especially SQL Server is much better than Perl.

There were three main components to each project. The first was a .NET DLL that provided an API to TeamSite functionality (basically representing files, workflow tasks and jobs, etc. as objects and calling the command line tools to take actions on them). The second were .NET executables, one of which was used to call classes in the DLL to perform ExternalTask processing during workflow, others for templating inlines, etc. The third were ASPX pages to replace or extend TeamSite UI functionality.

The first project was the best TeamSite implementation I have ever worked on. In addition to the DLL I was able to develop five highly complex workflows (all of which used the same core code for the approval sequence), several ExternalTask processes, a template and a few other smaller things in less than three months. We actually replaced the .wft files with ASPX pages that would call into the DLL to generate and instantiate workflow job XML. The only Perl on the project was that embedded in presentation templates and custom menu items that were basically stubs to .NET code. Developing workflows (along with representing files on the Y: drive as objects) was one of the places where an object-oriented approach provided an advantage I would refer to as an order of magnitude higher than Perl. It was also so nice to get away from the Interwoven UI (for instance, have links to ASPX pages in email messages to perform functions rather than to the Interwoven servlets).

At the project I am on now we are doing everything with Java instead of .NET. While I have access to OpenAPI in Java, I am not using it at all, as the command line tools are adequate. I really prefer C# to Java.

Please let me know if you have any additional questions or if there is anything else I can do to help with your project. I am highly interested in helping Interwoven customers move away from Perl. At the last user group here in Portland, OR, Interwoven indicated that they are also trying to reduce their customers' reliance on Perl.