Issue Targeting x86 Platform #67

Closed
hatboyzero opened this Issue Dec 26, 2013 · 17 comments

Comments

Projects
None yet
10 participants
@hatboyzero

nuget.package/tools/net45/GetLibLuaPostBuildCmd.ps1

This file adds post build events that copy the wrong version of the native library for our project. We are developing on an x64 machine, but targeting x86 processors. Because the machine is x64, the install script assumes, incorrectly, that we desire the x64 library, and we get a Bad Image Format exception when we try to run the code.

Also, the path of the reference in the post-build event is hard coded to the development machine, which will result in a failure on our build server.

Maybe this is the same culprit as what is described in #66.

@viniciusjarina

This comment has been minimized.

Show comment
Hide comment
@viniciusjarina

viniciusjarina Dec 26, 2013

Member

@hatboyzero Have you tried the latest NuGet pakage?

The patch sent by @davidkennedy85 should fix the issue ce7fea3

Can you try the latest NuGet Package? https://www.nuget.org/packages/NLua/1.3.0.2

Thank you.

Member

viniciusjarina commented Dec 26, 2013

@hatboyzero Have you tried the latest NuGet pakage?

The patch sent by @davidkennedy85 should fix the issue ce7fea3

Can you try the latest NuGet Package? https://www.nuget.org/packages/NLua/1.3.0.2

Thank you.

@Pajamaman

This comment has been minimized.

Show comment
Hide comment
@Pajamaman

Pajamaman Dec 27, 2013

Contributor

Actually that's exactly what the script is supposed to do. It looks at the arch. of the machine you're developing on and copies the version of the DLL that is compatible with your machine.

AKAIK NLua is only compatible with x64 projects, which is why I opened issue #66.

Contributor

Pajamaman commented Dec 27, 2013

Actually that's exactly what the script is supposed to do. It looks at the arch. of the machine you're developing on and copies the version of the DLL that is compatible with your machine.

AKAIK NLua is only compatible with x64 projects, which is why I opened issue #66.

@hatboyzero

This comment has been minimized.

Show comment
Hide comment
@hatboyzero

hatboyzero Jan 6, 2014

That's all fine and good, but what happens when you are developing on one platform but targeting an entirely different one. I know that is not typically the case, but it does happen in real world scenarios. Simply looking at the architecture of the development machine and selecting the appropriate binary for the desired target platform only works if your development platform and target platform are the same, thus excluding my particular use case...

That's all fine and good, but what happens when you are developing on one platform but targeting an entirely different one. I know that is not typically the case, but it does happen in real world scenarios. Simply looking at the architecture of the development machine and selecting the appropriate binary for the desired target platform only works if your development platform and target platform are the same, thus excluding my particular use case...

@jamesrcounts

This comment has been minimized.

Show comment
Hide comment
@jamesrcounts

jamesrcounts Jan 6, 2014

Agree with @hatboyzero you need to look at the currently selected project build configuration and decide based on that, if it is Debug|x86 or Release|x86, picking the x64 native library simply will not work, regardless of the physical architecture of the CPU.

@hatboyzero also mentioned a valid point about hardcoding the path to the binary as full path in a post-build event. This simply wont work on a build server. At a minimum the path must be relative to the project structure. Even better would be to add the (appropriate) DLL as a project member, set the build type to "Content" set it up to "Copy if newer" or "Copy always", this will get it into the bin dir at run time and allow Visual Studio's project system to keep track of the file's location.

Agree with @hatboyzero you need to look at the currently selected project build configuration and decide based on that, if it is Debug|x86 or Release|x86, picking the x64 native library simply will not work, regardless of the physical architecture of the CPU.

@hatboyzero also mentioned a valid point about hardcoding the path to the binary as full path in a post-build event. This simply wont work on a build server. At a minimum the path must be relative to the project structure. Even better would be to add the (appropriate) DLL as a project member, set the build type to "Content" set it up to "Copy if newer" or "Copy always", this will get it into the bin dir at run time and allow Visual Studio's project system to keep track of the file's location.

