Bug 51487 - Xamarin.Android does not appear to honor build determinism requests.
Summary: Xamarin.Android does not appear to honor build determinism requests.
Status: CONFIRMED
Alias: None
Product: Android
Classification: Xamarin
Component: General (show other bugs)
Version: 8.0 (15.4)
Hardware: PC Windows
: --- normal
Target Milestone: ---
Assignee: Jonathan Pryor
URL:
Depends on:
Blocks:
 
Reported: 2017-01-12 15:58 UTC by Brian Berry
Modified: 2017-06-26 19:38 UTC (History)
3 users (show)

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


Attachments
Sample solution used to verify the problem. (32.75 KB, application/zip)
2017-06-23 21:27 UTC, Tom Opgenorth
Details


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 for Bug 51487 on Developer Community or GitHub if you have new information to add and do not yet see a matching new report.

If the latest results still closely match this report, you can use the original description:

  • Export the original title and description: Developer Community HTML or GitHub Markdown
  • Copy the title and description into the new report. Adjust them to be up-to-date if needed.
  • Add your new information.

In special cases on GitHub you might also want the comments: GitHub Markdown with public comments

Related Links:
Status:
CONFIRMED

Description Brian Berry 2017-01-12 15:58:53 UTC
Found: Opt in for deterministic builds does not appear to work for Xamarin.Android.

Steps to reproduce:
    * Generate a blank solution.
    * Add a .NET Framework class library project (name CLI).
    * Add an Android class library project (name Android).
    * Add an iOS class library project (name iOS).
    * Initialize a new git repository and commit everything.

Then, for a control, iterate on the following:

    * Rebuild the solution and git commit all changes.
    * Repeat.

    ... for each iteration, you'll see that the output artifacts
    change with every build for all platforms, which is to be
    expected as build determinism is not on by default.  e.g.:

On branch master
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

        modified:   Android/bin/Debug/Android.dll
        modified:   Android/bin/Debug/Android.pdb
        modified:   CLI/bin/Debug/CLI.dll
        modified:   CLI/bin/Debug/CLI.pdb
        modified:   iOS/bin/Debug/iOS.dll
        modified:   iOS/bin/Debug/iOS.dll.mdb
        modified:   iOS/bin/Debug/iOS.pdb


Next, opt in on build determinism by manually adding:

  <PropertyGroup>
    <Deterministic>true</Deterministic>
  </PropertyGroup>

...to each of the .csproj files (top of the Project scope).

Repeat the rebuild / commit cycles (you'll see a full
change one time after the property addition, but then
a reduction in thrash subsequently).  You will then see:

On branch master
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

        modified:   Android/bin/Debug/Android.dll
        modified:   Android/bin/Debug/Android.pdb
        modified:   CLI/bin/Debug/CLI.pdb


Result:  The assemblies generated by Xamarin.Android are not
deterministic, where the others are.

(Note that PDBs may not themselves be fully guaranteed
deterministic with the opt in---a separate issue).

Expected: Deterministic binaries when requested.

Note:  This is Xamarin.Android 7.1.0.13 under VS2017RC.
I have yet to do the same experiment on macOS.
Comment 1 Brian Berry 2017-01-12 16:05:43 UTC
Note: same result under the Visual Studio for Mac preview---the Android assembly (and .dll.mdb in this case) mutate with each build.
Comment 2 Tom Opgenorth 2017-06-23 21:20:32 UTC
Can confirm that this occurs with Visual Studio for Mac. However, base on conversations with JonP in Slack, it sounds like this isn't Xamarin.Android, it's more a issue with the compilers (i.e. CSC/MCS).

Changing Product/Component of this bug.

Here are the details of my VSfM:


=== Visual Studio Enterprise 2017 for Mac ===

Version 7.0.1 (build 24)
Installation UUID: e74a38fd-e061-4610-83a0-17c4044cc365
Runtime:
	Mono 5.0.1.1 (2017-02/5077205) (64-bit)
	GTK+ 2.24.23 (Raleigh theme)

	Package version: 500010001

=== NuGet ===

Version: 4.0.0.2323

=== .NET Core ===

Runtime: /usr/local/share/dotnet/dotnet
SDK: /usr/local/share/dotnet/sdk/1.0.3/Sdks
MSBuild SDKs: /Library/Frameworks/Mono.framework/Versions/5.0.1/lib/mono/msbuild/15.0/bin/Sdks

=== Xamarin.Profiler ===

Version: 1.5.4
Location: /Applications/Xamarin Profiler.app/Contents/MacOS/Xamarin Profiler

=== Xamarin.Android ===

Version: 7.3.1.2 (Visual Studio Enterprise)
Android SDK: /Users/tom/android-sdk-macosx
	Supported Android versions:
		5.0 (API level 21)
		5.1 (API level 22)
		6.0 (API level 23)
		7.0 (API level 24)
		7.1 (API level 25)

SDK Tools Version: 26.0.2
SDK Platform Tools Version: 26.0.0
SDK Build Tools Version: 26.0.0 rc2

Java SDK: /usr
java version "1.8.0_131"
Java(TM) SE Runtime Environment (build 1.8.0_131-b11)
Java HotSpot(TM) 64-Bit Server VM (build 25.131-b11, mixed mode)

Android Designer EPL code available here:
https://github.com/xamarin/AndroidDesigner.EPL

=== Apple Developer Tools ===

Xcode 8.2.1 (11766.1)
Build 8C1002

=== Xamarin.Mac ===

Version: 3.4.0.36 (Visual Studio Enterprise)

=== Xamarin Inspector ===

Version: 1.2.2
Hash: b71b035
Branch: d15-1
Build date: Fri, 21 Apr 2017 17:57:12 GMT

=== Xamarin.iOS ===

Version: 10.10.0.36 (Visual Studio Enterprise)
Hash: d2270eec
Branch: d15-2
Build date: 2017-05-22 16:30:53-0400

=== Build Information ===

Release ID: 700010024
Git revision: 7ab1ca2ced6f584e56b7a0d4d321d00775cd95c9
Build date: 2017-05-19 05:44:51-04
Xamarin addins: 08d17158f3365beee5e60f67999e607cce4b3f93
Build lane: monodevelop-lion-d15-2

=== Operating System ===

Mac OS X 10.11.6
Darwin 15.6.0 Darwin Kernel Version 15.6.0
    Tue Apr 11 16:00:51 PDT 2017
    root:xnu-3248.60.11.5.3~1/RELEASE_X86_64 x86_64
Comment 3 Tom Opgenorth 2017-06-23 21:27:15 UTC
Created attachment 23093 [details]
Sample solution used to verify the problem.

Excluded the bin/obj and .git directories from this ZIP (in order to keep the file size of the ZIP within limits).
Comment 4 Brian Berry 2017-06-24 00:13:41 UTC
Just popping in again now since I saw a change notification.

@Tom: In what way does John think this would be a compiler-specific issue if we see the thrash only for Android and not other targets, as indicated?  (I'd assume the compiler would be identical.)
Comment 6 Marek Safar 2017-06-26 17:53:52 UTC
Moving back to XA.

Since Mono 5.0 we default to csc which supports deterministic builds but you need to pass /deterministic to csc via csproj (the setting is not available on UI).
Comment 7 Tom Opgenorth 2017-06-26 19:38:38 UTC
The .CSPROJ file has following in it:

<PropertyGroup>
    <Deterministic>true</Deterministic>
  </PropertyGroup>

Is this not the correct way to request a deterministic build?