Package Creator API - VS DTE powershell commands

Sep 1, 2010 at 6:25 PM

So, I was thinking about the pain I went through writting the Solution Factory tool and I see the biggest value add for package creators is making it really easy to do all of the COM interopt with the DTE.  so I can see a number of task based powershell commands that are meant for package creators to use.. these would be commands like..

  •  add file to project,
  • create new project,
  •  change project item build type
  • adding to the project files, pre and post build steps.
  • .... ect.

  Is this something you all have thought about.? 

 

 

 

Sep 1, 2010 at 6:28 PM
hell's yeah!!

and some built in prompt's

$answer = Ask-User "What is your name?"
ala - thor: http://github.com/wycats/thor
(scroll down)

-d

On Wed, Sep 1, 2010 at 1:25 PM, erichexter <notifications@codeplex.com> wrote:

From: erichexter

So, I was thinking about the pain I went through writting the Solution Factory tool and I see the biggest value add for package creators is making it really easy to do all of the COM interopt with the DTE.  so I can see a number of task based powershell commands that are meant for package creators to use.. these would be commands like..

  •  add file to project,
  • create new project,
  •  change project item build type
  • adding to the project files, pre and post build steps.
  • .... ect.

  Is this something you all have thought about.? 

 

 

 

Read the full discussion online.

To add a post to this discussion, reply to this email (nupack@discussions.codeplex.com)

To start a new discussion for this project, email nupack@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com


Sep 1, 2010 at 6:59 PM

Yup, definitely something that has been discussed.  We will come up with the right list of command as we need them when we build sample packages like the MvcScaffold I demoed yesterday.

Sep 2, 2010 at 12:55 AM

Should I create an Issue or a wiki page to start collecting ideas?

Editor
Sep 2, 2010 at 12:59 AM
I think we want to avoid interactive prompts.

--
Scott Hanselman - Tiny keyboard, tiny email - Sent from some kind of phone

On Sep 1, 2010, at 11:29 AM, drusellers <notifications@codeplex.com> wrote:

From: drusellers

hell's yeah!!

and some built in prompt's

$answer = Ask-User "What is your name?"
ala - thor: http://github.com/wycats/thor
(scroll down)

-d

On Wed, Sep 1, 2010 at 1:25 PM, erichexter <notifications@codeplex.com> wrote:

From: erichexter

So, I was thinking about the pain I went through writting the Solution Factory tool and I see the biggest value add for package creators is making it really easy to do all of the COM interopt with the DTE. so I can see a number of task based powershell commands that are meant for package creators to use.. these would be commands like..

  • add file to project,
  • create new project,
  • change project item build type
  • adding to the project files, pre and post build steps.
  • .... ect.

Is this something you all have thought about.?

Read the full discussion online.

To add a post to this discussion, reply to this email (nupack@discussions.codeplex.com)

To start a new discussion for this project, email nupack@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com


Sep 2, 2010 at 1:02 AM

Maybe a wiki page until we come up with a more concrete design.  We should reserve 'issues' for things that are more or less ready to be worked on.  But either way, there is more than one 'right' way of doing things :)

Sep 2, 2010 at 9:36 PM

I agree about the interactive prompts.. if a prompt is needed a package author can make that part of the powershell command and make the parameters required.  I guess this breaks down if you needed to prompt from the add package invocation.

Sep 9, 2010 at 3:01 AM

I created a wiki page as a home for potential commands to implement http://nupack.codeplex.com/wikipage?title=Visual%20Studio%20Powershell%20API

Sep 9, 2010 at 3:49 AM
erichexter wrote:

I created a wiki page as a home for potential commands to implement http://nupack.codeplex.com/wikipage?title=Visual%20Studio%20Powershell%20API

Are some of these things that should be in PowerConsole itself? I'm not seeing why they should be in NuPack (don't get wrong, some of them are great) and worried about scope creep on this project stepping outside it's boundaries. For example while Add-SolutionFolder is cool, what's it got to do with packaging?

Sep 9, 2010 at 7:04 AM

