[msbuild] Do not allow iOS and Mac to share the same Xamarin.MacDev* …

[jstedfast]

…assemblies

Fixes https://bugzilla.xamarin.com/show_bug.cgi?id=52729

[jstedfast]

@rolfbjarne I need your help with fixing up the Makefile to correctly copy the Xamarin.iOSDev.Tasks* assemblies from their proper locations.

The problem is that the Makefile rules use the assembly name to construct the path, e.g.:

Xamarin.iOSDev.Tasks -> Xamarin.iOSDev.Tasks/bin/Release/Xamarin.iOSDev.Tasks.dll

but this assembly is actually located in Xamarin.MacDev.Tasks/bin/Release/Xamarin.iOSDev.Tasks.dll

[monojenkins]

Build failure

[rolfbjarne]

Crazy idea here: could it be easier to just include everything into Xamarin.iOS.Tasks[.Core].dll?

[jstedfast]

@rolfbjarne I thought of that, but that does make sharing code between Mac & iOS a bit harder...

[rolfbjarne]

@jstedfast why? can't you just link to the source files in the corresponding projects?

[monojenkins]

Build failure

[jstedfast]

iOS.Tasks.Core subclasses MyTaskBase and calls it MyTaskBase and then iOS.Tasks subclasses again and calls it MyTask

[jstedfast]

Yes, this is all safe syntactically from a namespace point of view all in the same assembly, but it's still awkward

[jstedfast]

anyway, I found a way to make fix the Makefile in a simple way, so all works now :)

[kzu]

Why not the way simpler approach of just renaming the assembly when referencing the project instead?

This is the approach we use with Cecil: https://github.com/xamarin/XamarinVS/blob/master/External/Mono.Cecil.overrides

You should be able to perform that renaming automatically in the ProjectReference itself:

<ProjectReference ...>
  <AdditionalProperties>AssemblyName=...</AdditionalProperties>
</ProjectReference>

That way, the entire build/reference/copy would just work. Seems like maintaining stuff in sync would be more work for little gain, unless I'm missing some other requirement

[monojenkins]

Build failure

[jstedfast]

I don't understand the Cecil approach or how that could/would work.

[spouliot]

Merging into a single assembly per-platform also sounds nice to my ears.

There's always some chance that Apple could break the simultaneous release of iOS/tvOS/watchOS so having less shared binaries help if we ever need to split things.

[spouliot]

Can you provide QA a list of tasks that required Newtonsoft.Json.dll so they can make sure the changes are tested correctly ?

[spouliot]

that's also an assembly that can change between versions
and can include breaking changes (it's happening with mono 5.8)

[monojenkins]

Build failure

[kzu]

Attached is the basic idea @jstedfast with three fake projects:

1. MacDev (the one upstream in Xamarin.MacDev), the one you want to reuse the code but not the assembly name
2. Two tasks projects, MacDev.Tasks and iOSDev.Tasks which both reference 1.

Both tasks project reference the MacDev one like so:

    <ProjectReference Include="..\Xamarin.MacDev\Xamarin.MacDev.csproj">
      <Project>{46e80364-c523-4b95-8c2b-ac1f1d047a15}</Project>
      <AdditionalProperties>AssemblyName=Xamarin.iOSDev;OutputPath=$(MSBuildProjectDirectory)$(OutputPath)</AdditionalProperties>
      <Name>Xamarin.MacDev</Name>
    </ProjectReference>

Passing the desired AssemblyName as an additional property to pass to the project reference when building it. The MacDev project in turn just needs to honor those overrides when present:

    <AssemblyName Condition="'$(AssemblyName)' == ''">Xamarin.MacDev</AssemblyName>
    ...
    <OutputPath Condition="'$(Condition)' == ''">bin\Release\</OutputPath>

This means you don't need to maintain duplicate projects at all. The end result is the same you have achieved by duplicating all projects and modifying build script: each tasks project ends up with its own distinct copy of a uniquely named assembly for its own tasks. Gotta love MSBuild ;)

Xamarin.MacDev.zip

[kzu]

I have to say though, that using the ILRepack nuget package and a bit of MSBuild sounds even better, simpler and more fool proof.

[jstedfast]

ILRepack is licensed under the Apache 2.0 license and is not MIT, is that something we can use?

[jstedfast]

This PR has been replaced by #3007