WOCCatalog Sample Doesn’t Build

[alakoring]

I grabbed the 1802Eval VM (for Parallels) and downloaded WinObjC. I had to do some Visual Studio updating, but finally got to the point where I could get this error. None of it really makes any sense, since I'm not a Windows user any more. I have no idea what manifests or tasks are in the Visual Studio world.

My expectation is that the samples build.

1>------ Rebuild All started: Project: NugetRestore, Configuration: Debug Any CPU ------
1>EnsureSolutionRestored: Restoring solution C:\WinObjC-0.2.180220\samples\WOCCatalog\WOCCatalog-WinStore10.sln
1>MSBuild auto-detection: using msbuild version '15.5.180.51428' from 'C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\bin'.
1>C:\WinObjC-0.2.180220\common\gitversiontask\4.0.0-beta0011\build\GitVersionTask.targets(68,5): error MSB4062: The "GitVersionTask.GetVersion" task could not be loaded from the assembly C:\WinObjC-0.2.180220\common\gitversiontask\4.0.0-beta0011\build\GitVersionTask.dll. Could not load file or assembly 'file:///C:\WinObjC-0.2.180220\common\gitversiontask\4.0.0-beta0011\build\GitVersionTask.dll' or one of its dependencies. The module was expected to contain an assembly manifest. Confirm that the <UsingTask> declaration is correct, that the assembly and all its dependencies are available, and that the task contains a public class that implements Microsoft.Build.Framework.ITask. [C:\WinObjC-0.2.180220\samples\WOCCatalog\WOCCatalog.vsimporter\WOCCatalog-WinStore10\WOCCatalog.vcxproj]
1>
1>C:\WinObjC-0.2.180220\common\NugetRestore.msbuildproj(33,5): error MSB3073: The command "C:\WinObjC-0.2.180220\common\..\.tools\nuget.exe restore C:\WinObjC-0.2.180220\samples\WOCCatalog\WOCCatalog-WinStore10.sln" exited with code 1.
1>Done building project "NugetRestore.msbuildproj" -- FAILED.
========== Rebuild All: 0 succeeded, 1 failed, 0 skipped ==========

[DHowett-MSFT]

@alakoring Hi! Thanks for the report. Was this directory (WinObjC-0.2.180220) generated by cloning our repository, downloading the release tag, or pulling our NuGet packages?

Due to a GitHub issue, the ZIP generated from the release tag is not usable: GitHub doesn't include Git LFS files in the final archive.

[alakoring]

Oh drat, it was the .zip (that always seems simplest since I don't have to install anything). I now vaguely remember reading that didn't work…

[DHowett-MSFT]

If you get past this and run into further issues, we're tracking changes that improve our compatibility with VS 2017 Update 5 and beyond:

Bugs

• 2837

• 2859

Tasks

• 2848

• 2860

• 2838

If you're building the samples, or any applications that do not consume C++, you should be okay.

[alakoring]

Oh, because https://developer.microsoft.com/en-us/windows/bridges/ios said to get the .zip file…

I have one or two .mm files, but they don’t use STL.

[alakoring]

Yes, I had to unload NugetRestore, otherwise this error blocked me

After that, I got HelloUI working (switched samples because it seemed a little simpler).

[alakoring]

Darn, I am using std::string so I guess I am using STL. I am blocked by that…

(BTW, thanks for the prompt and helpful reply, Dustin — you’ve saved me a lot of frustration.)

[alakoring]

I don’t see a 64-bit configuration there, and my vsimporter run didn’t make one for my own project. Is this supported?

[DHowett-MSFT]

You may still be able to scrape by using std::string without type_traits. I don't have a handle on exactly which headers are impacted, unfortunately. They change with every VS release, and the gulf is only going to widen until the #2837 work lands.

Unfortunately, 64-bit isn't supported. It looks like you found #122 tracking that; it's obviously a pretty old one! In a lot of places we're not 64-bit clean, and it's a tough uphill battle to become 64-bit clean:

• A few old places are using DWORD for pointers (!)
• NSInvocation doesn't have an assembly counterpart for x64
• libobjc2's objc_msgSend.x86_64 was written for the sysv x64 ABI
• The Windows exception model is different on x86 vs. x64, and we haven't quite nailed exception generation yet

[alakoring]

I stubbed out my limited use of std::string, and eventually managed to get all my code building as a (32-bit) DLL. But, per #2861, the Unity Editor is now 64-bit. (I think I can download a 2 year old version, but that’s not a very good answer for a big project.)

This game doesn’t use NSInvocation, and I could probably rewrite my limited use of exceptions. But I guess you’d have to do the whole thing.

Sadly, it looks like I may have to rethink Windows support.

[MSFTFox]

As far as I know, Unity discontinued the 32 bit version of their IDE but did not end support for 32 bit builds. I would imagine that you could target your project to x86 in Unity's build settings and in that way utilize the 32 bit dll you've been able to build. You would have to make sure everything else your project uses is 32 bit as well.

https://blogs.unity3d.com/2016/11/15/end-of-support-for-32-bit-editor-for-windows/

(Specifically the paragraph titled, "I use 32-bit plugins, what are my options?")

[alakoring]

I think the 64-bit Unity editor still needs to have a usable plugin, even though it can target 32-bit. At least that’s how I interpreted its error messages.

But at least Unity 5.6 isn’t as old as I feared I would have to try.

[MSFTFox]

I'm fairly confident that the 64 bit editor should play nice with 32 bit plugins as long as your build settings are targeting x86 and not x86_x64. Only the latter would require a 64 bit dll.

[alakoring]

I get Failed to load 'Assets/Plugins/SAPlugin.dll', expected x64 architecture, but was x86 architecture. You must recompile your plugin for x64 architecture. although the build settings are for x86. (I assume it’s because I’m not actually building when I use the Editor. But I haven’t used Unity enough to be certain.)