Yes, those are technically orthogonal to NuPack.  It's just a helpful thing that we can provide on the side, but that is not directly in the core.

Sep 9, 2010 at 11:07 AM

While I agree this is orthagonal.  I believe that if we are ever going to take the .Net community from continually rebuilding plumbing to building on top of what Shanselman described as the right sized lego pieces, we need to take away the pain of automating visual studio.  I could see this being a seperate package and not part of core, but I believe if this is really going to work well, the project team / testing should be done by the core team.  I have done a lot of VS automation and there are a lot of tricks to making it work correctly across various project types.

Sep 9, 2010 at 1:55 PM

To follow up on the Add-solutionFolder .  I agree this has nothing to do with packaging and the delivery of packages.  The intention is to make it easy for package creators to automate visual studio. Rather then just copying dlls and some config files. They can provide some higher level helpers and mutli project packages.  I really am not sure what they may do with this. I could see a Database Migration tool adding a solution level folder for migration scripts. A deployment tool maybe.  My goal here is to reduce the authoring friction to help encourage innovation on top of the packaging infrastructure.

Coordinator
Sep 9, 2010 at 5:01 PM

We had discussed having these PS commands being encapsulated in its own package as a possibility. So you would install the MyCoolAutomateVsPackage.nupack and off you go! I think that might be the right place for these which rightly have no business elsewhere.

Sep 9, 2010 at 5:04 PM

Leveraing NuPack to install its own bits and using it to build cool new stuff is going to go a long way on street creds IMHO.

PS Eric did add a VS Solution package to the list on the wiki. GO TEAM!

Sep 9, 2010 at 6:39 PM

Agreed, that's absolutely the way to go.  These DTE Solution Helpers are a package, and any Package that needs this functionality just depends on it.  By doing this:

  • We keep things nicely componentized by not putting too much in NuPack core
  • We get to dogfood our own technology

Note that I still think we should deliver this package, as it is important.  It's just a separate piece.

Oct 8, 2010 at 12:57 PM

Adding imports to a project would be good also.

Oct 8, 2010 at 2:56 PM
Adding imports? You mean references?

-d

On Fri, Oct 8, 2010 at 7:57 AM, justinc <notifications@codeplex.com> wrote:

From: justinc

Adding imports to a project would be good also.

Read the full discussion online.

To add a post to this discussion, reply to this email (nupack@discussions.codeplex.com)

To start a new discussion for this project, email nupack@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com


Oct 8, 2010 at 3:05 PM
If you are talking about references. I have that working in solution factory, and if you did not want to depend on that project you could lift the code from the project.
 
Oct 8, 2010 at 3:09 PM
Or have we found a fellow VB.Net developer and he is referring to the default imports (shudder)
-d

On Fri, Oct 8, 2010 at 10:05 AM, erichexter <notifications@codeplex.com> wrote:

From: erichexter

If you are talking about references. I have that working in solution factory, and if you did not want to depend on that project you could lift the code from the project.
 

Read the full discussion online.

To add a post to this discussion, reply to this email (nupack@discussions.codeplex.com)

To start a new discussion for this project, email nupack@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com


Oct 8, 2010 at 4:51 PM

I think Justin means adding the <Import> element into project file to allow importing another .targets file.

Oct 9, 2010 at 1:17 PM

Yeah sorry I mean the ability to add <Import Project="xyz" /> Commands.

Specifically if your package contains assemblies with MSBuild tasks and targets files, you want to put them into the /Tools folder then add an import to the targets file. I actually have a prototype of this working in a fork I made:

http://nupack.codeplex.com/SourceControl/network/Forks/justinc/MetaSharpNuPack/changeset/changes/eb674f3faee4

 

Jan 12, 2011 at 10:17 PM

Has there been any progress on this? I have the Append-Import command prototype above in a fork but I'm not totally sure I have done it in the correct way. If these other commands discussed have been done already I could follow them as a prototype. I actually have to do a pull and probably some merging but I was held up by some bugs before and would like to give it a second shot now.