File name based IO

Shim enables file name based I/O, such as File.OpenRead(string path). In practice, on individual target platforms, these implementations may work only partially or not at all due to I/O restrictions on these platforms.

Silverlight 5 will normally require elevated trust for a method like File.OpenRead(string) to work, under normal conditions Silverlight only supports isolated storage I/O.

In Windows 8 applications it is necessary to set the application capability to support regular I/O operations on the file system, and on Windows 8.1 this capability has been deprecated; only removable media I/O can be enabled.

Windows Phone suffer similar limitations.

In conclusion, even though Shim allows code containing e.g. System.IO.File calls to compile, you are generally recommended not to use those methods in practice.

The recommended workaround is instead to ensure that the API of the legacy code allows for System.IO.Stream input and output, because Stream works without limitations across all target platforms. If there are not already methods supporting Stream input and/or output, add them to the legacy code.

For example, if your legacy code contains a method like this:

string ParseFile(string fileName) {
    var fileStream = File.OpenRead(fileName);
    ... operate on fileStream
    return parsedValue;
}

If there is not already a Stream based overload for this method, add one!

string ParseFile(Stream fileStream) {
    ... operate on fileStream
    return parsedValue;
}

The point with Shim is to make as few intrusions to the original legacy code as possible, so I will not recommend complete removal of the string based overload. What you should do, however, is to attach the [Obsolete] attribute to this method:

[Obsolete]
string ParseFile(string fileName) { ... }

Now, in the application code you should thus first create the Stream object using the platform-specific I/O operations, and then call ParseFile(Stream) directly.