I'm seeing a new issue in c6 builds when using the VS 2015 build tools. The SiteCore component fails to build due to:
> error CS1703: Multiple assemblies with equivalent identity have been imported
This project builds successfully in VS2015 and from command line with MSBuild 14 using cycle 5 builds, but fails with cycle 6 builds. This project builds successfully on Mac against cycle 6 builds, as well as in XS on windows against cycle 6 builds (which does not yet support 2015 build tools).
Steps to reproduce from Command line:
1. Download the SiteCore component
2. Download xamarin-component.exe
3. xamarin-component.exe restore samples\AndroidMobileSdkDemo\AndroidMobileSdkDemo.sln
4. msbuild /t:SignAndroidPackage samples\AndroidMobileSdkDemo\AndroidMobileSdkDemo\AndroidMobileSdkDemo.csproj
Successful C5 build output:
Failed C6 build output:
##### Environment #####
Operating System: Windows 10
Repo Name: XamarinVS.git
Branch Name: cycle6
Build Revision: 8150bab699a83061f39a1cd5e35303e793972caa
MonoDroidHash: cycle6 2eefd39c431d80d2d004877f8ef84760b95d8e20
@peterc this is a problem with the nuget package for the Sitecore
CSC : error CS1703: Multiple assemblies with equivalent identity have been imported: 'C:\Users\PJ\Downloads\Sitecore.Mobile.SDK-1.0\samples\AndroidMobileSdkDemo\Components\Sitecore.Mobile.SDK-1.0\lib\android\System.Threading.Tasks.dll' and 'C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\MonoAndroid\v1.0\Facades\System.Threading.Tasks.dll'. Remove one of the duplicate references. [C:\Users\PJ\Downloads\Sitecore.Mobile.SDK-1.0\samples\AndroidMobileSdkDemo\AndroidMobileSdkDemo\AndroidMobileSdkDemo.csproj]
CSC : error CS1703: Multiple assemblies with equivalent identity have been imported: 'C:\Users\PJ\Downloads\Sitecore.Mobile.SDK-1.0\samples\AndroidMobileSdkDemo\Components\Sitecore.Mobile.SDK-1.0\lib\android\System.IO.dll' and 'C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\MonoAndroid\v1.0\Facades\System.IO.dll'. Remove one of the duplicate references. [C:\Users\PJ\Downloads\Sitecore.Mobile.SDK-1.0\samples\AndroidMobileSdkDemo\AndroidMobileSdkDemo\AndroidMobileSdkDemo.csproj]
It should NOT be including the design time facade dll's in the component package specifically
they appear be in be Components\Sitecore.Mobile.SDK-1.0\lib\android\ when they shouldn't be.
I don't know who maintains this component but they will need to update it to be compatible with the new build tooling. This isn't something we can fix on our end since its MSBuild doing the assembly resolution here not us.
On a side note... its also including files like
in the android folder of the package.. I'm willing to bet that if someone adds the nuget for Newtonsoft.json manually they will get the same error.
The iOS and iOS unified lib folders have the same issue
Personally I don't think this is a regression. The previous build targets were hiding a problem that the user should fix. Namely the csproj had references to things like System.IO which were in the component directory and not just using the framework provided ones. Users should never reference Facade assemblies directly from an app because they are normally just shim's of the platform specific assembly provided by the actual framework.
The sample project included with the component should NOT be including the design time facade dll's in the component
they appear be in be Components\Sitecore.Mobile.SDK-1.0\lib\android\. We probably don't need to include those files in the Component either.
So to fix this issue we just need to remove the references for these assemblies from the .csproj of the component sample.
Interestingly on Mac.. we need to have a reference to System.Threading.Tasks.dll in order to build but not System.IO.. on windows they both need to be removed in order to the app to build.
Both apps behave the same otherwise.
CC: @holmes @redth on Comment #4.
I'll be filing a new bug to track the behavioral discrepancy between various build paths here, as we will want to standardize on the "correct" behavior everywhere. Unfortunately, it looks like _none_ of this will be happening in time for cycle6-baseline.
Just for future reference, the mono bug filed mentioned in Comment 5 is: https://bugzilla.xamarin.com/show_bug.cgi?id=35706
Do you know if the NuGet works with Cycle 6?
The initial failure here was reported against cycle6, and it only affects the sample project that ships with the sitecore component, not the NuGet package itself.
Using a new or existing XA project, if I add and use the Sitecore.MobileSDK.Xamarin NuGet I'm able to compile and run my project without any issues.
However, the 'AndroidMobileSdkDemo' sample project errors out on machines with MSBuild 14 as mentioned above. It's only this sample project that will need to be updated to not reference the design time facade dll's in the component package, specifically:
Given the dependencies that are contained in this component I suggest the submitter make use of the NuGet features now available in the component store.
I will reach out to the submitter to resolve this issue.
Hi all, Xamarin component had no dependency support when the package was created.
That's why libraries was included in the component package.
We will update package in a short time.
Please check the new Xamarin component version.
Now it's actually just a shell component around the NuGet Sitecore SDK package.
Marking as resolved as per Comment #11, the included sample in v1.1 no longer fails to compile.
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 Links.
Create a new report for Bug 35582 on Developer
Community or GitHub if you have new information to add and do not yet see a matching
In special cases on GitHub you might also want the comments:
GitHub Markdown with public comments
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.