Xamarin-macios: *.dylib libraries are signed during full rebuild, but not the second time

Created on 10 Aug 2018  路  24Comments  路  Source: xamarin/xamarin-macios

In two words.
I have a project that has *.dylibs in example.ipa/example.app/Frameworks.
If I do full rebuild all these libs are signed and everything deploys and runs fine.
If I change a code, click on run these libs aren't signed that causes the next error

dyld: Library not loaded: @rpath/libswiftCore.dylib
Referenced from: /private/var/containers/Bundle/Application/72A745D9-0F6A-4A4A-B4B0-1D957D706291/example.app/Frameworks/iOSDFULibrary.framework/iOSDFULibrary
Reason: no suitable image found. Did find:
/private/var/containers/Bundle/Application/72A745D9-0F6A-4A4A-B4B0-1D957D706291/example.app/Frameworks/libswiftCore.dylib: code signature invalid for '/private/var/containers/Bundle/Application/72A745D9-0F6A-4A4A-B4B0-1D957D706291/exampleapp/Frameworks/libswiftCore.dylib'
/private/var/containers/Bundle/Application/72A745D9-0F6A-4A4A-B4B0-1D957D706291/example.app/Frameworks/libswiftCore.dylib: code signature invalid for '/private/var/containers/Bundle/Application/72A745D9-0F6A-4A4A-B4B0-1D957D706291/example.app/Frameworks/libswiftCore.dylib'

//////
During full rebuild I see the log where libs are signed.
_CodesignNativeLibraries:
2> Tool /usr/bin/codesign execution started with arguments: -v --force --sign 08729008A0D2A6EEB29981EB65354E55BCAF97AE --timestamp=none bin/iPhone/Debug/device-builds/ipad5.1-10.3.2/example.app/Frameworks/libswiftCore.dylib
2> Tool /usr/bin/codesign execution started with arguments: -v --force --sign 08729008A0D2A6EEB29981EB65354E55BCAF97AE --timestamp=none bin/iPhone/Debug/device-builds/ipad5.1-10.3.2/example.app/Frameworks/libswiftCoreFoundation.dylib
2> Tool /usr/bin/codesign execution started with arguments: -v --force --sign 08729008A0D2A6EEB29981EB65354E55BCAF97AE --timestamp=none bin/iPhone/Debug/device-builds/ipad5.1-10.3.2/example.app/Frameworks/libswiftCoreGraphics.dylib
2> Tool /usr/bin/codesign execution started with arguments: -v --force --sign 08729008A0D2A6EEB29981EB65354E55BCAF97AE --timestamp=none bin/iPhone/Debug/device-builds/ipad5.1-10.3.2/example.app/Frameworks/libswiftCoreImage.dylib
2> Tool /usr/bin/codesign execution started with arguments: -v --force --sign 08729008A0D2A6EEB29981EB65354E55BCAF97AE --timestamp=none bin/iPhone/Debug/device-builds/ipad5.1-10.3.2/example.app/Frameworks/libswiftDarwin.dylib
2> Tool /usr/bin/codesign execution started with arguments: -v --force --sign 08729008A0D2A6EEB29981EB65354E55BCAF97AE --timestamp=none bin/iPhone/Debug/device-builds/ipad5.1-10.3.2/example.app/Frameworks/libswiftDispatch.dylib
2> Tool /usr/bin/codesign execution started with arguments: -v --force --sign 08729008A0D2A6EEB29981EB65354E55BCAF97AE --timestamp=none bin/iPhone/Debug/device-builds/ipad5.1-10.3.2/example.app/Frameworks/libswiftFoundation.dylib
2> Tool /usr/bin/codesign execution started with arguments: -v --force --sign 08729008A0D2A6EEB29981EB65354E55BCAF97AE --timestamp=none bin/iPhone/Debug/device-builds/ipad5.1-10.3.2/example.app/Frameworks/libswiftMetal.dylib
2> Tool /usr/bin/codesign execution started with arguments: -v --force --sign 08729008A0D2A6EEB29981EB65354E55BCAF97AE --timestamp=none bin/iPhone/Debug/device-builds/ipad5.1-10.3.2/example.app/Frameworks/libswiftObjectiveC.dylib
2> Tool /usr/bin/codesign execution started with arguments: -v --force --sign 08729008A0D2A6EEB29981EB65354E55BCAF97AE --timestamp=none bin/iPhone/Debug/device-builds/ipad5.1-10.3.2/example.app/Frameworks/libswiftQuartzCore.dylib
2> Tool /usr/bin/codesign execution started with arguments: -v --force --sign 08729008A0D2A6EEB29981EB65354E55BCAF97AE --timestamp=none bin/iPhone/Debug/device-builds/ipad5.1-10.3.2/example.app/Frameworks/libswiftUIKit.dylib
2> Tool /usr/bin/codesign execution started with arguments: -v --force --sign 08729008A0D2A6EEB29981EB65354E55BCAF97AE --timestamp=none bin/iPhone/Debug/device-builds/ipad5.1-10.3.2/example.app/Frameworks/libswiftos.dylib
///////
If I change some code and debug (this is not rebuild) app crashes on startup with error I described above. And in the log I don't have _CodesignNativeLibraries so libs are not signed.
If there is some quick fix for "C:\Program Files(x86)\MSBuild\Xamarin\iOS\Xamarin.iOS.Common.targets"
to force signing always let me know in the comments or give a link to the commit when issue is fixed so I don't wait for next update. Thanks
///////
Microsoft Visual Studio Community 2017
Version 15.7.6
VisualStudio.15.Release/15.7.6+27703.2047
Microsoft .NET Framework
Version 4.7.03056

