Andrew Arnott : .NET

GZip encoder for Compact WCF

andarno — Wed, 01 Oct 2008 05:13:07 GMT

The GZip encoder is not included in NetCF as it is on the desktop WCF, but it isn't hard to build yourself and in fact we have released a sample of exactly how to add your own GZip encoder to NetCF:

http://go.microsoft.com/fwlink/?LinkId=108652

So many people have asked me for it lately I thought I'd better just post the link. Have fun!

OpenID and ASP.NET web sites

andarno — Tue, 15 Apr 2008 01:21:10 GMT

If you are a web developer I hope you've considered accepting OpenID credentials for logging in your users. If you have an ASP.NET web site, the process of adding OpenID support to your web site couldn't be easier when you use the free C# DotNetOpenId library.

Supporting OpenID is a great idea:

No more "I forgot my username/password" pages.
No more "Change Password" pages.
Your users have one less username/password to make-up/reuse when they join your site.
Users who prefer greater security than a username/password provides can choose an OpenID Provider that provides that assurance, without you having to enhance your site.
It's free. And so are the libraries that you can drop in to add support for it.

Workaround for XmlSerializer T[] and List bug

andarno — Tue, 06 Nov 2007 00:34:27 GMT

The XmlSerializer in NetCF 2.0 has a bug where if a single serialization requires reflecting into types that use a mixture of Collection<T>-like types for the same T the XmlSerializer will throw an exception. Here an example where CF 2.0 would crash:

public class SerializingType1 {
   public string[] FirstNames;
   public List<string> PhoneNumbers;
}

This type would fail to serialize under NetCF 2.0 because T = string would appear in two kinds of collections. This next example would also fail if you were serializing TypeA, because it contains a TypeB instance which has the another kind of T collection.

public class TypeA {
   public string[] FirstNames;
   public TypeB b;
}
public class TypeB {
   public List<string> PhoneNumbers;
}

If you can change the public API to use all T[] or List<T> and avoid the mixture, you've worked around the problem. So this would be the simplest workaround:

public class SerializingType1 {
   public List<string> FirstNames;
   public List<string> PhoneNumbers;
}

If you can't change the public API to maintain compatibility for your customers, here's another workaround that will eliminate the mixture for the XmlSerializer but keep the mixture for your customers.

public class SerializingType1 {
   [XmlIgnore]
   public string[] FirstNames {
      get { return firstNamesHiddenList != null ? firstNamesHiddenList.ToArray() : null; }
      set { firstNamesHiddenList = value != null ? new List<string>(value) : null; }
   }
   [System.ComponentModel.EditorBrowsable(System.ComponentModel.EditorBrowsableState.Never)]
   [XmlArray("FirstNames")]
   [Obsolete("This member is for internal use only.")]
   public List<string> firstNamesHiddenList;
   public List<string> PhoneNumbers;
}

This will make the XmlSerializer work, and the API to the customer appear to be the same, except for a public member that they should never use directly that is only there (and public) because the XmlSerializer requires it. EditorBrowsableAttribute and ObsoleteAttribute are there to help the customer to not run into that member and use it when you didn’t intend them to.

This bug is fixed in .NET Compact Framework 3.5.

What do you think of the new WCF 'Store and forward' Mail Transport?

andarno — Mon, 29 Oct 2007 22:53:53 GMT

With the .NET Compact Framework 3.5 release which comes with Visual Studio 2008, a new Windows Communication Foundation transport is introduced that uses email as the communication mechanism.

Others have already blogged about this new transport including Roman Batoukov and David Kline.

I'd like to take a poll of the audience to see how you like the transport, including the documentation and samples that we ship with it. Can you think of uses for an email transport? Do you have any trouble figuring out how to use it? Will you use it exclusively on desktop machines, mobile devices or both?

Please comment below and let me know what you're doing with it! We'd like to know about any pain points you run into so we can fix it in the next version.

Calling WCF services from NetCF 3.5 using Compact WCF and NetCFSvcUtil.exe

andarno — Thu, 13 Sep 2007 02:29:00 GMT

The .NET Compact Framework 3.5 adds a subset of the Windows Communication Foundation (WCF or "Indigo") to smart devices, allowing them to communicate with desktop WCF components with all the flexibility of multiple, interchangeable service bindings and endpoints. Although it ships out of the box only with support for message-level communication (no service calls, per se), we have a code generation tool that will allow you to call WCF or other WSDL-publishing services.

Desktop has an svcutil.exe tool that generates client proxy code, but the source code it generates cannot compile against NetCF libraries because NetCF does not include all the classes referenced from that source code. While you can modify the code by hand to eventually get it to work with NetCF, we offer an easier way.

