S
Stephen W. Nuchia
Guest
For historical reasons mainly, and in a couple of cases functional reasons, we have a few places where multiple visual studio project files exist in a filesystem directory. The NuGet integration gets horribly confused and ends up corrupting the projects (leaving orphaned xml elements) when you make changes, including stepping to a new version of a package.
Everywhere else VS associates a file with a project the name of the file incorporates the name of the project file; eg the .user files, and this setup has been working since VC6.
I don't see any indication that the name or location can be overridden. An item is created so the packages.config file gets displayed in the tree view but it doesn't seem plausible that the integration is picking that up; it has no unique-ifying attributes.
The historical situation was that a very large project was broken up by making multiple copies of the project file and deleting subsets of the source from each, leaving them disjoint but in one folder. I can reorganize that; it won't be pleasant but it's a finite task.
The functional situation has to do with the desire to product a comprehensive product as the result of building a solution; there are some pieces of code that have to be built in more than one configuration to make that happen but there's no way to associate more than one configuration of any given project with one solution-level configuration. Hence, multiple project files for one folder full of code. I suppose I can make two subfolders and push the project files down a level there as well. Sigh.
My question here is simply this: is there a mechanism for managing the name/location of the packages.config file associated with a project file?
Stephen W. Nuchia StatSoft, Inc. Tulsa, Oklahoma USA
Continue reading...
Everywhere else VS associates a file with a project the name of the file incorporates the name of the project file; eg the .user files, and this setup has been working since VC6.
I don't see any indication that the name or location can be overridden. An item is created so the packages.config file gets displayed in the tree view but it doesn't seem plausible that the integration is picking that up; it has no unique-ifying attributes.
The historical situation was that a very large project was broken up by making multiple copies of the project file and deleting subsets of the source from each, leaving them disjoint but in one folder. I can reorganize that; it won't be pleasant but it's a finite task.
The functional situation has to do with the desire to product a comprehensive product as the result of building a solution; there are some pieces of code that have to be built in more than one configuration to make that happen but there's no way to associate more than one configuration of any given project with one solution-level configuration. Hence, multiple project files for one folder full of code. I suppose I can make two subfolders and push the project files down a level there as well. Sigh.
My question here is simply this: is there a mechanism for managing the name/location of the packages.config file associated with a project file?
Stephen W. Nuchia StatSoft, Inc. Tulsa, Oklahoma USA
Continue reading...