Create NuGet package for C++/CLI (mixed) assembly
<p>I have created a C++/CLI (mixed) assembly which has a managed wrapper class around some unmanaged C++ code. The managed part targets .NET 4.6.1, I got a file <code>entry.cpp</code> with just this line to do that:</p>

<pre><code>[assembly:System::Runtime::Versioning::TargetFrameworkAttribute(L".NETFramework,Version=v4.6.1", FrameworkDisplayName = L".NET Framework 4.6.1")];
</code></pre>

<p>When I now manually include the compiled assembly in a .NET 4.6.1 project I can use the managed class as expected.</p>

<p>This project can be build four ways: <em>x86</em> or <em>x64</em> as either <em>debug</em> or <em>release</em> build. It has no managed dependencies.</p>

<p>Now I want one (or if required multiple) NuGet packages which I can upload to my feed and use the wrapper assembly easily in every .NET 4.6.1 compatible project I would like. <strong>How do I achieve this?</strong></p>

<hr>

<p>So far I tried two approaches:</p>

<p>First, I created a <code>.autopkg</code> file which is according to <a href="http://blogs.techsmith.com/inside-techsmith/nuget-packages-3/" rel="noreferrer">this blog post</a> the way to provide native DLLs. The <code>files</code> section of that file looks like this:</p>

<pre><code>files {
  // include: { *.h }; 
  [x86,v120,release] {
     symbols: { ..\Release\*.pdb; }
     bin:     { ..\Release\*.dll; }
  };
  [x86,v120,debug] {
     symbols: { ..\Debug\*.pdb; }
     bin:     { ..\Debug\*.dll; }
  };
};
</code></pre>

<p>This process results in three <code>.nupkg</code> files which I can upload to my feed. But when I try to install that package to a .NET 4.6.1 project I get this error message:</p>

<blockquote>
  <p>Could not install package 'MyCppCliWrapper.redist 1.0.0.2'. You are trying to install this package into a project that targets '.NETFramework,Version=v4.6.1', but the package does not contain any assembly references or content files that are compatible with that framework. For more information, contact the package author.</p>
</blockquote>

<hr>

<p>So I rethought if I should not use the way for managed assembly to create the <code>.nupkg</code> because the assembly has a managed class I want to use from managed code. I created a <code>.nuspec</code> (using <code>nuget spec</code>) and provided the metadata. Then I try to create my package like this:</p>

<pre><code>nuget pack MyCppCliWrapper.nuspec -Prop Configuration=Release -Prop Platform=x86 -Build
</code></pre>

<p>But that results in a package which contains the whole project with all source files and temporary files, just like a zip file of that folder.</p>

<p>Obviously there is also missing the meta information about targeted framework.</p>

<p>When I try to use the project file to create the package (like with C# assemblies) this fails too:</p>

<blockquote>
  <p>Please specify a nuspec, project.json, or project file to use</p>
</blockquote>

<p>The C++ project files, <code>.vcxproj</code>, seem to be unsupported by NuGet (I am using the NuGet 3.5.0.1938 command line utility).</p>

<p>Will I need to build manually and provide all files in the <code>files</code> section of the <code>.nuspec</code>? If yes, how would he know from this line which DLL is for which .NET framework plus platform?</p>

<pre><code>&lt;file src="bin\**\*.dll" target="lib" /&gt;
</code></pre>

<hr>

<p>I believe Hans Passant is right, this is just a <em>regular</em> managed nuget package but the packager does not handle the <code>.vcxproj</code> files so I made up my own <code>.nuspec</code>:</p>

<pre><code>&lt;?xml version="1.0"?&gt;
&lt;package &gt;
  &lt;metadata&gt;
  ...
  &lt;/metadata&gt;
  &lt;files&gt;
    &lt;file src="readme.txt" target="" /&gt;
    &lt;file src="bin\Win32\Release\*.dll" target="lib\net461" /&gt;
    &lt;file src="bin\Win32\Release\*.pdb" target="lib\net461" /&gt;
  &lt;/files&gt;
&lt;/package&gt;
</code></pre>

<p>The package generated this ways works.</p>

<p>There is one question remaining: This way, do I have to do two packages, one for 32bit and one for 64bit - or is it possible to include them in one package (which I would prefer) and have the consuming project use one or another depending on the target architecture (any-cpu is mostly 32bit)?</p>