4

We have a solution file with multiple Apps for multiple platforms. There are 10 projects which may be selected as default startup project while developing a user story. Unfortunately the StartupItem is stored in the sln file and hence causes undesired merges in our version control system (or worse: collisions). As I understand, Visual Studio has an .suo file to store these kind of settings per user.

Why does Xamarin Studio store the StartupItem in the sln file? Is there support for suo files? Or is there any other workaround for this commit ping-pong?

Falko
  • 17,076
  • 13
  • 60
  • 105
Rodja
  • 7,998
  • 8
  • 48
  • 55
  • isn't the startup item for VS stored in the .suo file (*not* the sln), which contains other user preferences like for debnugging etc, and is a binary file, and hence should preferrably not be in version control? – stijn Jul 10 '14 at 06:44
  • You are right. I need this to work with Xamarin Studio an clarified the question. – Rodja Jul 20 '14 at 10:46

3 Answers3

3

In case you are using Git as a version control system you can easily define filters for specific files as indicated in this answer:

  1. Define a new filter *.sln filter=startupitem in a local .gitattributes file or globally in .git/info/attributes.
  2. Define the behaviour of this filter via git config filter.startupitem.clean "sed '/StartupItem\ =\ .*.csproj/'d" on the command line. (You can use the --global option as well.)

Git will still list the solution file as uncommitted changes. But when adding the file to the stage, the filter is applied and the line vanishes.

After checkout this line is missing and Xamarin sets some default startup project. From now on you can switch the project without checking in your choice. Xamarin will only locally add the line back to the *.sln file.

Community
  • 1
  • 1
Falko
  • 17,076
  • 13
  • 60
  • 105
1

Just a note - Xamarin has fixed this in version 5.7:

http://developer.xamarin.com/releases/studio/xamarin.studio_5.7/xamarin.studio_5.7/

From the release notes: "The startup project name is now stored in the user solution settings file instead of the .sln file."

So >= v 5.7 no filters or anything special should be needed.

Nate Rickard
  • 652
  • 8
  • 14
0

One solution is to review file-by-file changes to files as you checkin. Thus unless new projects have been added there should be no checkins of the solution file.

The next level which we do at work is to build the solution file using premake. Thus we no longer checkin the .sln or .vcproj files as these are auto built after checkout. This solution was to solve the fact out project file changed a lot and so e development centers didn't listen to the first rule of "check your changes"

Simeon Pilgrim
  • 22,906
  • 3
  • 32
  • 45