@Pajamaman

This comment has been minimized.

Show comment
Hide comment
@Pajamaman

Pajamaman Jan 6, 2014

Contributor

I think this issue should be merged with issue #66 as it is the same problem I am having.

Contributor

Pajamaman commented Jan 6, 2014

I think this issue should be merged with issue #66 as it is the same problem I am having.

@viniciusjarina

This comment has been minimized.

Show comment
Hide comment
@viniciusjarina

viniciusjarina Jan 23, 2014

Member

What is your configuration (Windows+VS+target project) ?

On Wed, Jan 22, 2014 at 11:33 PM, dcarlson-plazsoft <
notifications@github.com> wrote:

I am having the same issue (BadImageFormatException upon creation of Lua
object). NLua does not work at all on my system. I also got the latest
NuGet package - 1.3.0.2


Reply to this email directly or view it on GitHubhttps://github.com/NLua/NLua/issues/67#issuecomment-33089091
.

Member

viniciusjarina commented Jan 23, 2014

What is your configuration (Windows+VS+target project) ?

On Wed, Jan 22, 2014 at 11:33 PM, dcarlson-plazsoft <
notifications@github.com> wrote:

I am having the same issue (BadImageFormatException upon creation of Lua
object). NLua does not work at all on my system. I also got the latest
NuGet package - 1.3.0.2


Reply to this email directly or view it on GitHubhttps://github.com/NLua/NLua/issues/67#issuecomment-33089091
.

@dcarlson-plazsoft

This comment has been minimized.

Show comment
Hide comment
@dcarlson-plazsoft

dcarlson-plazsoft Jan 23, 2014

