Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
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
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.
* Create test project.
* Build for device.
* Build for device again (without doing any changes).
codesign is executed in both builds.
Looks like the _CodesignAppBundle target doesn't have doesn't have any Inputs/Outputs (same with _CodesignNativeLibraries and _CodesignFrameworks).
Ouch, I suspect re-signing means re-uploading to the device :(
If that's the case then we might want to backport this to C9 as it would impact build/deploy times when debugging.
The only solution I can think of is to have a stamp file for each resource that gets codesigned.
Okay so let me post all my discoveries at this point:
Both XS and Xcode seem to re-run codesign at every build the question is: does that actually force re-upload on our side? And the answer is: yes it does!
Basically we will re-upload if the app bundle has changed (we compare the last write timestamp against the last time we uploaded the app to the device).
With some logging of all the files that changed since last upload I found out that:
- MyApp.app/MyApp (native executable)
are the files that change when we re-build (no clean) with no changes at all.
This is forcing re-upload.
The native executable change would be due to codesign (even though Xcode's native executable does not change after each build) and the other files are due to some other tasks.
Thanks for looking into this, @Vincent! HUGE help :)
I think that the way that I'm going to do this is I'm going to submit 2 separate PR's.
The first PR will fix the archived-expanded-entitlements.xcent and embedded.mobileprovision outputs to not change while the second PR which will fix the Codesign task.
The reason for the split is that the Codesign changes will need different logic for cycle8/9 and for cycle10 (at least once my App Extension codesign-delay changes for cycle10 get merged).
PR #1 (cycle10): https://github.com/xamarin/xamarin-macios/pull/1359
This should easily be portable to cycle9 (and even cycle8 if we want to), but it will depend on https://github.com/xamarin/xamarin-macios/pull/1352 (since this patch removes a `using System.Linq;` statement - otherwise a little massaging can be done).
PR #1 for cycle9: https://github.com/xamarin/xamarin-macios/pull/1369
PR #2 for master: https://github.com/xamarin/xamarin-macios/pull/1373
PR #2 for cycle9: https://github.com/xamarin/xamarin-macios/pull/1370
I can reproduce this Issue with stable XI 10.3.1.7 and observed that MyApp.app/MyApp (native executable), MyApp.app/archived-expanded-entitlements.xcent, MyApp.app/embedded.mobileprovision getting change every time when rebuild app without any change.
I have chacked the same with latest Cycle 9 build (XI 10.4.0.61) and Master build (XI 10.5.0.243) and observed that now MyApp.app/MyApp (native executable), MyApp.app/archived-expanded-entitlements.xcent, MyApp.app/embedded.mobileprovision not getting change when rebuild app without any change.
Build Output: https://gist.github.com/saurabh360/d9f02f42acf0cf7319cbd48b297c9fa0
Environment Info and Logs: https://gist.github.com/saurabh360/93fadba1f5425a39c055f24f9aaaca40