Windows Phone Silverlight
doozly
Posts: 4
I know Windows Phone Silverlight is still in beta, but I have the following issue tying to use SA with it.
First I created a brand new Windows Phone Class Library with no classes. Then created a brand new SA project without changing any settings, and everything works correctly.
I then add a class as follows:
Using the same SA project I now get the error:
SmartAssembly has encountered an invalid token in:
[System.Windows]System.Net.HttpUtility
I guess that this is due to the oddity with the way Silverlight locates its side-by-side assemblies, this was using SA 5.2 (build 92)
Also in another Windows Phone project the Control Flow Obfuscation does not work on Strongest but does with Strictly Valid, I havent been unable to narrow it down any further.
These are not issues that need resolving immediately but thought you should be made aware.
Thanks
Doozly
www.doozly.com
First I created a brand new Windows Phone Class Library with no classes. Then created a brand new SA project without changing any settings, and everything works correctly.
I then add a class as follows:
public class Class1
{
static void Test()
{
System.Net.HttpUtility.UrlEncode("");
}
}
Using the same SA project I now get the error:
SmartAssembly has encountered an invalid token in:
[System.Windows]System.Net.HttpUtility
I guess that this is due to the oddity with the way Silverlight locates its side-by-side assemblies, this was using SA 5.2 (build 92)
Also in another Windows Phone project the Control Flow Obfuscation does not work on Strongest but does with Strictly Valid, I havent been unable to narrow it down any further.
These are not issues that need resolving immediately but thought you should be made aware.
Thanks
Doozly
www.doozly.com
Comments
Redgate Software
With regard to the control flow obfuscation you will probably have to use the "strictly valid" option for Windows Phone Silverlight unless the methods being protected are very small. The standard Microsoft .NET runtimes are fairly relaxed which means that SA can add more protections which are not completely within the spirit of the CLR specification. For non-standard or non-Microsoft runtimes - like Mono and the Windows Mobile version - you generally have to use "strictly valid" otherwise they complain.