Home Dashboard Directory Help
Search

Add DllImport support for .NET in Windows Phone 8 by Alexandre Mutel


Status: 

Closed
 as Fixed Help for as Fixed


946
2
Sign in
to vote
Type: Bug
ID: 777333
Opened: 1/23/2013 6:08:48 PM
Access Restriction: Public
0
Workaround(s)
view
56
User(s) can reproduce this bug

Description

Currently, It is not possible to use a [DllImport] in .NET for WP8 to directly access an existing native function from a DLL (for example, all Supported Win32 APIs for Windows Phone http://msdn.microsoft.com/en-us/library/windowsphone/develop/jj662956%28v=vs.105%29.aspx), while it is perfectly possible to do this on standard .NET and .NET 4.5 Core (for Win8/WinRT).

The workaround is to develop an almost empty C++ WinPRT component to get an access to these pointer functions (like It as been developed in SharpDX project: http://code.google.com/p/sharpdx/source/browse/Source/SharpDX.WP8/SharpDXWP8.cpp). This C++ WinPRT component is actually acting exactly as a DllImport, except that we have to develop it just to bypass the .NET restriction.

Also, this restriction is implying lots of annoying collateral effects:
- We cannot develop "AnyCpu" library/application, and are forced to have a specific build for WP8 x86 and ARM. It makes the build much more laborious as we have to maintain a special case for WP8. When developing an application (like a Game) that is supposed to run on Desktop, WinRT and WP8, we expect to use most the same code everywhere, without having to compile platform specific assemblies (that is the purpose of DllImport specially when using systems DLL that are automatically redirected to the correct platform dll x86 or x64 for example).
- We cannot use "Portable Library Class" with WP8 when using native code, making "Portable Library Class" useless when using "DllImport" (We can only target .NET and .NET Core, but not WP8).

We understand that WinPRT could be in the future the only way to access native code, but because lots of Win32 API are still not yet ported to the WinRT model, we still need to access directly native code from .NET. The fact that is DllImport access is not possible on WP8 is not consistent with .NET and .NET Core (WinRT).

One great strength of .NET is to have seamlessly native code integration, please, please, fix this in a next release of WP8 SDK!
Details
Sign in to post a comment.
Posted by Tommaso Scalici on 4/9/2014 at 7:09 AM
Thank you so much! That's the kind of news we all want to hear! So Microsoft really care about their developers, after all!
Happy Ending this time. ;)
Posted by Alexandre Mutel on 4/8/2014 at 5:24 PM
Ah, that's a good news, thanks!
Posted by Microsoft on 4/8/2014 at 11:39 AM
Thanks you everyone for your comments and votes on this issue. Windows Phone 8.1 now supports P/Invoke and DllImport in .NET applications. Please note that some DLLs may have different names on Windows Phone than they had on Windows.
Posted by Tommaso Scalici on 4/8/2014 at 12:49 AM
Microsoft, are you kidding us? More than one year and two months are passed, still no news about this issue. I hope we can find it on the next Developer Preview of WP8.1 or the Platform seriously risk to get abandoned.
Posted by Alexandre Mutel on 2/12/2014 at 6:05 AM
We have been waiting for more than one year for this bug to be fixed and we have still no news. Is this going to be fixed in WP8.1?

If you don't want to fix it, well, tell-us, I will remove support for WP8/8.1 in SharpDX, as I'm starting really to be bored by all the annoyance it is causing to the project.
Posted by Chris Bordeman on 1/8/2014 at 12:51 PM
Well, it's been a whole year since we were told this was being handled by the correct group.

Is there any update, or is Microsoft going to blow off its developers critical needs again?

And they wonder why developers aren't writing mobile apps.

This of course needs to apply to WinRT apps, too, not just WP8!
Posted by Nabeel Hassan Colwiz on 12/17/2013 at 11:54 PM
any update on this issue ??
please I need this fix in order to use a dll in my fyp.

I would appreciate if you could provide with an alternative solution at this time ..
Posted by Duane Bekaert on 10/28/2013 at 4:17 AM
Like many already comented, this is a pressing issue. When will this be adressed ? This seem to be a WP8 problem so how do you plan to distrubute the fix ?
Posted by Dan Colasanti on 10/11/2013 at 6:55 AM
Visual Studio Product Team - it's been 9 months since you indicated you will review this issue - what is your resolution? Will this be addressed for VS2012, VS2013, or not at all?
Posted by sinand99 on 3/13/2013 at 8:49 AM
This is a critical bug
Posted by Capella Meng on 3/5/2013 at 11:08 PM
Really need this! thanks!!
Posted by timrfrench61 on 2/28/2013 at 1:14 PM
Yes, this is also important for my development.
Posted by Syncaidius on 2/10/2013 at 3:33 AM
Agreed - This is vital to developer productivity when it comes to developing across several of Microsoft's platforms. If you really care about us developers MS, please implement this!
Posted by Noodle Biscuit on 2/9/2013 at 6:00 AM
Agreed - we need this ASAP!
Posted by Clark Alesna on 2/4/2013 at 7:40 AM
Yes please! Absolutely needed!
Posted by AzureSky on 2/3/2013 at 9:45 AM
Yes, absolutely, please add this feature, Microsoft! I think this is most important to have on WP8.

Posted by Aleksey.T on 2/2/2013 at 5:42 AM
Dear Microsoft, please, we need this.
Thank you.
Posted by _Mahdi_ on 1/26/2013 at 4:38 AM
Really really urgent feature we miss in C#/WP8.
Posted by SoftSavage on 1/24/2013 at 6:41 AM
For users of MonoGame this feature is also very very important!
Posted by Microsoft on 1/24/2013 at 1:22 AM
Thanks for your feedback.

We are rerouting this issue to the appropriate group within the Visual Studio Product Team for triage and resolution. These specialized experts will follow-up with your issue.
Posted by Iol2006 on 1/24/2013 at 12:37 AM
This issue is critical in continue development for WP8
Posted by Tom Spilman on 1/23/2013 at 8:13 PM
I don't see any reason why C# developers should have less access to loading native libraries than C++ developers on the same platform. This forces us to manage 3x the number of assemblies instead of a single one like we do with our Windows 8 Store app.

Worse it causes unnecessary productivity loss. I always forget to switch between x86 and ARM targets when going from the emulator to the deployment to a device.

Windows 8 Store development is much nicer than Windows Phone 8 development because DLLImport works and "Any CPU" targets are possible.
Posted by Lertulo on 1/23/2013 at 7:57 PM
This is critical for my continued involvement in Windows Phone development.
Posted by Microsoft on 1/23/2013 at 6:51 PM
Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(http://support.microsoft.com)
Sign in to post a workaround.