Why make packages.xml visible in VS?

Sep 27, 2010 at 2:42 AM

Do we want to make packages.xml visible in VS? I'm curious what the upside is? The downside is the user is more likely to meddle.

Coordinator
Sep 27, 2010 at 3:35 AM
One upside is source control integration. That's a file that rightly belongs in your project. Can we make it not visible yet still part of your csproj?
Sep 27, 2010 at 3:57 AM

No, I don't think hiding it is possible.  Source control is indeed the reason to have it in there.

Oct 7, 2010 at 4:47 AM
Edited Oct 7, 2010 at 4:48 AM

Just because a file belongs in your "project", and therefore versioned, that doesn't mean that it needs to be a part of your csproj file, does it?

If it must be included, what about filing it away in a /Packages folder in the project, just like the AssemblyInfo.cs is filed away in the Properties folder? or can the packages.xml file be filed _in_ the Properties folder?

Oct 7, 2010 at 9:07 AM

Actually, I think it does mean that.  Any file in the project has an entry in the csproj (unless there are exceptions I don't know about!).

Putting it in a Packages folder is possible, but that still adds one 'entry' top level.  It's just a folder instead of a file, but it's not all that different IMO.

The Properties folder might be interesting to look into.

Developer
Oct 7, 2010 at 9:32 AM

It has to be per project. Think of that file as the References node in the VS solution explorer

Oct 7, 2010 at 10:53 AM

Since the packages file is just xml, is there any reason that xml cant be in the csproj file it self?

Oct 7, 2010 at 11:46 AM

I don't think putting it into the csproj file is the right approach. It's an external entity and while it exists as an artifact in the project, going in and messing with the csproj file just opens up a whole 'nuther can of worms. It would need to either be the csproj or the vbproj, there's version issues if/when the schema for project files changes, it would have to be a visual studio thing not a core thing because we don't want to make the core incompatible with mono, sharepdevelop, etc.

I think we should spike out the properties folder though. Since it's per project (and there has been talk of a system wide settings file too) it makes sense as the Properties folder is always there in any project type and well, it sounds like these are properties for a project, just like any regular assembly reference.

Oct 7, 2010 at 11:48 AM

What the story for Web Sites, if any, since these lack project files and Properties folders?

Oct 7, 2010 at 12:21 PM
bsimser wrote:

I don't think putting it into the csproj file is the right approach. It's an external entity and while it exists as an artifact in the project, going in and messing with the csproj file just opens up a whole 'nuther can of worms. It would need to either be the csproj or the vbproj, there's version issues if/when the schema for project files changes, it would have to be a visual studio thing not a core thing because we don't want to make the core incompatible with mono, sharepdevelop, etc.

I think we should spike out the properties folder though. Since it's per project (and there has been talk of a system wide settings file too) it makes sense as the Properties folder is always there in any project type and well, it sounds like these are properties for a project, just like any regular assembly reference.

 valid points, but still i think nupack is very closly related to the references and the references are int he <x>proj file :) still, moving to the Properties filder and perhaps choosing another file extension such as .nupack or something is totaly acceptable too

Oct 7, 2010 at 6:55 PM
+1000 on keep it out of the csproj file. Starting to mix concerns and for all of the reasons that Bil already mentioned. 
____
Rob
"Be passionate in all you do"

http://devlicio.us/blogs/rob_reynolds
http://ferventcoder.com
http://twitter.com/ferventcoder



Oct 7, 2010 at 7:07 PM

@ssmith: for web sites, packages.config is just another file in your site.  Even though there is no project file, source control work in web site as it follows a different model.  The bottom line is that this file is treated like other files in the project, and that holds true for both Web Sites and regular projects.

Oct 8, 2010 at 12:34 PM
+1000 on keep it out of the csproj file. Starting to mix concerns and for all of the reasons that Bil already mentioned. 

 i dont think thats more a mix on concerns than having refences and service references in the proj file.. imo packade information is conceptually metadata of a reference.

Oct 8, 2010 at 9:17 PM
Getting the libraries that you are going to reference to a local cache and actually referencing them are two different functions when you decompose the process. To me this means two different concerns. 

I'm still not sold that we actually need package information either. It's a slight duplication to me, but it does enable a couple of things that the guys want, like to know what the source of the package was so it can only go back there. Jury is still out for me on whether that is a good thing or not. 

The other mixing of concerns - I don't want a marriage of the visual studio project files and a project that is on the side b/c then you can no longer separate the two easily. Keep them uncoupled and then maintenance is separate for each. 
____
Rob
"Be passionate in all you do"

http://devlicio.us/blogs/rob_reynolds
http://ferventcoder.com
http://twitter.com/ferventcoder

Oct 9, 2010 at 12:06 PM
Edited Oct 9, 2010 at 12:07 PM

we have to agree to disagree then :)

to me nupack is doing essencially the same thing as a service reference.

  • it contacts a remote server,
  • downloads some stuff
  • adds a reference in your project

One could ofcourse argue that the VS service reference implementation is also to closley coupled to vs, but thats another story :) i'm mearly suggesting that having the nupack xml in the proj file would be consistent with the way VS does things. if the team wishes to prioritize portability, a separate file is better, however since you are going to integrate with VS and presumably other editors as well anyway, why not take that integration a step further?