Visual Studio 2015: Intellisense-Fehler, aber Lösung kompiliert

Question

Wir bewerten derzeit das neue Visual Studio 2015 und stieß auf ein seltsames Problem mit Intellisense. Als ich unsere Hauptlösung mit dem neuen Studio kompiliert habe, ist der Build erfolgreich, aber trotzdem werden 6 Fehler angezeigt.

Ich entdeckte, dass es kein echter Fehler ist, sondern nur ein Intellisense-Fehler. Der Code ist definitiv korrekt und alles wurde erfolgreich kompiliert. Der Code ist jedoch rot markiert und es erscheinen Fehler in der Fehlerliste.

Alle 6 Fehler haben den gleichen Ursprung. Es ist ein einfacher Konstruktoraufruf. Seltsam genug, aber es gibt auch einige Vorkommen des exakt gleichen Konstruktors ohne irgendwelche Fehler.

Die Fehlermeldung:

Code: CS1729 
Message: '<the class>' does not contain a constructor that takes that many arguments. 
Project: <the project name> 
File: <the path to the file> 

Das neue Studio auf einem neu installierten Windows 7 ohne Legacy-Software (kein VS13) installiert wurde.

Ich habe schon versucht, die Caches zu löschen, löschte die SUO-Datei, gelöscht bin und Obj Verzeichnisse, gereinigt und neu aufgebaut die Lösung usw. Aber nichts hat funktioniert.

Kann mir jemand dieses Verhalten erklären?

Answer 1

Auch hatte dieses Problem mit einem migrierten Projekt, so referenzierte ich die Microsoft.CSharp dll. In einigen Projekten musste ich die Referenz im Projekt entfernen und hinzufügen.

Answer 2

Auch hatte dieses Problem (der Titel, nicht die spezifische Fehlermeldung), sowie squiggly Zeilen im Editor. Die erste Squiggly-Zeile befindet sich unter der ersten #include-Anweisung, die einen vorkompilierten Header bezeichnet. Intellisense schließt den vorkompilierten Header nicht ein, führt diesen jedoch nicht als Fehler auf; Stattdessen listet es Fehler weiter unten in der Datei auf, die (sehr zu Recht) auf Deklarationen im vorkompilierten Header basieren.

Der Grund, dass Intellisense den vorkompilierten Header in meiner Umgebung nicht findet, ist, dass der angegebene Header keine tatsächliche Datei ist. Es muss nicht in einer anderen VC- oder gcc-Version sein, die ich verwendet habe, noch im Compiler von 2015, solange die vorkompilierten Header-Einstellungen korrekt konfiguriert sind. Anscheinend nicht mehr für Intellisense. Ich bin mir nicht ganz sicher, ob es 2013 anders war, vielleicht habe ich es einfach nie bemerkt. Im unwahrscheinlichen Fall, dass dies das hier gemeldete Problem wäre, ist die Lösung einfach: Erstellen Sie eine kleine Datei mit dem Vornamen des vorkompilierten Headers, wie in den Anweisungen #include angegeben, und lassen Sie diese Datei den tatsächlichen Namen enthalten des vorkompilierten Headers.

Wenn Sie sich fragen ... warum diese Unterscheidung zwischen dem vorkompilierten Header-Namen in der '# include' Anweisung und dem tatsächlichen Dateinamen des vorkompilierten Headers? Gerade weil es garantiert, dass vorkompilierte Header-Einstellungen korrekt konfiguriert sind. Überall dort, wo ein vorkompilierter Header "#included" ist, kann keine Datei enthalten sein. Entweder wird eine tatsächlich vorkompilierte (binäre) Version des aktuellen Headers gelesen oder die Kompilierung schlägt fehl. Offensichtlich ist ein Nachteil, dass es Menschen verwirrt den Code lesen, nicht nur Intellisense.

Answer 3

