Ideas for STSDEV

Mar 25, 2008 at 8:56 PM
First, thanks for the awesome tool. You've addressed one of my most painful pain points!!

I'd love to see some of STSDEV's great functionality packaged up in a VS Addin or Extension:

The Addin or Extension would have a tool bar with the following buttons: New Solution, Deploy, Retract, Upgrade, etc. This way the New Solution button could create the solution and then ask the user if they wanted to open the solution (which I guess they would 99% of the time).

The Addin/Extension could also handle the updating of the ddf and manifest files whenever a file was added/deleted or, at a minimum, when the project was built (just like you're doing it now).

I don't like the fact that I have to select a build configuration for every action I want to perform (e.g. retract, deploy, etc.). That is why I think that toolbar buttons (e.g. deploy, retract, etc.) would work so much better. If you separate the action (e.g. retract, deploy) from the build configuration (e.g. release vs. debug) you would be able to deploy, updgrade, install release or debug builds (and any other special configurations a developer may come up with).

A friend of mine had the great idea that it would be cool if the user could specify different environments (e.g. a production environment, one for test, one for dev) so that you could deploy to production or to test or to development all from within the IDE.

So it sounds like there are three variables at play:

1) environment - production, test, development, etc.
2) configuration - release, debug, etc.
3) action to perform - retract, deploy, upgrade, install, build, etc.

One possible UI for this would be a toolbar with a combo box that contained the environments along with a button to manage the environments (e.g. add, edit, delete) and then buttons for each of the actions to perform.

It would also be great if you could specify an environment, configuration, and action to perform via MSBuild too. Perhaps it already does some of this?

One challenge I see with the multiple environments is figuring out how to store them in a place where they can be shared with other developers. All developers might deploy to the same testing and production environments, but each developer has their own development environment so you'd probably want to make the development environment not shared between developers. I'm going to check out the new "Professional Visual Studio Extensibility" book and see how easy/difficult these tasks would be.