STSDEV, the Anti-Pattern

Apr 24, 2008 at 1:06 PM
Is it just me, or is STSDEV only intended for small projects? I love the idea of having STSDEV manage my metadata via the solution config, but it's rendered nearly useless due to my project structure. I'm working with several different projects that contain core business logic, web content, and services. Apparently, STSDEV thinks I need to merge all of these into one for it to work. That's just not going to happen, tho. This goes against key patterns and practices I don't feel like I should have to sacrifice for SharePoint.

I'm going to keep STSDEV, but I've commented out the refresh portion of the build script. I'm hoping a future release will take larger scale patterns into consideration. There's no reason the tool should assume a single-project solution and multi-solution application development projects. This just screams of acedemia. If I had time, I'd try to fix the tool, but it just seems like the tool would have to be completely rewritten to do what it needs to.
Coordinator
Apr 29, 2008 at 7:02 PM
As it currently stands, STSDev is a proof of concept. It is a demonstration of what is possible (see www.codeplex.com/stsdev). There are plans for a new version that will take some of your comments into account, but understand that unless you build the perfect tool for exactly the patterns and practices you favor/support and to follow the development model you are comfortable with, then no tool will meet your exact needs. If you are interested in helping to move this project forward, then please feel free to contact me (user id: dmann). We would love to have more help on the next version.

Dave



flanakin wrote:
Is it just me, or is STSDEV only intended for small projects? I love the idea of having STSDEV manage my metadata via the solution config, but it's rendered nearly useless due to my project structure. I'm working with several different projects that contain core business logic, web content, and services. Apparently, STSDEV thinks I need to merge all of these into one for it to work. That's just not going to happen, tho. This goes against key patterns and practices I don't feel like I should have to sacrifice for SharePoint.

I'm going to keep STSDEV, but I've commented out the refresh portion of the build script. I'm hoping a future release will take larger scale patterns into consideration. There's no reason the tool should assume a single-project solution and multi-solution application development projects. This just screams of acedemia. If I had time, I'd try to fix the tool, but it just seems like the tool would have to be completely rewritten to do what it needs to.

May 1, 2008 at 1:18 AM
I've been able to use STSDev in a single solution, multi-project scenario. I have a "feature" project that houses the STSDev build targets, my elements files, aspx pages etc. From the feature project I reference other projects. For instance, I have a workflow project, a utilities project, a shared project, etc. After referencing the other projects you can update your SolutionConfig.xml file to add the referenced assemblies to the solution package. I've been developing with this solution structure for about a month and so far it is working pretty good.