Bug 7914 - MonoDevelop changes csproj unnecessarily
Summary: MonoDevelop changes csproj unnecessarily
Alias: None
Product: Xamarin Studio
Classification: Desktop
Component: Project Model ()
Version: 3.0.x
Hardware: Macintosh Mac OS
: --- normal
Target Milestone: ---
Assignee: Lluis Sanchez
: 4490 ()
Depends on:
Reported: 2012-10-20 22:32 UTC by David Fowler
Modified: 2013-02-11 16:58 UTC (History)
4 users (show)

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

Example diff of a project after editing in Monodevelop. (128.20 KB, image/png)
2012-10-20 22:32 UTC, David Fowler
First pass patch (20.83 KB, patch)
2013-02-10 20:27 UTC, Mikayla Hutchinson [MSFT]

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 David Fowler 2012-10-20 22:32:27 UTC
Created attachment 2767 [details]
Example diff of a project after editing in Monodevelop.

When developing SignalR in mono develop on OSX, it aggressively tries to make changes to the csproj file that end up making no functional difference to the project.

- It tries to turn instances of lowercase "true" into "True". 
- It also removes the target framework version and target framework profile properties from the project file (Example 2 below).
- It also reorders assembly references in the csproj to be in a specific order.

Example 1:

+    <DebugSymbols>True</DebugSymbols>
-    <Optimize>false</Optimize>
+    <Optimize>False</Optimize>

The above is the git diff after it tried to change one project file.

Example 2:

- <TargetFrameworkVersion>v4.0</TargetFrameworkVersion>
-    <TargetFrameworkProfile>
-    </TargetFrameworkProfile>

These changes make it hard to work in both Visual Studio (I'm using 2012) and MonoDevelop. When MonoDevelop opens a csproj file, it should do its best to keep all formatting intact so that there isn't source control churn. Every time I make a change that ends up touching a project file it applies one or more of these changes.
Comment 1 Andres G. Aragoneses 2012-10-21 11:54:38 UTC
This is a dupe (or just very related) of bug 4490.
Comment 2 Tom Spilman 2013-02-10 17:32:18 UTC
I can verify at least the changes to the Booleans.

I suspect this other bug:


Was the cause behind uppercase booleans appearing in project files.

This really makes a mess of things in a project.  

Can we get someone to raise the priority on this issue?
Comment 3 Mikayla Hutchinson [MSFT] 2013-02-10 20:27:44 UTC
Created attachment 3354 [details]
First pass patch

Here is first pass patch that:
1) switches back the default case of MSBuild bool properties to lowercase
2) preserves case of existing MSBuild bool properties when serializing
3) continues to use Titlecase for bools in MD-specific csproj and sln sections
4) continues to use Titlecase for MSBuild item metadata, since I think VS uses Titlecase for these too
5) avoids removing existing TargetFramework* properties even if they have the default value
6) continues to avoid adding TargetFramework* properties with the default value

I'm not sure whether 3 & 4 are the right thing to do but it was easier to leave them as they are for now in order to lander the other improvements sooner.

Lluis, could you review it?
Comment 4 Mikayla Hutchinson [MSFT] 2013-02-10 20:36:46 UTC
Note - in the original example, it's not "reordering" the references, it's removing "System.XML" and and adding "System.Xml".

This is the result of a bug in the VS templates and we have workaround logic to handle loading it, but I'm not going to add logic to preserve the original buggy value.
Comment 5 Mikayla Hutchinson [MSFT] 2013-02-10 20:43:02 UTC
*** Bug 4490 has been marked as a duplicate of this bug. ***
Comment 6 Mikayla Hutchinson [MSFT] 2013-02-11 16:58:41 UTC