title: How can I overcome Windows Component limitation to windows runtime types?
body: <p>I have a Windows Store application that uses a background task. The background task is stored in a Windows Runtime Component project. (This structure appears to be the only way to make background tasks work.)</p>
  
  <p>In the background task project, I have some externally visible public methods that have return/parameter types that are my own classes rather than Windows Runtime classes.</p>
  
  <p>For example:</p>
  
  <pre><code>public MyClass DoSomething()
  {
      return null;
  }
  </code></pre>
  
  <p>When I build, I receive errors such as the following in relation to these methods:</p>
  
  <blockquote>
    <p>Method 'X' returns 'Y', which is not a valid Windows Runtime type.  Methods exposed to Windows Runtime must return only Windows Runtime types.</p>
  </blockquote>
  
  <p>and</p>
  
  <blockquote>
    <p>Method 'T' has parameter 'U' of type 'W'. 'W' is not a valid Windows Runtime parameter type.</p>
  </blockquote>
  
  <p>I can understand what the errors are saying, but I haven't thought of a good way I can structure my code so that I meet these requirements.</p>
  
  <p>Here are some things I have already considered:</p>
  
  <ol>
  <li>Changing the background task project to a Windows Store Class Library project. This allowed the use of the non-Windows Runtime types in the method signatures, but the background task no longer launched.</li>
  <li>Using a portable class library. This didn't work because it didn't have access to the Windows Runtime.</li>
  <li>For value types, I can break them up into <code>Tuple</code>s or multiple parameters, but this seems messy, less structured and less maintainable. I am strongly against this type of programming.</li>
  <li>For classes, it seems that I might have to duplicate their logic across both applications. This is a huge maintainability problem.</li>
  </ol>