Questioning the need for the solution folder

Sep 11, 2010 at 9:02 PM

[Starting a new thread to discuss a slightly different take]

So why exactly do we have the solution folder today?  Two possible reasons can be given:

  1. So users in VS see those files
  2. To make source control work

Let's look at both:

  • #1 is probably not a valid reason, since we’re talking about hiding it anyway.  Users don't need to see those files.  They just want NuPack to work.
  • #2 is only relevant in TFS.

So putting this together, we only have the solution folder to make TFS work.  And currently it doesn't even work correctly, which is what the other thread was about.

So instead of trying to abuse a Solution folder into making TFS work for us, I think we're better off following a different approach:

  • Get rid of the solution folder entirely.  It was an major abuse of that feature anyway.
  • Have separate logic to deal with TFS by directly calling the TFS APIs (without involving VS!).  TeamFoundationServerFactory seems to be the starting point.

Note that this only applies to the solution level files.  For the project level files, we can continue to do what we do today, which does rely on VS to perform TFS operations when they are needed (and works very well).

Sep 11, 2010 at 9:07 PM
Agreed.
What do you mean, but project level stuff? For example? 

On Sat, Sep 11, 2010 at 11:02 PM, davidebb <notifications@codeplex.com> wrote:

From: davidebb

[Starting a new thread to discuss a slightly different take]

So why exactly do we have the solution folder today?  Two possible reasons can be given:

  1. So users in VS see those files
  2. To make source control work

Let's look at both:

  • #1 is probably not a valid reason, since we’re talking about hiding it anyway.  Users don't need to see those files.  They just want NuPack to work.
  • #2 is only relevant in TFS.

So putting this together, we only have the solution folder to make TFS work.  And currently it doesn't even work correctly, which is what the other thread was about.

So instead of trying to abuse a Solution folder into making TFS work for us, I think we're better off following a different approach:

  • Get rid of the solution folder entirely.  It was an major abuse of that feature anyway.
  • Have separate logic to deal with TFS by directly calling the TFS APIs (without involving VS!).  TeamFoundationServerFactory seems to be the starting point.

Note that this only applies to the solution level files.  For the project level files, we can continue to do what we do today, which does rely on VS to perform TFS operations when they are needed (and works very well).

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 11, 2010 at 9:30 PM
Ayende wrote:
Agreed.
What do you mean, but project level stuff? For example? 

e.g. Static files.

Sep 12, 2010 at 9:24 AM

You make some great points here.

Coordinator
Sep 12, 2010 at 8:31 PM
Unfortunately, the solution folders for source control doesn't just apply to TFS. It applies to any source control that uses VS integration in order to apply source control.

Ex:
* sourcegear vault
* visual sourcesafe
* ankh svn/visual svn
* perforce
* etc...

Phil
>
Sep 12, 2010 at 8:38 PM

