Open philstopford opened 6 years ago
I don't have a perfect solution to offer, but I dug into this a couple days ago and learned some things that might be useful to someone at some point.
As you've seen, the correct version of OpenTK is copied to the build output folder, just not packed into the ultimate .app bundle. It can be brute forced on a command line, or that cp line could be turned into a post build step, though at least in my case the latter option required an external console, which in turn doesn't close automatically and you either have to constantly close the leftover terminal windows or end up with a cascade of them on screen.
The approach I settled on was a new MSBuild target, set to run after the Build target, as such:
<Target Name="ReplaceOpenTK" AfterTargets="Build">
<ItemGroup>
<OpenTK Include="$(TargetDir)\OpenTK.*" />
</ItemGroup>
<Copy SourceFiles="@(OpenTK)" DestinationFolder="$(OutputAppPath)\Contents\MonoBundle" />
</Target>
See it in context here. The target builds a list named OpenTK, comprised of everything in the output directory matching that name, including the PDB, the .dll.config, and of course the DLL itself, then just crams it into the .app bundle, overwriting everything inside already. No need for an external console, no orphan terminal windows, nice and clean.
I haven't figured out how to avoid the Xamarin OpenTK reference in the first place, but I have figured out where it gets added. I was able to dump diagnostic build output to a text file for easy searching by building at the command line with this:
msbuild -verbosity:diagnostic Path/To/Project.csproj > builddiagnostic.txt
Having seen that the undesirable OpenTK.dll packed into the output .app was 665KB in size, I tried to find out where it was coming from. "Search this Mac" didn't help, presumably because the location wasn't indexed, but poking around that massive diagnostic build log showed me that in my case the file was being copied from here:
/Library/Frameworks/Xamarin.Mac.framework/Versions/Current/lib/x86_64/full
There are other copies, too, in lib/reference/full and some nearby directories, but the 665KB file was only in that location. Searching the build log for full/OpenTK.dll got me only one result: there's a build task named "Mmp" that's a child of a build target called "_CompileToNative", and during that task, the pernicious Xamarin OpenTK insinuates itself into our .app bundles.
How one would avoid referencing the undesirable library in the first place, I don't know, but this sledgehammer of a technique seems to be working for my project. I'm able to reference the proper version in Visual Studio for Mac, get Intellisense and everything, and then build the project, replace the files without manual intervention, and run/debug the project without issue.
Reading through this OpenTK issue, or digging through the Xamarin.Mac repo, might shed some light on things, but I didn't have much luck myself. The Xamarin project makes it clear where _CompileToNative is, as well as a couple things for Mmp (here and here), but I'm hard pressed to say how much more there is to it than those three, and I couldn't piece all that stuff together into a more elegant solution, I'm sorry to say.
Post-build, within the Debug/Release folder:
cp OpenTK.dll TestEtoGl.XamMac.app/Contents/MonoBundle/
Then the app will run.
Haven't figured out why the OpenTK.dll library in the bin folder isn't packaged in the app properly.