The workstation where this problem was occurring is windows 7 x64, vs2010 pro. I tried both x86 and x64 projects, trying multiple .net versions as well. I installed the vs 2012 c++ redistributable. (http://www.microsoft.com/en-us/download/details.aspx?id=30679) I also tried the latest NuGet package - 1.3.0.2.

However, after getting home, I tried on my laptop and finally got it to work for x64/.net 4.0 and then x86/.net 3.5. So it is possible I just missed something at work yesterday. (My laptop is also windows 7 x64, vs2010 pro)
Now I will have to see if I can get it in our XNA project.

The workstation where this problem was occurring is windows 7 x64, vs2010 pro. I tried both x86 and x64 projects, trying multiple .net versions as well. I installed the vs 2012 c++ redistributable. (http://www.microsoft.com/en-us/download/details.aspx?id=30679) I also tried the latest NuGet package - 1.3.0.2.

However, after getting home, I tried on my laptop and finally got it to work for x64/.net 4.0 and then x86/.net 3.5. So it is possible I just missed something at work yesterday. (My laptop is also windows 7 x64, vs2010 pro)
Now I will have to see if I can get it in our XNA project.

@dcarlson-plazsoft

This comment has been minimized.

Show comment
Hide comment
@dcarlson-plazsoft

dcarlson-plazsoft Jan 23, 2014

I got it to work on my workstation in a blank x86 Console application, and even a blank XNA application, but not the project with the game in it. It just gives me the exception below every time for that project.
System.BadImageFormatException was unhandled
Message=An attempt was made to load a program with an incorrect format. (Exception from HRESULT: 0x8007000B)
Source=KeraLua
StackTrace:
at KeraLua.NativeMethods.LuaLNewState()
at KeraLua.Lua.LuaLNewState() in y:\projects\nlua\NLua\Core\KeraLua\src\KeraLua\Lua.cs:line 34
at NLua.LuaLib.LuaLNewState()
at NLua.Lua..ctor()
at YargisNew.YargisGame.DoLuaTest() in C:\Users\dcarlson\Documents\Visual Studio 2010\Projects\Yargis\Yargis\Yargis\Core\Game.cs:line 296
at YargisNew.YargisGame..ctor() in C:\Users\dcarlson\Documents\Visual Studio 2010\Projects\Yargis\Yargis\Yargis\Core\Game.cs:line 91
at YargisNew.Program.Main(String[] args) in C:\Users\dcarlson\Documents\Visual Studio 2010\Projects\Yargis\Yargis\Yargis\Core\Program.cs:line 13
InnerException:

EDIT: It turns out there was a post build script doing something to the dlls. After deleting that and recopying, it worked.
Thank you.

I got it to work on my workstation in a blank x86 Console application, and even a blank XNA application, but not the project with the game in it. It just gives me the exception below every time for that project.
System.BadImageFormatException was unhandled
Message=An attempt was made to load a program with an incorrect format. (Exception from HRESULT: 0x8007000B)
Source=KeraLua
StackTrace:
at KeraLua.NativeMethods.LuaLNewState()
at KeraLua.Lua.LuaLNewState() in y:\projects\nlua\NLua\Core\KeraLua\src\KeraLua\Lua.cs:line 34
at NLua.LuaLib.LuaLNewState()
at NLua.Lua..ctor()
at YargisNew.YargisGame.DoLuaTest() in C:\Users\dcarlson\Documents\Visual Studio 2010\Projects\Yargis\Yargis\Yargis\Core\Game.cs:line 296
at YargisNew.YargisGame..ctor() in C:\Users\dcarlson\Documents\Visual Studio 2010\Projects\Yargis\Yargis\Yargis\Core\Game.cs:line 91
at YargisNew.Program.Main(String[] args) in C:\Users\dcarlson\Documents\Visual Studio 2010\Projects\Yargis\Yargis\Yargis\Core\Program.cs:line 13
InnerException:

EDIT: It turns out there was a post build script doing something to the dlls. After deleting that and recopying, it worked.
Thank you.

@dionrhys

This comment has been minimized.

Show comment
Hide comment
@dionrhys

dionrhys Mar 13, 2014

This problem still appears to occur with the latest (1.3.0.2) NuGet package.

Steps to reproduce:

  1. Create an empty Console Application project in Visual Studio 2013 for .NET Framework 4.5 (on a 64-bit platform)
  2. Add the NLua package to the project using NuGet
  3. Write some code to use NLua in the console app's Main method.
  4. Run

This is the resulting exception:

An unhandled exception of type 'System.BadImageFormatException' occurred in KeraLua.dll

Additional information: An attempt was made to load a program with an incorrect format. (Exception from HRESULT: 0x8007000B)

Stack Trace:
   at KeraLua.NativeMethods.LuaLNewState()
   at KeraLua.Lua.LuaLNewState()
   at NLua.LuaLib.LuaLNewState()
   at NLua.Lua..ctor()
   at ConsoleApplication2.Program.Main(String[] args) in c:\Users\dion.williams.COLLABCO\Documents\Visual Studio 2013\Projects\ConsoleApplication2\ConsoleApplication2\Program.cs:line 14
   at System.AppDomain._nExecuteAssembly(RuntimeAssembly assembly, String[] args)
   at System.AppDomain.ExecuteAssembly(String assemblyFile, Evidence assemblySecurity, String[] args)
   at Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly()
   at System.Threading.ThreadHelper.ThreadStart_Context(Object state)
   at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
   at System.Threading.ThreadHelper.ThreadStart()

It's likely caused because the 64-bit native Lua DLL is placed in the bin folder in a post-build event, even though projects have "Prefer 32-bit" set by default and target the "Any CPU" platform.

This problem still appears to occur with the latest (1.3.0.2) NuGet package.

Steps to reproduce:

  1. Create an empty Console Application project in Visual Studio 2013 for .NET Framework 4.5 (on a 64-bit platform)
  2. Add the NLua package to the project using NuGet
  3. Write some code to use NLua in the console app's Main method.
  4. Run

This is the resulting exception:

An unhandled exception of type 'System.BadImageFormatException' occurred in KeraLua.dll

Additional information: An attempt was made to load a program with an incorrect format. (Exception from HRESULT: 0x8007000B)

Stack Trace:
   at KeraLua.NativeMethods.LuaLNewState()
   at KeraLua.Lua.LuaLNewState()
   at NLua.LuaLib.LuaLNewState()
   at NLua.Lua..ctor()
   at ConsoleApplication2.Program.Main(String[] args) in c:\Users\dion.williams.COLLABCO\Documents\Visual Studio 2013\Projects\ConsoleApplication2\ConsoleApplication2\Program.cs:line 14
   at System.AppDomain._nExecuteAssembly(RuntimeAssembly assembly, String[] args)
   at System.AppDomain.ExecuteAssembly(String assemblyFile, Evidence assemblySecurity, String[] args)
   at Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly()
   at System.Threading.ThreadHelper.ThreadStart_Context(Object state)
   at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
   at System.Threading.ThreadHelper.ThreadStart()

It's likely caused because the 64-bit native Lua DLL is placed in the bin folder in a post-build event, even though projects have "Prefer 32-bit" set by default and target the "Any CPU" platform.

@Gadroc

This comment has been minimized.

Show comment
Hide comment
@Gadroc

Gadroc Apr 13, 2014

There are a few problems in place with the current nuget package. All from the same cause. Essentially when the package is installed it adds a post build event like this:

xcopy /s /y "c:\users\username\Source\Repos\helios\packages\NLua.1.3.0.2\lib\native\x64\*.*" "$(TargetDir)"

There are multiple problems with this build event, all stemming from the fact that they are hardcoded to the first machine that processes the nuget install script. First fix would be to not hardcode the path to the packages directory. It would then look like this.

 xcopy /s /y "$(SolutionDir)packages\NLua.1.3.0.2\lib\native\x64\*.*" "$(TargetDir)"

Now if you check out the source on a second machine and compile it. It will still work. Now we hit the second problem which is that the platform architecture is hardcoded into the xcopy as well. What is worse is that it was driven by querying the build machine architecture instead of the build target. This is partially fixed by using another variable in the post build event as follows:

xcopy /s /y "$(SolutionDir)packages\NLua.1.3.0.2\lib\native\$(PlatformName)\*.*" "$(TargetDir)"

Now we have the last problem which in all honesty is not resolvable. That is the fact that we are adding dependency with native unmanaged code. This causes significant problems with an AnyCPU target, and probably should not be supported. AnyCPU has many possibilities on run time environment... x86, x64 and arm. To support them NLua will have to dynamically import the right library at run time instead of just copying the dependencies with the appropriate name to the right place.

Lastly not related to the post build xcopy is the project references. The nuget package added the x86 dll as the reference but was copying the 64bit. I'm not sure how it decided which references to add.

Gadroc commented Apr 13, 2014

There are a few problems in place with the current nuget package. All from the same cause. Essentially when the package is installed it adds a post build event like this:

xcopy /s /y "c:\users\username\Source\Repos\helios\packages\NLua.1.3.0.2\lib\native\x64\*.*" "$(TargetDir)"

There are multiple problems with this build event, all stemming from the fact that they are hardcoded to the first machine that processes the nuget install script. First fix would be to not hardcode the path to the packages directory. It would then look like this.

 xcopy /s /y "$(SolutionDir)packages\NLua.1.3.0.2\lib\native\x64\*.*" "$(TargetDir)"

Now if you check out the source on a second machine and compile it. It will still work. Now we hit the second problem which is that the platform architecture is hardcoded into the xcopy as well. What is worse is that it was driven by querying the build machine architecture instead of the build target. This is partially fixed by using another variable in the post build event as follows:

xcopy /s /y "$(SolutionDir)packages\NLua.1.3.0.2\lib\native\$(PlatformName)\*.*" "$(TargetDir)"

Now we have the last problem which in all honesty is not resolvable. That is the fact that we are adding dependency with native unmanaged code. This causes significant problems with an AnyCPU target, and probably should not be supported. AnyCPU has many possibilities on run time environment... x86, x64 and arm. To support them NLua will have to dynamically import the right library at run time instead of just copying the dependencies with the appropriate name to the right place.

Lastly not related to the post build xcopy is the project references. The nuget package added the x86 dll as the reference but was copying the 64bit. I'm not sure how it decided which references to add.

@jamesrcounts

This comment has been minimized.

Show comment
Hide comment
@jamesrcounts

jamesrcounts Apr 14, 2014

The easiest way to "decide" which native library to add is to let the developer do it.

The easiest way to let the developer decide is to create a version of the package for each platform (x86 and x64, and no package for "Any"). A developer should know what platform they are targeting, and choose the appropriate package, and each package should include only one version of the native library.

My suggestion for "deploying" the native library is to add it to the "content" folder and and include a install.ps1 to set the copy property to "Copy Always."

Here is a gist for the install.ps1 file: https://gist.github.com/jamesrcounts/10690582

The easiest way to "decide" which native library to add is to let the developer do it.

The easiest way to let the developer decide is to create a version of the package for each platform (x86 and x64, and no package for "Any"). A developer should know what platform they are targeting, and choose the appropriate package, and each package should include only one version of the native library.

My suggestion for "deploying" the native library is to add it to the "content" folder and and include a install.ps1 to set the copy property to "Copy Always."

Here is a gist for the install.ps1 file: https://gist.github.com/jamesrcounts/10690582

@viniciusjarina

This comment has been minimized.

Show comment
Hide comment
@viniciusjarina

viniciusjarina Oct 2, 2014

Member

Fixed. Just create a folder x86 and x64 and copy each version of native lua52.dll (grab from the the README.md since the NuGet is not updated).

Member

viniciusjarina commented Oct 2, 2014

Fixed. Just create a folder x86 and x64 and copy each version of native lua52.dll (grab from the the README.md since the NuGet is not updated).

@swlasse

This comment has been minimized.

Show comment
Hide comment
@swlasse

swlasse Oct 2, 2014

Thanks @viniciusjarina - is the nuget package going to be updated in the near future?

swlasse commented Oct 2, 2014

Thanks @viniciusjarina - is the nuget package going to be updated in the near future?

@zunath

This comment has been minimized.

Show comment
Hide comment
@zunath

zunath Oct 2, 2014

Please update the Nuget package. Thank you.

zunath commented Oct 2, 2014

Please update the Nuget package. Thank you.

@viniciusjarina

This comment has been minimized.

Show comment
Hide comment
@viniciusjarina

viniciusjarina Oct 3, 2014

Member

I am doing this..I am trying to finish the Windows Store version first ;)

On Thu, Oct 2, 2014 at 10:17 AM, zunath notifications@github.com wrote:

Please update the Nuget package. Thank you.


Reply to this email directly or view it on GitHub
#67 (comment).

Member

viniciusjarina commented Oct 3, 2014

I am doing this..I am trying to finish the Windows Store version first ;)

On Thu, Oct 2, 2014 at 10:17 AM, zunath notifications@github.com wrote:

Please update the Nuget package. Thank you.


Reply to this email directly or view it on GitHub
#67 (comment).

@nrother

This comment has been minimized.

Show comment
Hide comment
@nrother

nrother May 8, 2015

Is there any progress on updating the NuGet Package? I'd really like to add a dependency to NLua from my DynamicLua instead of including it, but this would require a version that has this bug fix included ;)

nrother commented May 8, 2015

Is there any progress on updating the NuGet Package? I'd really like to add a dependency to NLua from my DynamicLua instead of including it, but this would require a version that has this bug fix included ;)

@viniciusjarina

This comment has been minimized.

Show comment
Hide comment
@viniciusjarina

viniciusjarina May 11, 2015

Member

@nrother This was fixed a long time ago.

Is not working for you?

Member

viniciusjarina commented May 11, 2015

@nrother This was fixed a long time ago.

Is not working for you?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment