Bug 3642 - Better support multiple projects in addin templates
Summary: Better support multiple projects in addin templates
Alias: None
Product: Xamarin Studio
Classification: Desktop
Component: Project Model ()
Version: unspecified
Hardware: PC Mac OS
: Normal normal
Target Milestone: ---
Assignee: Lluis Sanchez
Depends on:
Reported: 2012-02-25 01:00 UTC by Curtis Wensley
Modified: 2015-07-02 10:41 UTC (History)
2 users (show)

Is this bug a regression?: ---
Last known good build:

Sample template with multiple projects (1.40 KB, text/xml)
2012-02-25 01:13 UTC, Curtis Wensley

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.

Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:

Description Curtis Wensley 2012-02-25 01:00:11 UTC
Right now, if you define multiple projects in a template, each project gets the same Assembly Name and Output Directory - basically making it so you can only have one project in a template for it to be usable.

It would be nice to have the ability to have multiple projects in a template.  Each project could then have references to others in the same solution.  The project name(s) should be able to be unique or based on the user-entered project name when creating the solution.

I've taken a stab at doing this, and it works really well.  It deals with whether or not the user checks the 'Create directory for solution' or not as well.

Here is the patch:


If you like, I will submit a pull request.
Comment 1 Curtis Wensley 2012-02-25 01:13:20 UTC
Created attachment 1421 [details]
Sample template with multiple projects

This can be used to test out the new features.  It creates a library project, and an executable project that references the library project.
Comment 2 Mikayla Hutchinson [MSFT] 2012-02-27 12:15:09 UTC
How exactly does the directory attribute interact with the "create directory for solution" option? Might it not make more sense to have <Directory name="foo"> elements? Also, tabs/spaces indentation is a little inconsistent - please use tabs.

Apart from that, it looks good.
Comment 3 Curtis Wensley 2012-02-27 13:17:35 UTC
The directory attribute will make it create sub-directories off of the solution directory, regardless if the user selected 'create directory for solution'.. 

for example, with 'create directory' on, using the attached template:

--MyProject/(Other main project files)
--MyProject.Project2/(Other project2 files)

With 'create directory' turned off:

(Other base project files)
--MyProject.Project2/(Other project2 files)

if the directory is '.' or not specified, then it will behave like it did before - where all projects go in the same directory, however the assembly name will be correctly specified for each so it will compile/run as opposed to before.

I could have made a directory element, but I was trying to be consistent with the directory attribute that's used on the Combine tag (SolutionDescriptor.cs).

I guess it picked up the spaces because I initially copied that code from SolutionDescriptor.cs, which uses spaces.  I've fixed that now, and submitted a pull request: 

Comment 4 Mikayla Hutchinson [MSFT] 2012-02-27 13:34:31 UTC
That doesn't seem right, with 'create directory' turned off shouldn't it be:

My thought with the Directory element is that it would be consistent with what we do for the files within the projects. I didn't realize that Combine has a directory attribute, not sure what the purpose of that is or whether anyone even uses it. It probably goes back to when we supported nested solutions.

Maybe the attribute is best, elements might be better suited to handling Solution Folders, which don't have to map to the on-disk layout.
Comment 5 Curtis Wensley 2012-02-27 13:42:15 UTC
Hm, you have a point about the directory structure.  I thought it was weird though to have the .sln in MyProject/MyProject.sln, but referencing a project that is outside of its directory..

I can make the change if needed.
Comment 6 Miguel de Icaza [MSFT] 2012-04-24 12:16:04 UTC
Curtis, we would appreciate if you made that change.
Comment 7 Lluis Sanchez 2015-07-02 10:41:45 UTC
We already support multiple projects with different names in a solution template.