tag:support.appharbor.com,2010-11-23:/discussions/problems/92-need-support-for-multiple-solutions-badlyAppHarbor: Discussion 2011-04-08T03:50:20Ztag:support.appharbor.com,2010-11-23:Comment/49172832011-01-24T22:43:39Z2011-01-24T22:43:39ZNeed support for multiple solutions badly.<div><p>We have thought about what to do in this scenario. One thing we
would like to avoid is configuration, primarily because it makes it
more difficult to use and can cause unintended side-effects (say
you rename the solutions, the next push will cause it to fail,
until you change the configuration).</p>
<p>Can you tell me both why your repository include more than a
single solution and what the structure looks like? I guess we could
alter the algorithm to look for the shortest name solution file
closest to the root of the repository. Would that solve the issue
for you? In case it's multiple versions of the same solution
(Visual Studio 2008/2010), we could perhaps look for the newest of
them.</p></div>tttag:support.appharbor.com,2010-11-23:Comment/49172832011-01-25T12:36:21Z2011-01-25T12:36:49ZNeed support for multiple solutions badly.<div><p>Hi Troels,</p>
<p>thanks for your answer.</p>
<p>I can see your point with not wanting to handle configuration.
But at the same time, if it enables an important use case that
would otherwise not be supported, it is maybe worth thinking about.
You could do something else, like sorting on the solution names and
taking the first one, or looking at the length of the solution
names, but I would say that such an approach is far worse then
working with a conf file. If you impose any of those rules, my
naming of the solutions would be governed by the fact that I chose
to use AppHarbor for running my web app, which is obviously a bad
consequence.</p>
<p>From my perspective, multiple solutions in one repository is
quite common. VS was never really designed to handle large
solutions (something you will notice when trying to work with a
solution that includes 20 or more projects). For me, solutions are
different views of the code base and a way to structure the
code.</p>
<p>In this particular case I have a library with logic. This
library is used both from a desktop app and from a web app. Now,
having these three projects in the same solution will not work
because AppHarbor doesn't manage to build the desktop app,
rendering an error when trying. Failing to build the desktop app is
OK, but this means that I have to have multiple solutions to handle
the situation.</p>
<p>Also, if you have test projects, all of the tests will be
executed when pushing to AppHarbor. This is not a desirable
behavior I would say.</p>
<p>Regards Björn<br>
Regardless of why you would want to support multiple solutions,
from my view it is an important and very common use case.</p></div>bjomitag:support.appharbor.com,2010-11-23:Comment/49172832011-01-26T08:28:41Z2011-01-26T08:28:41ZNeed support for multiple solutions badly.<div><p>Say you'd accept having a configuration file inside your
repository that defines which solution to build. Could this
configuration be a solution file, with a specific name?</p>
<p>My thoughts are this:<br>
If we require a configuration name with a special name that ties
your repository to AppHarbor, we might as well use Visual Studio's
format as it is easy to include the projects you'd like us to build
and run tests for. The solution doesn't affect your "views", so you
can structure everything else as you please.</p>
<p>So the logic would be something like this:<br>
If you have zero solution files, we treat the repository as a
WebMatrix site.<br>
If you have a single solution file, we use that one.<br>
If you've got multiple solution files, we look for
"AppHarbor.sln".</p></div>tttag:support.appharbor.com,2010-11-23:Comment/49172832011-01-26T16:29:46Z2011-01-26T16:29:48ZNeed support for multiple solutions badly.<div><p>That would absolutely work. Sounds like a good idea.</p></div>bjomitag:support.appharbor.com,2010-11-23:Comment/49172832011-01-27T02:39:52Z2011-01-27T02:39:52ZNeed support for multiple solutions badly.<div><p>I have just pushed support for this. If there is multiple
solutions and one of them is named "AppHarbor.sln", we'll use that
one.</p></div>tt