sharpdx / SharpDX

SharpDX GitHub Repository
http://sharpdx.org
MIT License
1.69k stars 638 forks source link

Can't build with .NET Native (UWP, Release) with version 4.0.0 #911

Closed Sergio0694 closed 7 years ago

Sergio0694 commented 7 years ago

Hello, I've been using the SharpDX library for some time and I've never had a problem with it. The version 3.1.1 worked perfectly fine for me but after I've updated it to version 4.0.0 this morning, I could no longer compile my app in Release mode.

I have installed all the required packages/tools I've seen listed in the readme file:

Version 3.1.1 compiles just fine both in Debug and Release, 4.0.0 compiles and works in Debug mode but fails to compile in Release mode. This is an error I'm seeing in the Output log when trying to compile in Release:

ILT0005: 'C:\Users\Sergio.nuget\packages\microsoft.net.native.compiler\1.6.2\tools\x86\ilc\Tools\nutc_driver.exe @"C:\PathToMyApp\obj\x86\Release\ilc\intermediate\MDIL\Lockr.rsp"' returned exit code 1

Is this a known issue, or maybe is there anything else I need to install/configure in order to get the new 4.0.0 version to compile properly? Thanks for your help!

xoofx commented 7 years ago

You will have to investigate this with .NET Native support.

Sergio0694 commented 7 years ago

@xoofx Yeah, I'll try to contact them and ask for some help πŸ˜„ I just wanted to know whether I was the only one with this issue while other developers with UWP were still able to compile the new 4.0.0 version using .NET Native, or if this was a know issue that appeared with the latest version of the package that's affecting everyone working on UWP apps.

I mean, having this additional info would also help the .NET Native team to better find the cause of the problem, as they'd know whether or not to actually look into my binaries specifically, or just the SharpDX package in general with UWP apps.

xoofx commented 7 years ago

Well, If there was any known issues related to this, 4.0.0 wouldn't have been released πŸ˜‰

But there is nothing in the build process of SharpDX that verifies that this platform works well and I'm never developing anything with UWP apps, so can't tell. The package 4.0.0 has been in pre-release for quite some time, so I was expecting this to popup before, when people using it would try it for this platform...

Sergio0694 commented 7 years ago

@xoofx You're absolutely right, sorry about that, didn't mean to say you actually released a bugged version on purpose, that came out wrong πŸ˜„

Anyways, I've just tried to create a black UWP app (for build 10.15063) and included the SharpDX package, I get the same error and I can't build in Release mode, so I guess that's just the .NET Native compiler that's complicating things again (this isn't the first time it does something unexpected like this).

I'll ask the .NET Native team, in the meantime you might want to add a small disclaimer that the latest 4.0.0 version doesn't seem to build successfully in Release mode for UWP apps (at least with the 15063 SDK). I'll let you know as soon as I hear back from the support team! πŸ‘

kburgoyne commented 7 years ago

@Sergio0694: Just some feedback...

I was building Win8 Universal with SharpDX V3 for a while and switched to Win10 UWP with SharpDX V4 a month or two ago. Since its been prerelease I've been building against a SharpDX that I build (one time as a separate project) and not a Nuget. For now I've been referencing the necessary SharpDX DLLs directly from the build I perform. (From "...\bin\Release\uap0.0" branches.)

When I switched to UWP I started by creating a blank UWP app (under VS2017) and then copied into it my source code files from the Win8 Universal version.

I've been mostly debug builds right now, but I have done some alpha release builds in the past. I just did some tests to see if I could duplicate what you're experiencing. I'm building for target 15063 (Creators) and a min of 10240 (original?). I rotated my release builds through x86, x64, and ARM. (My libraries are all AnyCPU.) I didn't encounter any build issues. I ran the x86 and x64 builds without issue. I didn't go so far as trying the ARM on a phone, but I've run ARM release builds on a phone in the past.

From your comments it "seems" like the one difference between our environments (other then the build systems) is I'm building against a SharpDX clone I built versus from a Nuget.

Are you building under VS2017? It just occurred to me that if you're not trying to actually build SharpDX, but rather using a Nuget, you might be building under VS2015. I only made the leap to VS2017 because of wanting to build SharpDX. Otherwise I probably would have been a VS2015 UWP project since VS2017 would have been an "unknown" concern for me at that time and VS2017 doesn't support the Win8 Universal project.

xoofx commented 7 years ago

@Sergio0694 could you check with latest 4.0.1 build, because I discovered as part of issue #912 that assemblies were compiled and released in "Debug", not sure if it has any impact on .NET Native but it could.

xoofx commented 7 years ago

Just tested to build a UWP application with VS2017 and nuget SharpDX.Direct3D11 (+DXGI + Core) 4.0.1 and it successfully builds.

Sergio0694 commented 7 years ago

@kburgoyne I'm using the NuGet package for the library and I'm working with VS2017, wouldn't want to miss out all the new .NETCore and .NET Native updates that aren't available for VS2015 πŸ‘

@xoofx Just tested and it works perfectly now (updating the package to version 4.0.1 also seems to have updated/installed a lot more referenced packages than before), I just created an app package in Release mode without any kind of issues. That was fast, thank you so much for your help! πŸ˜„

kburgoyne commented 7 years ago

Glad to hear its working and the solution to the issue is now known.

If there is nothing about the Nuget that clearly disallows VS2015, then it's probably worth remembering somebody trying it with VS2015 is always a possibility. It's probably easy to fall into the "assumption" the person would be using VS2017.

Sergio0694 commented 7 years ago

@kburgoyne Yeah you're right, lots of developers are still using VS2015 (for example, as VS2017 doesn't support some project types anymore, like WP8.1/W8.1 apps). Your question was 100% valid, I specified I was using VS2017 just to provide additional context πŸ˜ƒ