2016-10-26 5 views
5

Wir haben eine C# DLL in. Net4.0, aber mit Microsoft.bcl, Microsoft.bcl.async, Microsoft.bcl.build gebaut , Microsoft.net.http. Diese Bibliotheken stammen von nuget. Wir haben Gründe, nicht zu .net4.5 zu wechseln, sondern async zu verwenden, und warten auf diese bcl-Bibliotheken. Alles funktioniert in C# -Projekten in Ordnung, aber wir konnten diese DLL in unserem C++ Interop-Projekten hinzufügen, erhalten wir diesen Fehler:Verwendung von C# DLL (mit Microsoft.bcl gebaut) in Interop (C++ verwaltet) Projekt

Wir erhalten diesen Fehler, wenn wir versuchen, diesen Verweis hinzuzufügen zu projizieren.

Obwohl Clr Interop-Projekt ist auch in. Net4.0 und DLL, die wir hinzufügen, ist auch in. Net4.0 wir am Ende bekommen diesen Fehler. Gibt es eine Möglichkeit, dies zu lösen?

Error in text format: 
--------------------------- 
Microsoft Visual Studio 
--------------------------- 
Could not add a reference to: 

C:\xxx\xxx\xx\xxxHelper.dll 



For one of the following reasons: 

    - Targets a higher version of the .NET Framework 

    - Not a .NET assembly 

    - Not a registered ActiveX control 
--------------------------- 
OK 
--------------------------- 

Code, um dieses Problem zu reproduzieren: https://dl.dropboxusercontent.com/u/1967630/BCL_Problem/oAuth2_SDK_consumer_DLL/BCL_Problem_projects.zipx

+2

Bitte geben Sie immer die textuelle Darstellung des Fehlers an. Nicht für Sie, sondern wegen der Stackoverflow-Indexierung, um Wiederholungen zu vermeiden. Der Fehler, den Sie erhalten, liegt vermutlich daran, dass C# -Projekt nach C++ erstellt wird. Versuchen Sie zunächst, C# 1 zu erstellen und dann C++ manuell zu erstellen. – eocron

+0

fertig, danke für die Eingaben. Nein, das ist bei mir nicht der Fall. Ich erhalte diesen Fehler, wenn ich versuche, C# dll als Verweis auf C++ - Projekt hinzuzufügen. – rplusg

+0

Haben Sie versucht, die Bitanzahl (x86/x64) der C# - und C++ - Anwendungen zu variieren? – Dmitry

Antwort

3

ich repro, sieht sicher wie ein Fehler. Gemessen an der Fehlermeldung in Ihrem Screenshot verwenden Sie VS2013. Sehr wenig hilfreiche Nachricht, es wurde in VS2015 abgeschwächt, scheitert aber immer noch. Odd bug btw scheint die Microsoft.Threading.Task-Assemblyreferenz zu behandeln, die Ihr C# -Projekt als Framework-Assembly verwendet. Keine vorherigen SO-Fragen zu diesem Problem, die ich kenne, die meisten Programmierer bekommen das richtig, ohne gegen die Maschine kämpfen zu müssen.

Sie sollten es so machen, wie sie es tun, um diesen Fehler zu vermeiden. Dies geht nur schief, wenn Sie die Schaltfläche Durchsuchen im Dialogfeld Verweis hinzufügen verwenden. Aber es funktioniert gut, wenn Sie eine Projektreferenz verwenden, so wie es die meisten Programmierer bevorzugen, ihre Lösung zu konfigurieren. Verwenden Sie also Datei> Hinzufügen> Vorhandenes Projekt, wählen Sie Ihr C# -Projekt. Fügen Sie dann erneut einen Verweis hinzu, wählen Sie jedoch dieses Mal das C# -Projekt aus der Liste Lösung> Projekte aus, anstatt die Schaltfläche Durchsuchen zu verwenden.

Wenn dies aus irgendeinem Grund nicht wünschenswert ist, können Sie dies auf andere Weise umgehen. Öffnen Sie Ihre .vcxproj in einem Texteditor, Editor ist in Ordnung. Suchen Sie dieses Element:

<TargetFrameworkVersion>v4.0</TargetFrameworkVersion> 

Und ändern Sie die Versionsnummer zu v4.5. Fügen Sie nun die Referenz wie zuvor mit der Schaltfläche Durchsuchen hinzu, diesmal keine Beschwerden. Und zurück zum Editor und ändern Sie die Versionsnummer wieder auf v4.0

+0

Vorhandener Fehlerbericht [ist hier] (https://connect.microsoft.com/VisualStudio/feedback/details/794976/in-ac-project-cannot-add-reference-to-ac-project), schwer vorstellbar ist nützlich. –

+0

Ich habe fast jede Option und Kombinationen ausprobiert, hat nicht funktioniert.Ein Fall mit Microsoft-Unternehmensverbindungen archiviert, und sie sind weniger als hilfreich. Also, ich postete hier mit einem Kopfgeld. Danke für den Blick. – rplusg

0

Wenn nichts anderes hilft, können Sie versuchen, Ihre DLL zu dekompilieren. .Net Baugruppen sind leicht umsteuerbar.

Das erneute Kompilieren kann das Problem lösen (z. B. könnte Ihre DLL von niget 4.5, nicht 4.0 sein).

+0

DLL von nugget sind .net4.0, sicher. Ich benutzte Disassembler und Header-Informationen sagt. NET 4.0. – rplusg