Build Editor for x64

[ericoporto]

Hey, I tried to preserve things as is as possible for the x86 builds of the Editor but some things DID change, please review this with care and evaluate if we update this in 3.6.1 or leave for 3.6.2.

fix #2088

The Editor does successfully build on the x64 target and it does starts up!

• Verify the x86 target still builds
• Adjust CI for x86 builds
• Adjust installer and packaging scripts for x86 builds
• Test x64 editor and check possible broken features
• check x64 p/invoke and other direct access to windows dll still work or adjust Apparently it works but I don't understand how
• Handle x86 engine .dll plugins in x64 Editor (and possibly vice-versa) abandoned here, leaving for the future

CI for x64 builds of the Editor will not be done in this PR.

[AlanDrake]

I suggest not to bother trying to bridge x86<->x64 plugins. They should be compiled as separate dlls just like it's done in every other game engine.

Only thing necessary is to make sure x86 builds still work.

Fixing x64 editor issues can be done later, it's more important to have the build option available so we can test it in real scenarios.

[ericoporto]

To explain the problem with plugins, it’s that Windows plugins for the Engine ALSO have Editor features, for one it reads the header but also it can do extra things, like showing additional options in the plugin context menu in the editor. I think it needs a Windows directory there where the different archs of the engine can be placed, along with their plugins.

But the core issue is the x64 editor will crash when trying to build with plugins for windows right now.

Still, it’s possible to add the way it’s now and just fix the CI and move onto these things later.

[ericoporto]

Found out that this is wrong in 64-bit

ags/Editor/AGS.Editor/Utils/Utilities.cs

Line 517 in b0b63f1

int sourceAddress = sourceData.Scan0.ToInt32();

Obviously the address can't be an int32, this will crash. There's no reason for this too, the IntPtr can be manipulated directly - the type exists exactly for this!

[ericoporto]

Only thing necessary is to make sure x86 builds still work.

Fixing x64 editor issues can be done later, it's more important to have the build option available so we can test it in real scenarios.

I chose this approach and upgraded the Editor project in a way it does builds for x64 but that it still builds for x86.

Still, I had to remove the AnyCPU and Mixed Platforms as a general target for the Solution (they kinda make sense in fully managed dlls, but not when there is Native dlls involved).

[ivan-mogilko]

For the record, this is also an issue related to 64-bit support, perhaps it makes sense to do next: #2274

[ericoporto]

Yes, this has to be tackled next before providing builds of the Editor to ensure we don't get weird things when compiling script. I did a git grep long in the Compiler dir and doesn't look like a lot of things so I hope to be able to start and finish that tomorrow.