daveaglick
Consider switching off 32-bit preference
If you try and reference #r reference a x64 dll inside of a scripty csx script you get a "Bad Image Format" error as scripty.exe is a x86 exe.
I've been manually cloning and building Scripty myself with the Properties\Build"Prefer 32-bit" turned off, which fixes the issue. Is there any issue pulling this into scripty?
I don't see a problem turning off the 32-bit preference. To be honest, not even sure why that's turned on. Only thing I can think is that MSBuild maybe used a x86 library at one point, so that'll just need to be verified that it won't cause a problem.
Of course, that means native 32-bit libraries will trigger bad image exceptions, but if we only had to support one, I'd choose x64. It may mean I need to publish both a x86 and a x64 version at some point - but we can deal with that later. I'm not sure how frequent a use case consuming native libraries is anyway.
To be honest, not even sure why that's turned on.
Its a default property for new apps. Something done to make AnyCPU executables work for ARM processors I think.
About a year ago, we had a new server (win2012) come online to replace an older one (win2K 32bit). Thanks to SAP's explicit platform targeting of x86 or x64 (and not just leaving the default AnyCPU) when the platform changed and could run x64, our programs did, then crashed with Bad Image Format exceptions when it tried to load the SAP .net connector.
Recompiling and retesting a 190 project solution for a version that was published a few years ago would have taken too long and was not in budget. But I found we could remove that property from all the exe's and assemblies using a powershell script and CorFlags.exe (corflags /32bitpref- ) . @stryder199 you may find that easier than Corflags than clone + recompile.
What I meant by the "work within Visual Studio" comment was that if your script host is Visual Studio (via the Custom Tool), the same the Image Format exception may get thrown when a forced x64 assembly is attempted to load in a csx and run.
I do encounter a BadImageFormationException when referencing a 64 bit dll in a .csx script and executing it with the "Custom Tool" feature. Is there any progress on this problem? What is the currently recommended mitigation?
Visual studio is not a 64 bit application, and that is the process the custom tool and script runs in.
What is the recommended work-around?
I see four options:
- Wait until a new release(s) of Scripty is out. I'm still leaning towards moving to x64 (which will cause x86 libraries to throw). I don't think I want to support two versions - that'll just get too confusing. Note that this may be a little while longer. Scripty isn't dead, but I've still got work to do to get it up to the .NET Core/.NET Standard world first (most of which has been happening in the Buildalyzer repo before being brought here).
- Find or recompile the library you're trying to consume to target x86 until Scripty moves to x64.
- Recompile Scripty as x64 as @stryder199 has done.
- Use the CorFlags utility or another assembly modification tool as @StingyJack has suggested to adjust the flag in the downloaded Scripty Visual Studio extension (it should be somewhere like "C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\Common7\IDE\Extensions")
I'll go with option 3 and use Scripty.exe as a command line tool to do my code generation. At least better than nothing at all. There isn't a 64bit version of T4's TextTransform.exe either, which is why I went looking for other alternatives. Scripty seems to do well enough, especially since C# got string interpolation. Thanks for your work on this!
Official support for 64 bit would be great. Then I can point colleagues to an official release, instead of telling them to manually compile and add the tool to the PATH.
The custom tool could spin up a host process and pipe the parameters and results back and forth. I think this is what the POSH tools do.