Ich hatte Tausende von IntelliSense-Fehlern und 0 Build-Fehler. Nach dem Löschen der .su-Datei ist ein Neustart von VS intellisense-Fehlern nicht mehr möglich.

Suo-Datei befindet sich relativ zu Quelle in: .vs \ Solution \ v14.suo

Kommentar nach: Beachten Sie, dass *.suo ist eine versteckte Datei.

Edit: Nach Kommentaren, VS2017 das gleiche Problem hat, so dass Sie ähnliche Lösung verwenden können: Löschen .vs \ Solution \ v15.suo

Answer 4

Heute habe ich ähnliches Problem mit MSVC habe ++ 2015 gab ich fast up und entschied sich, ohne IDE-Hinweise weiterzumachen, aber gelegentlich habe ich bemerkt, dass stdafx.h des Teilprojekts, mit dem ich Probleme hatte, keine Standard-Bibliotheks-Header enthält. Ich schlug vor, dass es die Modulkompilierung verlangsamen könnte, aber die Einbeziehung der Standard-Header dort behoben Intellisense auch.

Answer 5

In ähnliches Problem in Visual Studio 2017 ASP.Net Core-Projekt. Folgende Schritte haben den Trick für mich

1. durch Ausführen eines saubere Lösung
2. Schließen VS
3. .suo Datei & löschen ist/obj Verzeichnisse löschen
4. VS wieder öffnen

Answer 6

Ich hatte mehr stdfax.h in Zusätzliche Include-Verzeichnisse Stellen Sie sicher, dass die von Ihnen gewünschte stdafx.h zuerst in Ihrem Pfad ist.

Answer 7

Ähnliches Problem wie andere, aber unterschiedliche Auflösung. Für den Fall, dass ich jemand anderem helfen kann.

Ausführen von Visual Studio 2017 15.5.2. Ich benutze Git und wechsle häufig Zweige. Vor einigen Wochen fing ich an, Editoren zu haben, die mir Fehler zeigten (alle bezogen auf Typen, die nicht gefunden werden konnten, obwohl Referenzen gültig waren). Compile hat super funktioniert. Ich habe das gleiche Thema in VS 2017 15.6 Preview (6. Januar 2018) bestätigt. Ich würde versuchen, Cache-, SUO-Dateien oder bin/obj-Ordner und keine Auswirkungen zu löschen. Zuerst scheint es zu funktionieren. Öffnen Sie Visual Studio und alles würde gut aussehen. Verwenden Sie "Lösung neu erstellen", und die IntelliSense-Fehler werden zurückgegeben. Ich habe sogar versucht, Visual Studio zu deinstallieren/neu zu installieren.

Ich hatte das gleiche Problem auf zwei Rechnern, beide mit der gleichen Version von Visual Studio.

Wenn man sich die Fehler über fehlende Typen anschaut, scheinen alle aus zwei referenzierten Projekten zu stammen. Eine dieser Referenzen war ein gemeinsames Projekt, das von fast jedem anderen Projekt in der Lösung verwendet wurde, aber eines davon war ein kleines Projekt ohne viele Referenzen. Zufälligerweise wurde das kleine Projekt auch von meinem größeren gemeinsamen Projekt referenziert. In Visual Studio habe ich das kleine Projekt entladen und neu geladen. Die Fehler gingen weg! Sie sind nicht auf Rebuild Solution zurückgekommen.

Ich wechselte dann Git Zweige und die Fehler kamen alle zurück. Glücklicherweise wiederholte ich die obigen Schritte des Entladens/Neuladens des kleinen Projekts und die Fehler verschwanden.

Jedes Mal, wenn ich die Git-Verzweigungen umschalte, kommen die Fehler zurück, bis ich diesen Vorgang wiederhole. Es gibt keine Änderungen zwischen den Git-Verzweigungen für das kleinere Projekt, das ich entlade/neu lade. Unklar, warum diese Sequenz mein Problem behebt.