Need support for multiple solutions badly.
Hi,
support for multiple solutions in one repository would be very nice. In fact, for me it is vital that you add support for such a scenario.
Some kind of simple configuration file where you can specify which solution you should look at might be the answer?
Regards Björn Milton
Discussions are closed to public comments.
If you need help with AppHarbor please
start a new discussion.
Keyboard shortcuts
Generic
| ? | Show this help |
|---|---|
| ESC | Blurs the current field |
Comment Form
| r | Focus the comment reply box |
|---|---|
| ^ + ↩ | Submit the comment |
You can use Command ⌘ instead of Control ^ on Mac
Support Staff 1 Posted by tt on 24 Jan, 2011 10:43 PM
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).
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.
2 Posted by bjomi on 25 Jan, 2011 12:36 PM
Hi Troels,
thanks for your answer.
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.
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.
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.
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.
Regards Björn
Regardless of why you would want to support multiple solutions, from my view it is an important and very common use case.
Support Staff 3 Posted by tt on 26 Jan, 2011 08:28 AM
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?
My thoughts are this:
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.
So the logic would be something like this:
If you have zero solution files, we treat the repository as a WebMatrix site.
If you have a single solution file, we use that one.
If you've got multiple solution files, we look for "AppHarbor.sln".
4 Posted by bjomi on 26 Jan, 2011 04:29 PM
That would absolutely work. Sounds like a good idea.
Support Staff 5 Posted by tt on 27 Jan, 2011 02:39 AM
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.
tt closed this discussion on 27 Jan, 2011 02:39 AM.