The NetCFSvcUtil.exe tool that ships as part of the Power Toys for .NET Compact Framework 3.5 supports many of the same command-line switches that svcutil.exe does, but performs a few additional/modified steps:

Verifies that the service being consumed offers endpoints compatible with the feature subset included in NetCF 3.5.
Generates the client proxy class in C# or VB that compiles against NetCF or desktop WCF.
Generates code for a CFClientBase class that fills in where NetCF doesn't support calling WCF services.
Does not generate a .config file to store the endpoint information. This information is stored in the client proxy code. If an X509 certificate required by the endpoint, that must be passed into the proxy class' constructor by your code.

Assuming that you have a service running at http://localhost/service/service.svc on your desktop computer and a device application in your C:\deviceapp directory, you could generate the code to call the service from NetCF using the following command line. Be sure NetCFSvcUtil.exe is in your path. Also be sure to use a machine name that can be reached from your device. If you use "http://localhost/..." as your argument to the tool, your device will look for localhost (which is the device itself!) and not find the service that is running on your Windows box.

C:\deviceapp>netcfsvcutil.exe http://<machinename>/service/service.svc

The tool will generate and list two source files. The source file named after your service will be the one that contains the proxy class you'll use from your app. You can use it just like you would the svcutil.exe-generated code, except for the provision of secure endpoints made in my numbered list above.

To use these source files in your application, add them to your Visual Studio project and be sure you have System.ServiceModel.dll and System.Runtime.Serialization.dll in your project's Referenced Assemblies list in Solution Explorer. Calling your service from your device application can be as simple as a couple of lines of code:

CalculatorServiceClient client = new CalculatorServiceClient();
MessageBox.Show(client.Add(3, 5));

Some features that WSDLs and the desktop .NET WCF supports are not supported by the .NET Compact Framework 3.5. Although NetCFSvcUtil.exe generates code to enable some of these features, here is a list of features that remain unavailable for our first version of Compact WCF when calling a WCF service on desktop:

Fault contracts (they are not automatically deserialized for you, but you get the raw xml that you can parse manually)
Custom message headers (including peer hop counts)
Callback contracts
Sessions
Mandatory transactions

And the only desktop binding NetCF 3.5 supports is basicHttpBinding, with optional WS-Security (X.509 only) and no support for WS-ReliableMessaging. NetCF 3.5 adds the new mail transport as well, but NetCFSvcUtil does not support generating proxies for services exposed only on the mail transport.

It's worthwhile to note that any service or client that supports WSDL contracts should be able to intercommunicate, regardless of underlying implementation. This means that if you have a desktop WCF service that you want to call from NetCF, you may also use the already-existing Add Web Reference in Visual Studio to generate code for your client proxy class (the command line equivalent is wsdl.exe). The resulting proxy class may not have as friendly of a public API for you to use, and it won't use the WCF stack, but it is a valid alternative that will work in many cases.

The reverse is also true: you can use WCF to call into old-style .asmx web services. It is not necessary to even know which web service implementation is used on a server. So long as it publishes a WSDL, you're in luck. If it doesn't publish a WSDL, you may still be able to generate a client proxy for it as long as it uses WCF service model and you have access to the managed service assemblies. But that's another topic.

Power Toys for .NET Compact Framework 3.5 CTP released

andarno — Thu, 13 Sep 2007 02:17:00 GMT

The .NET Compact Framework team just released the Consumer Technology Preview (CTP) of the Power Toys for .NET Compact Framework 3.5. These Power Toys are tools to help you build, debug and optimizie your NetCF 3.5 applications.

My personal favorite is the NetCF ServiceModel Metadata Tool (NetCFSvcUtil.exe) which allows NetCF clients to call web services using the Compact WCF stack.

Download it and check it out!

How to (not) write an especially precarious app on .NET (Compact Framework)

andarno — Tue, 03 Jul 2007 01:33:00 GMT

As the .NET Compact Framework developers work to add features, fix bugs, and refactor code, we often have to determine whether a given change could break existing customer code. The ideal is that NetCF 3.5 will run all apps that ran on NetCF 2.0 and 1.0. We run hundreds of apps and many, many tests before shipping each product to check backward compatibility. The .NET Framework (both desktop and CF) makes heavy use of internal classes to allow us the freedom to change the internals of the framework without breaking customer code. But there are still ways that customers can write apps that may break on future versions.

Compare on exception text