Installed Version: Community

Application Insights Tools for Visual Studio Package 8.12.10405.1
Application Insights Tools for Visual Studio

ASP.NET and Web Tools 2017 15.0.40625.0
ASP.NET and Web Tools 2017

ASP.NET Core Razor Language Services 15.7.31476
Provides languages services for ASP.NET Core Razor.

ASP.NET Web Frameworks and Tools 2017 5.2.60618.0
For additional information, visit https://www.asp.net/

Azure App Service Tools v3.0.0 15.0.40608.0
Azure App Service Tools v3.0.0

C# Tools 2.8.3-beta6-63029-08. Commit Hash: e9a3a6c0ba5b1fde8b1fff964bdfb3fb768ee2eb
C# components used in the IDE. Depending on your project type and settings, a different version of the compiler may be used.

Common Azure Tools 1.10
Provides common services for use by Azure Mobile Services and Microsoft Azure Tools.

JavaScript Language Service 2.0
JavaScript Language Service

JetBrains ReSharper Ultimate 2017.1.2 Build 108.0.20170428.75743
JetBrains ReSharper Ultimate package for Microsoft Visual Studio. For more information about ReSharper Ultimate, visit http://www.jetbrains.com/resharper. Copyright 漏 2018 JetBrains, Inc.

Merq 1.1.19-rc (a4ffc1b)
Command Bus, Event Stream and Async Manager for Visual Studio extensions.

Microsoft Continuous Delivery Tools for Visual Studio 0.3
Simplifying the configuration of continuous build integration and continuous build delivery from within the Visual Studio IDE.

Microsoft JVM Debugger 1.0
Provides support for connecting the Visual Studio debugger to JDWP compatible Java Virtual Machines

Microsoft MI-Based Debugger 1.0
Provides support for connecting Visual Studio to MI compatible debuggers

Microsoft Visual Studio Tools for Containers 1.1
Develop, run, validate your ASP.NET Core applications in the target environment. F5 your application directly into a container with debugging, or CTRL + F5 to edit & refresh your app without having to rebuild the container.

Mono Debugging for Visual Studio 4.10.5-pre (ab58725)
Support for debugging Mono processes with Visual Studio.

NuGet Package Manager 4.6.0
NuGet Package Manager in Visual Studio. For more information about NuGet, visit http://docs.nuget.org/.

ProjectServicesPackage Extension 1.0
ProjectServicesPackage Visual Studio Extension Detailed Info

ResourcePackage Extension 1.0
ResourcePackage Visual Studio Extension Detailed Info

SQL Server Data Tools 15.1.61804.210
Microsoft SQL Server Data Tools

TypeScript Tools 15.7.20419.2003
TypeScript Tools for Microsoft Visual Studio

Visual Basic Tools 2.8.3-beta6-63029-08. Commit Hash: e9a3a6c0ba5b1fde8b1fff964bdfb3fb768ee2eb
Visual Basic components used in the IDE. Depending on your project type and settings, a different version of the compiler may be used.

Visual F# Tools 10.1 for F# 4.1 15.7.0.0. Commit Hash: 173513e369ffb7a1c4d5dccf83696d9aac2ab2d0.
Microsoft Visual F# Tools 10.1 for F# 4.1

Visual Studio Code Debug Adapter Host Package 1.0
Interop layer for hosting Visual Studio Code debug adapters in Visual Studio

VisualStudio.Mac 1.0
Mac Extension for Visual Studio

Xamarin 4.10.10.2 (35a01d8dc)
Visual Studio extension to enable development for Xamarin.iOS and Xamarin.Android.

