Wenn Sie versuchen, Verweise auf VSIX hinzuzufügen, werden diese normalerweise aus den Verweisen in der .csproj abgerufen. Wenn sich die Verweise jedoch nicht in der Datei .csproj befinden, weil sie sich jetzt in einer Datei project.json befinden, werden sie nicht in die Datei vsix gezogen. Die Lösung kann dann kompilieren, aber dann schlägt die Erweiterung mit "Datei nicht gefunden" fehl, wenn sie in Visual Studio installiert wird (da die Assemblys nicht in VSIX kopiert wurden).Fügen Sie project.json-Paketverweise zu einem VSIX hinzu.
Ich habe versucht, mit dem Abschnitt des Manifests in etwa so:
<Asset Type="Microsoft.VisualStudio.Assembly" d:Source="Project" d:ProjectName="*PROJECTNAME*" Path="|*ASSEMBLYNAME*|" AssemblyName="|*ASSEMBLYNAME*;AssemblyName|" />
Aber es funktioniert nicht, da es nicht die Paketreferenzen nicht erkennt.
Nach einigen Recherchen habe ich ein ähnliches Problem mit einem PCL sah jedoch ohne Antwort und nicht die gleiche Art von Problem: MEF With Portable Class library using Microsoft Composition MEF2 throws file not found exception
In derselben Note, scheint dies wie eine akzeptable Lösung: VSIX with Project Templates and NuGet Packages jedoch als Soweit ich das verstanden habe, impliziert dies die Verwendung des Pakets während der Installation. Außerdem funktioniert es nicht für unseren Fall, da sie die Paketversion angeben müssen und wir project.json verwenden, so dass wir Floating-Versionen verwenden können (zB: 2.0. *)
Gibt es eine Möglichkeit, dies zu referenzieren project.json verweist darauf, dass wir fehlen? Vielleicht ein Workaround? Die Lösungen, die ich gefunden habe, scheinen alle zu benötigen, um die DLL irgendwo "einzufügen", was für Floating-Versionen nicht so praktisch ist.
Vielen Dank im Voraus für jede Hilfe oder Eingabe.
Bearbeiten/Aktualisieren: Da VSIX automatisch eine Assembly verschiebt, auf die im CSPROJ verwiesen wird (und nicht das Projekt selbst), erscheint der Versuch, die DLLs auf Projektebene zu erhalten, unwahrscheinlich. Nach vielen Versuchen denke ich, dass eine gültige Problemumgehung wäre, die Assemblys aus dem Ausgabeordner abzurufen. Aber meines Wissens hat VSIX keine Möglichkeit, dies zu tun, oder?
Es ist seltsam, dass es so viele upvotes bekommt. Sollte die Problemumgehung hier nicht sein: _project.json an erster Stelle nicht verwenden? project.json wird in den nächsten Monaten fallengelassen und Microsoft wird anfangen, die Funktionalität von project.json wieder in gute alte csproj zu verschieben. Warum verwenden Sie project.json? Benötigen Sie einen Dotnet-Core in einer Visual Studio-Erweiterung? Wie? Warum? So viele Fragen! – Joao
[Hatte das rückwärts in meinem vorherigen Kommentar, den ich gelöscht habe] In unserem Fall versuchten wir, mit der Tatsache umzugehen, dass VS 2015 Update 3 eine ältere Version von System.Collections.Immutable als Roslyn verwendet, also stießen wir auf dieses Problem Artikel, der erklärt, wie die Version dieser Assembly auf 1.1.37 heruntergestuft wird, um eine Erweiterung zu erstellen, die Roslyn verwendet.An diesem Punkt begannen wir mit dem Problem, dass DLLs nicht mit dem VSIX-Paket bereitgestellt werden, und fanden diese SO-Frage mit demselben Szenario. – fussmonkey
FWIW Ich habe gehört, dass project.json wieder auf project.xxproj zurückgesetzt wurde - siehe diesen Blogpost https://blogs.msdn.microsoft.com/dotnet/2016/05/23/changes-to-project-json/ –