Some exception types are very general and don't tell you much about the error. One of these is InvalidOperationException, which can be thrown for a wide variety of reasons for many classes in our BCLs. Developers usually look at the Exception.Message property to get an idea of what went wrong. This is by design. What is not by design is for developers to write code in their apps that looks at the Message property and makes code path decisions based on it. Here is an example: (highly contrived, admittedly)

    class Program {
        static void Main(string[] args) {
            try {
                XmlSerializer serializer = new XmlSerializer(typeof(MailAddress));
            } catch (InvalidOperationException ex) {
                if (ex.Message == "System.Net.Mail.MailAddress cannot be serialized because it does not have a parameterless constructor.") {
                    // Print message to user saying he chose a bad type to serialize
                }
            }
            // Success!
        }
    }

This can break in at least two instances:

The text in Exception.Message is localized to the computer running your app, so this code will break if it was run on, say a Spanish computer for example.
A subsequent version of .NET Framework may change the Exception.Message text to be more descriptive, accurate or whatever.

Either one of these likely cases may cause your code path to take a wrong turn (in this case to assume success). Instead, you should write code that can analyze exceptions based primarily on exception type and/or error code (enumerable or integer) where available.

Note: It is generally ok to display the Exception.Message to a user of an app in the form of a MessageBox or a log file (there are security considerations in doing this, however) and let the user choose how to proceed.

Compare on Exception type

Another bad way of doing exception handling is to do absolute equality checking on exception types. Here's another bad (and contrived) example:

    class Program {
        static void ThrowBadArgument(int positiveValue) {
            if (positiveValue <= 0)
                throw new ArgumentException("Must be positive", "positiveValue");
        }
        static void Main(string[] args) {
            try {
                ThrowBadArgument(-5);
            } catch (Exception ex) {
                if (ex.GetType() == typeof(ArgumentException)) {
                    // Oops, the user provided a non-positive number!
                }
            }
        }
    }

Now suppose that the developer (or vendor) supplying you with your ThrowBadArgument method decided it was more appropriate to throw an ArgumentOutOfRange exception. This would break your code and again cause your program to inappropriately assume success.

Here is a corrected example:

    class Program {
        static void ThrowBadArgument(int positiveValue) {
            if (positiveValue <= 0)
                throw new ArgumentOutOfRangeException("Must be positive", "positiveValue");
        }
        static void Main(string[] args) {
            try {
                ThrowBadArgument(-5);
            } catch (ArgumentException ex) {
                // Oops, the user provided a non-positive number!
            }
        }
    }

Note in this latter example how the throwing method is using the derived class. But catching the base class in this way allows us to catch either ArgumentException or ArgumentOutOfRangeException equally well.

And if you need to check the exception type using an if statement (to check the type of Exception.InnerException for example) be sure to use the is keyword rather than Exception.GetType() == typeof(...). For example:

// good example
if (ex.InnerException is ArgumentException) {
    // do stuff based on inner exception
}
// Another good example (albeit harder to read)
if (typeof(ArgumentException).IsInstanceOfType(ex.InnerException)) {
}

// BAD example
if (ex.InnerException.GetType() == typeof(ArgumentException)) {
    // do stuff based on inner exception
}

Finding public methods using reflection and parameter names

There's no good way to do this. You should only find methods based on the parameter types, not parameter names. The reflection API makes it easy to do it right, and harder to do it wrong. Here is an example on how to do it right, and wrong:

    class Program {
        static void Main(string[] args) {
            // Good example
            MethodInfo m = typeof(int).GetMethod("ToString", new Type[] { typeof(CultureInfo) });
            Console.WriteLine(m.Invoke(3, new object[] { CultureInfo.CurrentCulture }));
            
            // Bad example
            foreach (MethodInfo method in typeof(int).GetMethods()) {
                ParameterInfo[] parameters = method.GetParameters();
                if (parameters.Length == 1 && parameters[0].Name == "provider") {
                    m = method;
                    break;
                }
            }
            Console.WriteLine(m.Invoke(3, new object[] { CultureInfo.CurrentCulture }));
        }
    }

You should not take a dependency on parameter names of methods you call. The .NET compilers take care of this for you, but if you go around them by using reflection and use parameter names rather than parameter types to find the method overload you want, you're asking to be broken if those method parameter names ever change (and they can!)

Finding internal-only methods or types using reflection

Again, there is no right way to do this. Getting into the internals of a library by using reflection requires full trust and means you're just asking for your app to break in the next version of the library when those internals get changed.

In conclusion...

If you follow these tips, your apps will be more likely to perform well on current and future versions of the .NET Framework, on your own as well as your customers' locales.