Xamarin Designer 4.12.1 (f3257e429)
Visual Studio extension to enable Xamarin Designer tools in Visual Studio.

Xamarin.Android SDK 8.3.3.2 (HEAD/dffc59120)
Xamarin.Android Reference Assemblies and MSBuild support.

Xamarin.iOS and Xamarin.Mac SDK 11.12.0.4 (64fece5)
Xamarin.iOS and Xamarin.Mac Reference Assemblies and MSBuild support.

VS bug #662636

external-xamarin-vs

Most helpful comment

Some users are having issues due to changes in tasks order when using PackageReference. There is a better explanation and workaround on the comment below:

https://github.com/Flash3001/iOSCharts.Xamarin/issues/47#issuecomment-452548254

All 24 comments

Hi,

Is there any chance you can provide us a test project that shows the issue? Or at least the Framework / dylib you're trying to use?

That would greatly help us reproduce the issue.

In addition please include your full build logs and crash reports.

To get full build logs just set the log verbosity to diagnostic at the following locations:

  • On Visual Studio for Mac: Preferences > Projects > Build
  • On Visual Studio for Windows: Tools > Options > Projects and Solutions > Build and Run

On Visual Studio Windows you also want to add -v -v -v -v to the mtouch additional arguments by right-clicking the project in the solution explorer and selecting Properties.
Note: this is done automatically on Visual Studio for Mac when the log verbosity is set to diagnostic.

Hi, @VincentDondain
Will do as soon as possible a sample app to reproduce a bug

Or at least the Framework / dylib you're trying to use? ( c ) I have a binding library that I've done from https://github.com/NordicSemiconductor/IOS-Pods-DFU-Library but it doesn't matter what framework. It is signed in both cases(full rebuild, build after code change). The problem with signing swift *dylib libraries. Full rebuild signs them. build after change doesn't.
libraries I add into the project from (version 4.0.3) https://github.com/Flash3001/Xamarin.Swift3.Support
but again there is nothing wrong with them. they work and can be signed by full rebuild.

@VincentDondain Here is a sample project. I made Xamarin forms project but look only into iOS.

Build logs are in the zip as well

CASE 1 fullrebuild_dylibs_signed_everything_is_ok_logs - Build Logs when I click on iOS project -> REBUILD. Then run an app and everything works.

CASE 2 build_after_modify_dylibs_not_signed_logs - Build logs when I change a code(any change in the code, even something like var s = "str"). then I click on iOS project -> BUILD

CASE 2 launching_the_app_after_modify - Logs I see when I launch the app after build (CASE 2)

DYLIBReproduceBug.zip

Mmh I cannot reproduce the issue using your test case. I have the same Xamarin.iOS version as you: https://gist.github.com/VincentDondain/f2ab9a50e1082612523e72627b5268aa

I'm wondering if maybe it has to do with Visual Studio on Windows.

To repro:

I opened you project and for Device|Debug I rebuilt the project (right click on DYLIBReproduceBug.iOS > Rebuild), then I added var s = "str" to the code, right click on DYLIBReproduceBug.iOS > Build. No issue.

@emaf can you change on XVS if you can reproduce this?

@VincentDondain

I added var s = "str" to the code, right click on DYLIBReproduceBug.iOS > Build. No issue.

Did you launched the app on a device?

Let's start from the beginning.
1) create App ID on apple.developer
2) create certificate,
3) create device with UDID of your device
4) create create provisioning profile on apple.developer with that certificate, app id and device you are testing on.
(Or use the one you have already)
5) Change bundle id in info.plist to the one you wrote when you created App ID on apple.developer
6) Rebuild an app with created provisioning profile,
7) launch an app on the device in debug - it should work.
8) Then change some code, click on ios project -> build and launch on the device in debug. App should be terminated on startup and you should see the error in the output window. If app was terminated but you didn't see the error, launch again.

Hey @VincentDondain, I was only able to reproduce it on VS for Windows.

On VS4M the CodesignNativeLibraries step sign all the libraries both for the first build and subsequent builds.

But on VS for Windows the same step sign all the libraries on the first build but skips all of them on subsequent builds.

I wonder if it has anything to do with the way this condition works on both: https://github.com/xamarin/xamarin-macios/blob/316948e5d0b230087476d9c14510e3adb1bb5762/msbuild/Xamarin.iOS.Tasks.Core/Tasks/CodesignNativeLibrariesTaskBase.cs#L157

On VS4M it always look like this:

Task "CodesignNativeLibraries"
    Tool /usr/bin/codesign execution started with arguments: -v --force --sign 57DFC61CAB0FE66FB6A5EBCA99C936E2BB1D9C6A --timestamp=none bin/iPhone/Debug/device-builds/iphone10.3-11.4.1/ioschartssample.app/Frameworks/libswiftCore.dylib
    Tool /usr/bin/codesign execution started with arguments: -v --force --sign 57DFC61CAB0FE66FB6A5EBCA99C936E2BB1D9C6A --timestamp=none bin/iPhone/Debug/device-builds/iphone10.3-11.4.1/ioschartssample.app/Frameworks/libswiftCoreGraphics.dylib
    Tool /usr/bin/codesign execution started with arguments: -v --force --sign 57DFC61CAB0FE66FB6A5EBCA99C936E2BB1D9C6A --timestamp=none bin/iPhone/Debug/device-builds/iphone10.3-11.4.1/ioschartssample.app/Frameworks/libswiftDarwin.dylib
    Tool /usr/bin/codesign execution started with arguments: -v --force --sign 57DFC61CAB0FE66FB6A5EBCA99C936E2BB1D9C6A --timestamp=none bin/iPhone/Debug/device-builds/iphone10.3-11.4.1/ioschartssample.app/Frameworks/libswiftMetal.dylib
    Tool /usr/bin/codesign execution finished (exit code = 0).
    Tool /usr/bin/codesign execution finished (exit code = 0).
    Tool /usr/bin/codesign execution started with arguments: -v --force --sign 57DFC61CAB0FE66FB6A5EBCA99C936E2BB1D9C6A --timestamp=none bin/iPhone/Debug/device-builds/iphone10.3-11.4.1/ioschartssample.app/Frameworks/libswiftDispatch.dylib
    Tool /usr/bin/codesign execution started with arguments: -v --force --sign 57DFC61CAB0FE66FB6A5EBCA99C936E2BB1D9C6A --timestamp=none bin/iPhone/Debug/device-builds/iphone10.3-11.4.1/ioschartssample.app/Frameworks/libswiftObjectiveC.dylib
    Tool /usr/bin/codesign execution finished (exit code = 0).
    Tool /usr/bin/codesign execution started with arguments: -v --force --sign 57DFC61CAB0FE66FB6A5EBCA99C936E2BB1D9C6A --timestamp=none bin/iPhone/Debug/device-builds/iphone10.3-11.4.1/ioschartssample.app/Frameworks/libswiftCoreImage.dylib
    Tool /usr/bin/codesign execution finished (exit code = 0).
    Tool /usr/bin/codesign execution started with arguments: -v --force --sign 57DFC61CAB0FE66FB6A5EBCA99C936E2BB1D9C6A --timestamp=none bin/iPhone/Debug/device-builds/iphone10.3-11.4.1/ioschartssample.app/Frameworks/libswiftQuartzCore.dylib
    Tool /usr/bin/codesign execution finished (exit code = 0).
    Tool /usr/bin/codesign execution started with arguments: -v --force --sign 57DFC61CAB0FE66FB6A5EBCA99C936E2BB1D9C6A --timestamp=none bin/iPhone/Debug/device-builds/iphone10.3-11.4.1/ioschartssample.app/Frameworks/libswiftCoreMedia.dylib
    Tool /usr/bin/codesign execution finished (exit code = 0).
    Tool /usr/bin/codesign execution finished (exit code = 0).
    Tool /usr/bin/codesign execution started with arguments: -v --force --sign 57DFC61CAB0FE66FB6A5EBCA99C936E2BB1D9C6A --timestamp=none bin/iPhone/Debug/device-builds/iphone10.3-11.4.1/ioschartssample.app/Frameworks/libswiftFoundation.dylib
    Tool /usr/bin/codesign execution started with arguments: -v --force --sign 57DFC61CAB0FE66FB6A5EBCA99C936E2BB1D9C6A --timestamp=none bin/iPhone/Debug/device-builds/iphone10.3-11.4.1/ioschartssample.app/Frameworks/libswiftUIKit.dylib
    Tool /usr/bin/codesign execution finished (exit code = 0).
    Tool /usr/bin/codesign execution started with arguments: -v --force --sign 57DFC61CAB0FE66FB6A5EBCA99C936E2BB1D9C6A --timestamp=none bin/iPhone/Debug/device-builds/iphone10.3-11.4.1/ioschartssample.app/Frameworks/libswiftCoreAudio.dylib
    Tool /usr/bin/codesign execution finished (exit code = 0).
    Tool /usr/bin/codesign execution started with arguments: -v --force --sign 57DFC61CAB0FE66FB6A5EBCA99C936E2BB1D9C6A --timestamp=none bin/iPhone/Debug/device-builds/iphone10.3-11.4.1/ioschartssample.app/Frameworks/libswiftos.dylib
    Tool /usr/bin/codesign execution finished (exit code = 0).
    Tool /usr/bin/codesign execution finished (exit code = 0).
    Tool /usr/bin/codesign execution started with arguments: -v --force --sign 57DFC61CAB0FE66FB6A5EBCA99C936E2BB1D9C6A --timestamp=none bin/iPhone/Debug/device-builds/iphone10.3-11.4.1/ioschartssample.app/Frameworks/libswiftCoreFoundation.dylib
    Tool /usr/bin/codesign execution finished (exit code = 0).
    Tool /usr/bin/codesign execution finished (exit code = 0).
    Tool /usr/bin/codesign execution finished (exit code = 0).
  Done executing task "CodesignNativeLibraries".

