Porting to WinRT

So, I tried to port a library I wrote over to WinRT. I just put all the classes in a newly created project and pressed Compile, getting 16 errors:

• First of all, System.Web and System.Security.Cryptography are gone. I sure hope there's a new HMACSHA256 class in WinRT because losing that would seriously suck.
• HttpWebRequest no longer has a 'Date' property or a GetResponse() method.
• The WebExceptionStatus enum no longer has the ProtocolError value.
• System.Reflection.Assembly no longer has a GetExecutingAssembly() method.
• System.Array no longer has ConvertAll
• HttpUtility is gone.
• String.ToLower no longer takes an IFormatProvider.
• NameValueCollection is gone. Seriously, NameValueCollection.

This is... kind of a lot to just spring on developers. Did the WinRT folks post a "guide for porting your .NET code to WinRT" blog post somewhere?

28 minutes ago, Bas wrote

• NameValueCollection is gone. Seriously, NameValueCollection.

NameValueCollection has been obsolete since .NET 2.0. use a Dictionary<string, string> instead.

@Bas: Not trying to be overly snarky or to be a Microsoft apologist, but you're doing a significant port of code from one runtime to another and are getting only 16 errors and you're complaining ?

That said, some of these would seem to be critical things to leave out. There's probably some alternative APIs that for whatever reason are considered better and should be used now is my guess. The cryptography APIs fall in this category, because I can't see them not including something there. Time to start digging and figuring out where the differences lie and what the options are.

54 minutes ago, wkempf wrote

@Bas: Not trying to be overly snarky or to be a Microsoft apologist, but you're doing a significant port of code from one runtime to another and are getting only 16 errors and you're complaining ?

I know, on one hand it's impressive, but on the other it's kind of annoying to have to rewrite stuff that was already working. It's all relative I guess.

That said, some of these would seem to be critical things to leave out. There's probably some alternative APIs that for whatever reason are considered better and should be used now is my guess. The cryptography APIs fall in this category, because I can't see them not including something there. Time to start digging and figuring out where the differences lie and what the options are.

That's the thing, I'm not so much complaining about stuff being different/left out but more about the lack of a good "this in .NET is here in WinRT" guide. Also I miss FxCop.

Other stuff is doable on second glance. The lack of GetResponse() is because they implemented the HTTP request stuff as asynchronous, with GetResponseBegin() GetResponseEnd()  and GetResponseAsync() methods. I guess it's time to get used to stuff like that.

Just in case people are trying to port their own stuff and are finding this thread via Google or something, I've since been able to successfully port the whole thing to be used in Metro. Some things I had to find some other way for (I needed the assembly's major version, but I just made it a hardcoded const int now, and I still don't know how to set the Date header in a HttpWebRequest but fortunately the webservice I was using provided an alternative, and I'm not catching ProtocolError WebExceptions anymore). Other things were easier: Array.ConvertAll was replaced by a LINQ query and a foreach, String.ToLower(IFormatProvider) was replaced by String.ToLowerInvariant(), and NameValueCollection was replaced by Dictionary<string, string>. Instead of HttpUtility.UrlEncode I used Uri.EscapeUriString, which is apparently a better way of doing it even if you're just writing regular, non-WinRT applications.

Replacing the HMACSHA256 class proved the most difficult, but I've figured it out using the Windows.Security.Cryptography namespaces. Basically to hash a string message using a key, you do

string stringToSign = "Whatever message you wish to sign";
string hashKey = "The key you want to sign it with."

MacAlgorithmProvider macAlgorithmProvider = MacAlgorithmProvider.OpenAlgorithm("HMAC_SHA256");
BinaryStringEncoding encoding = BinaryStringEncoding.Utf8;
var messageBuffer = CryptographicBuffer.ConvertStringToBinary(stringToSign, encoding);
IBuffer keyBuffer = CryptographicBuffer.ConvertStringToBinary(hashKey, encoding);
CryptographicKey hmacKey = macAlgorithmProvider.CreateKey(keyBuffer);
IBuffer signedMessage = CryptographicEngine.Sign(hmacKey, messageBuffer);

string hashedString = CryptographicBuffer.EncodeToBase64String(signedMessage);

Basically you create a MacAlgorithmProvider and tell it what algorithm you want to use (since I was using HMACSHA256 I told it to use the HMAC_SHA256 algorithm), you create IBuffers that you fill with the binary values for your message and hash key, tell the algorithm provider to create a CryptoGraphicKey using the IBuffer you made from your hash key string, and then call CryptoGraphicEngine.Sign to sign your stuff. Then to convert it back to a regular string you simply call CryptographicBuffer.EncodeToBase64String().