That might just mean having pluggability to let 3rd party add support for those (and most popular systems like Mercurial wouldn't need anything).  The fact is that solution folders as we are using them today simply do not work for source control (see other thread).  So we need to find some solution.

One key point I want to get out of this thread is: does anyone think that having the solution level files show up in VS has value to the users (ignoring source control)?  My take is that it doesn't, which is why we are going to hide them anyway.

 

Sep 12, 2010 at 8:40 PM
I think that they add zero value, and I was surprised when they showed up.

Moreover, I think that it is perfectly fine that even if there isn't any integration, that the user will take a step to add/remove them from SCM himself.


On Sun, Sep 12, 2010 at 9:38 PM, davidebb <notifications@codeplex.com> wrote:

From: davidebb

That might just mean having pluggability to let 3rd party add support for those (and most popular systems like Mercurial wouldn't need anything).  The fact is that solution folders as we are using them today simply do not work for source control (see other thread).  So we need to find some solution.

One key point I want to get out of this thread is: does anyone think that having the solution level files show up in VS has value to the users (ignoring source control)?  My take is that it doesn't, which is why we are going to hide them anyway.

 

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


Coordinator
Sep 12, 2010 at 9:18 PM
Mercurial might be among the most popular for package creators, but is it for consumers?

Keep in mind, our audience for using this will be much wider than OSS developers. Part of our goal is to reach the Corp devs who might not otherwise use OSS.

While many will continue to have Corp policies restrict usage of OSS, many simply don't because it's too hard to get started. Or, they'll use NuPack for their internal components. In other words, our target audience is *all* .NET devs. (think big!)

Do we have any idea what source control the broader .NET dev community is using? That would be useful info.

What happened to the custom package project type idea?
Sep 12, 2010 at 9:50 PM

Using a custom project type was a bad idea, as Eric pointed out in the other thread

"A custom project type is a option of last resort.  Having a custom project type means that in order to load a solution the project type needs to be installed on the devs system.  For this project to be successful, it has to be non invasive and I think a custom project would not be able to do this"

So the closest thing is a standard library project, which can be sort of abused as a plain file holder, but it's a hack and the overall user experience is inferior:

  • You can't hide it in VS
  • It'll still have its References and Properties pseudo-folders which are meaningless here
  • You end up with a project file that needs to be checked in

Contrast that with the experience where the user only sees the things that matter.  e.g. I add a NuPack reference to NHibernate, and all I see are the references getting added to my project.  I don't see a bunch of other crap that I don't directly care about popping up in my solution.  It's the same experience as adding a regular assembly reference, which is what we want!

Note that I'm not saying that we should ignore source control.  We will make it work in the scenarios that matter most, starting with TFS (and all the ones that are free of course).  We will get community help to cover others as they come up.

 

Sep 12, 2010 at 10:12 PM
At that point, I agree.
It is the same experience as adding normal lib.
So make the SCM experience the same. 
In other words, don't worry about it one jot.

On Sun, Sep 12, 2010 at 10:50 PM, davidebb <notifications@codeplex.com> wrote:

From: davidebb

Using a custom project type was a bad idea, as Eric pointed out in the other thread

"A custom project type is a option of last resort.  Having a custom project type means that in order to load a solution the project type needs to be installed on the devs system.  For this project to be successful, it has to be non invasive and I think a custom project would not be able to do this"

So the closest thing is a standard library project, which can be sort of abused as a plain file holder, but it's a hack and the overall user experience is inferior:

  • You can't hide it in VS
  • It'll still have its References and Properties pseudo-folders which are meaningless here
  • You end up with a project file that needs to be checked in

Contrast that with the experience where the user only sees the things that matter.  e.g. I add a NuPack reference to NHibernate, and all I see are the references getting added to my project.  I don't see a bunch of other crap that I don't directly care about popping up in my solution.  It's the same experience as adding a regular assembly reference, which is what we want!

Note that I'm not saying that we should ignore source control.  We will make it work in the scenarios that matter most, starting with TFS (and all the ones that are free of course).  We will get community help to cover others as they come up.

 

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


Coordinator
Sep 12, 2010 at 10:15 PM
I think we want a slightly better experience than adding a regular assembly reference, if we can provide it.

Having said that, I'm in agreement with what David said. Carry on. :)
Editor
Sep 12, 2010 at 10:17 PM
I tend to agree that we shouldn't bust our asses trying to make something fancy. A separate file system folder that folks manage on their own won't kill anyone.

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

On Sep 12, 2010, at 2:16 PM, "Haacked" <notifications@codeplex.com> wrote:

From: Haacked

I think we want a slightly better experience than adding a regular assembly reference, if we can provide it.

Having said that, I'm in agreement with what David said. Carry on. :)
Developer
Sep 12, 2010 at 10:21 PM
I hereby declare the death of solution folders.
Coordinator
Sep 12, 2010 at 10:24 PM
Yes. I wish I could lock this thread and say it's done. Resolved. No more responses please. Including this one.
;)