I'm having this same problem. It's annoying to have to clean between each run on the device

@Aufty Are you using Xamarin.Swift4 version 4.0.0.0? Version 4.0.0.1 has a workaround for that.

@Aufty Are you using Xamarin.Swift4 version 4.0.0.0? Version 4.0.0.1 has a workaround for that.

Using an SDK that depends on version 4.0.0.1

Without the SDK I have no issues.

Anybody have any suggestions? The SDK is DocumentReader (Regula).

Easy to reproduce. Create a project, add the SDK, run once on a device, stop, run it again, crash. Clean the project, run again, no problem, stop, run again, crash.

Does Microsoft support this product at all?

Just updated, still crashing

@Aufty Do you mind to share a build log? The original issue was fixed with the workaround on 4.0.0.1

What version of Visual Studio are you using? VS4M or Visual Studio for Windows?

I checked the library you mentioned, DocumentReader and it says: Xamarin.Swift4 (>= 4.0.0) which means Nuget will install version 4.0.0 when it installs, not 4.0.0.1. So you have to update the package manually.

Hi all,
Sorry for the late response. We've been working to solve this issue, and its fix should be included in the next Visual Studio 2019 preview.

Would you fix Visual Studio 2017 too ?

Just wanted to say I got everything set up on Visual Studio for Mac and this particular problem is not present. Only on Windows VS2017.

@Flash3001 the version of the DocumentReader I'm using is the beta version and it's using 4.0.0.1

Question: Is there anything I can change in the build process to force the dylib libraries to be rebuilt so I don't have to clean before each deploy? Something behind the scenes / temporary???

I'd love to just use VS Mac but it has proven to work horribly with TFS - so I'm kind of stuck between a rock and a hard place here. Every day I do my best not to get explosively frustrated with the time I'm losing navigating through Xamarin. I know it's complex - I just wish MS devoted a few more resources to getting it stable.

bump

@Aufty In fact this is what the Swift4 4.0.0.1 update tries to do as a workaround. Force the libraries to be resigned every time you build for Device.

As you didn't provide a log to check, please make sure you VS is on Diagnostics build log mode. And check if this task is running on a rebuild _CodesignSwift

You can find what it was supposed to be doing here https://github.com/Flash3001/Xamarin.Swift3.Support/blob/master/Swift4/Xamarin.Swift4/build/Xamarin.Swift4.targets#L22

and

https://github.com/Flash3001/Xamarin.Swift3.Support/blob/master/Swift4/Xamarin.Swift4/build/Xamarin.Swift4.targets#L38

Cheers @Flash3001 - is there anything I can do if this isn't happening other than asking the package owner to update their library?

@Flash3001 _CodesignSwift is not running on build. Only if i clean the project and make a new build.
Log says:
"Neuzuweisung der Eigenschaft: $(_CoreCodesignDependsOn)="

        _EmbedMobileProvision;
        _CodesignNativeLibraries;
        _CollectFrameworks;
        _CodesignFrameworks;
        _ReadAppExtensionCodesignProperties;
        _CodesignAppExtensions;
        _PrepareCodesignAppExtension;
        _CalculateCodesignAppBundleInputs;
    ;
        _CodesignAppBundle;
        _CodesignVerify;
    " (vorheriger Wert: "
  _CodesignSwift;
  ;

") unter C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\Xamarin\iOS\Xamarin.iOS.Common.targets (372,3)"

So it seems _CodesignSwift was set but overridden by Xamarin.iOS.Common.targets.

Is it possible to define a build order or something ?

Some users are having issues due to changes in tasks order when using PackageReference. There is a better explanation and workaround on the comment below:

https://github.com/Flash3001/iOSCharts.Xamarin/issues/47#issuecomment-452548254

That's it !! Thank you very much.

@Flash3001

This solved it! _Thank you!!!_

Was this page helpful?
0 / 5 - 0 ratings