A function that claims to be available to both Desktop and Metro apps.

But someone was concerned about this answer:

As far as I know, IdnToAscii is only for C++.The question is for C#/VB.

Okay, here is where things get complicated.

I think I have it straight now, though.

Here are the travails to get there -- imagine each one required several emails to clarify (since each one did!):

The Base Class Libraries (BCL) in the .NET Framework that runs on ARM is a subset of the full BCL. (OH NO!)

The System.Globalization Namespace is included in that subset (OH YES!)

The IdnMapping class is apparently not being included (OH NO!)

The IdnToAscii function is available to both the Desktop and Metro apps (OH YES!)

If you are using C# or VB, p/invoke cannot be used to run arbitrary code (OH NO!)

IdnToAscii is on the white list of legal functions to p/invoke to (OH YES!)

So really, the fact that you cannot get all of this from a glance at the docs is that the docs are a work in progress.

But I can live with that -- as long as people can get to functionality, they are not blocked.

We can get stuff done!

Whether Desktop or Metro.

Whether Native or Managed.

Whether x86 or x64 or WoA (ARM).

I think I know what my first Modern app will be!

Joshua on 18 May 2012 11:05 AM:

If you are using C# or VB, p/invoke cannot be used to run arbitrary code (OH NO!)

We will not be releasing an ARM build of our product then (need our own native DLL for a few key tasks).

Michael S. Kaplan on 18 May 2012 2:45 PM:

Well, you may want to dig in to get the right answer for your code -- my case kind of proves that the answer can be complicated!

Simon Buchan on 18 May 2012 8:48 PM:

My understanding of the entire point of WinRT was that APIs are WinRT apis (applies to "Metro style" applications in the docs), not "C++" or ".NET" apis: basically it's supposed to extend the language independence of .NET metadata to native code and scripting languages. So any "Metro" API should be accessible from any WinRT supporting language, so I'm more surprised that there's no .NET binding to it through some static class somewhere. I guess P/Invoke isn't so horrible, but it could be far better.

Simon Buchan on 18 May 2012 9:01 PM:

@Joshua: Cross-language/runtime interop is what WinRT is *for*. Recommendation for portal code is for you to, in your Metro builds, compile your native dll with your exports wrapped with C++/CX definitions:

// foo.h

...

int foo_bar(const char* str);

// WinRT.cpp

#include "foo.h"

namespace MyComponent

{

public ref class Foo sealed

{

public:

static int Bar(Platform::String^ str)

{

// Platform::String^ is pretty close to System.String in .NET.

// Convert UTF-16 to UTF-8 here...

return foo_bar(utf8Str);

}

}

}

Then you get a WinRT .dll that's indistinguishable from any other, including builtins.

cheong00 on 20 May 2012 11:02 PM:

He can just enable the setting "configuration"->"uri"->"idn" in app.config or web.config and let Uri.DnsSafeHost class handle it. It's available on PCL too.

Alan McF on 23 May 2012 12:56 PM:

@joshua It works for me in a Metro C# app too. When I add various Win32 API P/Invoke calls they work in *most* cases, but running WACK (Windows App Cert Kit) highlights that of the one I used "socket" and etc are forbidden but has no complaints about IdnToAscii.

Pavel Minaev [MSFT] on 13 Jun 2012 1:24 PM:

>> If you are using C# or VB, p/invoke cannot be used to run arbitrary code

It cannot be used to run arbitrary code in a sense that you can't P/Invoke, say, a desktop-only API. But from everything I've seen, it can absolutely be used to P/Invoke into the Metro subset of Win32, or your own DLLs. Or did that change in RP?