Writing LmdLets in C# vs .ps1

Sep 10, 2010 at 12:40 AM

Currently, our NuPack CmdLets are written in PowerShell, but we've been debating writing them in C# instead, to make it generally easier to develop (intellisense, ...).  The same could also apply to the general VS helper CmdLets we've been discussing.  So basically those CmdLets would come as a binary rather than a script (just like the built-in PS CmdLets).

Thoughts?

Editor
Sep 10, 2010 at 4:38 AM
This seems extremely low pri to me, on the surface if they mostly work now. Why prioritize this over other features?

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

On Sep 9, 2010, at 5:41 PM, "davidebb" <notifications@codeplex.com> wrote:

From: davidebb

Currently, our NuPack CmdLets are written in PowerShell, but we've been debating writing them in C# instead, to make it generally easier to develop (intellisense, ...). The same could also apply to the general VS helper CmdLets we've been discussing. So basically those CmdLets would come as a binary rather than a script (just like the built-in PS CmdLets).

Thoughts?

Sep 10, 2010 at 4:38 AM

I went through the process of writting powershell based commandlets and I like it as it forced me to learn powershell very well.  That being said. the Internal Visual Studio object model is hard.  If writting these in c# means you can also easily pull from existing VS code, than I say go for it. I also think it is easy to test C# since the project already has the unit testing infrastructure setup.  I would want to see some powershell testing put together if a large amount of code is written in powershell.

Sep 10, 2010 at 5:07 AM

Two big benefits of switching to writing cmdlets in managed code is intellisense and debugging capability. This will be a big productivity boost. Currently I pretty much write the script in Notepad2 and debug through write-debug statements.

Also, as we add more features, the script file is getting bigger and bigger everyday. It's still manageable today, but I won't be surprised if it's getting out of control down the road.

Sep 10, 2010 at 6:21 AM

Indeed, this is not about deciding whether to include a feature or not.  It is purely an implementation choice, and the reason to do this is to save coding time in the long run.  So it's not really about prioritizing this over some other feature, but more about picking the right implementation.

Sep 10, 2010 at 12:28 PM

So what I am reading from this thread is that there is no test automation strategy for the powershell scripts. It is f5 and maunally test the all the code branches.  I think you need to consider the testing strategy as part of this conversation.

Sep 10, 2010 at 12:47 PM

Two things. I see converting PS -> C# to be low priority after all the core features are delivered.

The PS cmdlets are just an abstraction over the core API and frankly if they're getting big and unwieldly that's a smell we're putting too much logic into the cmdlet and not the API. What is going into the cmdlet that is going to be missed if the user chooses to use nupack.exe or write their own UI?

I see the cmdlets as one of any number of access points to the core API. If there's logic going into cmdlets that's criticial to base functionality that sounds like core logic going into a UI to me.

Sep 10, 2010 at 5:28 PM

The two biggest logics in the script deal with tab expansion and default project concept, which do not belong to the core API. The rest of the script just calls into core API. But even with that, the script is getting big. As I said, it’s still manageable at this point. I’m just concerned over the long term.

I agree that this is lower priority than the core functionalities though. Speaking of which, we should have a document page to list all the core features that we want to do for the upcoming CTP release. Or do we already have it somewhere that I miss?

Sep 10, 2010 at 5:59 PM

We should just track features using the Issue Tracker, rather than in one big doc.

Coordinator
Sep 10, 2010 at 6:58 PM

Yeah, I haven’t had time to do this yet (I’m in the middle of a conference right now!) but all the issues which are assigned to the CTP release should be the list that we do for the next CTP. So if you have a issue that you know will be done for the next release, go ahead and assign it to that release. Thanks!

Phil

From: davidebb [mailto:notifications@codeplex.com]
Sent: Friday, September 10, 2010 10:59 AM
To: Phil Haack
Subject: Re: Writing LmdLets in C# vs .ps1 [nupack:226681]

From: davidebb

We should just track features using the Issue Tracker, rather than in one big doc.

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