warning CS0618: ‘Device.OS’ is obsolete: ‘TargetPlatform is obsolete as of version 2.3.4. Please use RuntimePlatform instead.’

Here is a couple of compiler generated warnings I found on project I was recently reviewing:

  1. warning CS0618: ‘Device.OS’ is obsolete: ‘TargetPlatform is obsolete as of version 2.3.4. Please use RuntimePlatform instead.’
  2. warning CS0612: ‘TargetPlatform’ is obsolete

A CS0612 is generated when the code references a type or member to wich the parameterless ObsoleteAttribute was applied.

CS0618 is generated when the code references a type or member to wich a parameterized ObsoleteAttribute was applied.

In this case, the reference to Device.OS has to be replaced with a reference to Device.RuntimePlatform.

Since Device.OS was an enum of type TargetPlatform and Device.RuntimePlatform is a string, it is necessary to update the right hand of the expression as well.

For that you can use one of the string constants defined on the Device class:

  • iOS;
  • Android;
  • WinPhone;
  • UWP;
  • WinRT;
  • macOS;

Here’s how the code looked like originally:

And here’s how the looks code after the update:

We need a tool that combines functionality of xsd.exe and sgen.exe

I added a suggestion on Microsoft Connect asking for something with the combined functionality of xsd.exe and sgen.exe.

Given an xml schema file (xsd), you could use xsd.exe to generate a set of classes that could be serialized in conformance with that schema.

Then to perf things up a little bit, you could use sgen.exe to create an assembly containing specialized serializers for the classes generated previously.

You would end up with two assemblies for something that, in my opinion, would be better handled with one. For instance, with only one assembly there would be no risks of mismatching versions of the Serializable and Serializer assemblies.

You can work around having an extra assembly using sgen’s “/k” option which keeps on your project’s folder the temporary files used to create the serializer assembly. Among those files, there’s one with the source code.

There are some caveats though:

First, sgen only generates code in C#. If your project is in Visual Basic, then you have to take some extra steps to integrate the code into your code base.

Second, each time you run sgen, it creates a new file with a random name. You’ll have to rename it to something that’s stable enough to be used in your project. This can be done with some pre or post build events, but things can eventually get wrong.

 

If you feel my pain, please vote on:

https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=416020