Laden...

Projekte verlieren Referenzen

Erstellt von danieljena vor 3 Jahren Letzter Beitrag vor 3 Jahren 1.732 Views
D
danieljena Themenstarter:in
38 Beiträge seit 2015
vor 3 Jahren
Projekte verlieren Referenzen

Hallo Leute,
Ich nutze VS2019CE.

In letzter Zeit bin ich fast Wahnsinnig geworden.
Ich arbeite an verschiedenen Rechnern und übertrage meine Projektordner immer mit Strick etc.
Nun ist mir aufgefallen, dass bei vielen Projekten (in einer Solution) folgende zwei Fehler auftreten:

  • alle !=Projektereferenzen werden verloren und die Einträge im Baum bekommen ein gelbes Dreieck
  • die Textfelder in den Assembly-Informationen (Projekt-Properties) sind leer.

Hat noch jemand diesen Fehler?
Woran kann es liegen?
Reparaturinstallation von VS hat nichts gebracht.

Aufgedeckt habe ich bisher folgendes:
1.
Erstelle ich an PC1 (aktuelles Win10Pro) ein Projekt und übertrage den Ordner mit Stick auf PC2 (ebenfalls aktuelles Win10Pro) werden die Referenzen verloren.
Starte ich die Projekte am gleichen PC passiert auch nach Tagen (inkl mehrerer Neustarts) nichts.
Kann dies an NTFS Berechtigungen etc liegen, auf den beiden PCs ist jeweils ein eigener normaler Benutzer.
2.
Der Fehler tritt ab zwischen Spätsommer 2019 und Frühjahr 2020 auf.

Jemand ne Idee 😦
danieljena

16.807 Beiträge seit 2008
vor 3 Jahren

Wenn sowas passt ist das ein Hinweis auf ein falsches Handling von Solutions.

  • Redest Du von Projektreferenzen oder NuGet oder Assembly oder...?
  • Du hast Solutions so aufgebaut wie es für .NET Anwendungen empfohlen ist?
D
danieljena Themenstarter:in
38 Beiträge seit 2015
vor 3 Jahren
  • Redest Du von Projektreferenzen oder NuGet oder Assembly oder...?

Projectreferenzen werden behalten, alle anderen (egal ob NuGet oder Assemblys) werden verloren

  • Du hast Solutions so aufgebaut wie es für .NET Anwendungen empfohlen ist?

Wie meinst du das?
Dann stellt sich mir aber die Frage, warum erst ab leztes Jahr Spätsommer, die Solution ist definitiv älter.

16.807 Beiträge seit 2008
vor 3 Jahren

Naja, es gibt klare Empfehlungen wie Solutions (=Projektmappen) aufgebaut werden, wo darin Assemblies liegen und wie NuGet referenziert wird.
Riecht danach, dass da was nicht stimmt.

Dann stellt sich mir aber die Frage, warum erst ab leztes Jahr Spätsommer, die Solution ist definitiv älter.

Möglicherweise ein schleichender Folgefehler. Würde das nun nicht auf das Tooling schieben...

D
danieljena Themenstarter:in
38 Beiträge seit 2015
vor 3 Jahren

Ich hab jetzt den Fehler höchstwahrscheinlich gefunden.
Alle Projekte die ich auf PC1 (privater Rechner) erstellt habe, funktionieren dort, verlieren jedoch auf PC2 (dienst-Rechner in einen WinAD-Verbund) die Referenzen.
Umgedreht werde ich nachher gleich testen.

Meine genutzten Assemblys habe ich bisher immer über ganz normale Dialogfenster referenziert, wurden also aus c:\prog x86\ref.a.\net... gezogen.

Der Verlust von Nuget-Referenzen ist mir bisher schleierhaft, hier werden die Files doch im packages-Ordner in der Projektmappe abgelegt und per relativen-Pfad verwendet. Oder stimmt das nicht?

16.807 Beiträge seit 2008
vor 3 Jahren

Meine genutzten Assemblys habe ich bisher immer über ganz normale Dialogfenster referenziert, wurden also aus c:\prog x86\ref.a.\net... gezogen.

Du gibst ja leider genau 0 Infos von welchen Projekttypen oder ob .NET Framework oder .NET Core zu sprichst; aber mühsam ernährt sich das Eichhörnchen.
Da Du offenbar vom GAC sprichst /oder meinst, wirst Du also .NET Framework haben und die .NET Framework Assemblies meinen.

Hätten ja auch Drittanbieter Assemblies, SDK Assemblies oder Whatever sein können. Gab ja keine Info.

  • Classic .NET Assemblies werden eigentlich aus dem GAC Folder (und nur über den Namen!) referenziert
  • Die meisten Assemblies können (auch für .NET Framework) mittlerweile aus NuGet konsumiert werden
  • Reference Assembly Folder in Program Files (den wirste wohl meinen, auch wenn ich raten muss) ist nicht für das Referenzieren gedacht, das ist NICHT der GAC. Dieser Ordner existiert (in vollem Umfang) nur auf Entwicklermaschinen und hat SDK Files.
    Auf jeder Maschine ohne das entsprechende SDK knallts zur Runtime.
    Siehe auch .NET History: evolution of design time assemblies

Da dies also nur Contract Assemblies sind, die in besagten Ordner liegen heisst das nicht, dass Du diese Assemblies einfach so referenzieren solltest.

In 99,999% der Fälle referenzierst Du Framework Assemblies klassisch über den Assembly Dialog und nicht über die manuelle Suche und den Verweis auf den SDK Folder;
Das führt dann auch dazu, dass die Verweise nicht über irgendwelche Pfade in der *.proj Datei angelegt werden sondern eine namentlicher Verweis ähnlich wie bei NuGet erfolgt.


  <ItemGroup>
    <Reference Include="System" />
    <Reference Include="System.Data" />
    <Reference Include="System.Deployment" />
  </ItemGroup>

Und eben modern über NuGet.

Ich würde nun also behaupten: Du referenzierst falsch, sofern Du nicht bewusst wirklich die Eigenschaften von Contract Assemblies willst.

Der Verlust von Nuget-Referenzen ist mir bisher schleierhaft, hier werden die Files doch im packages-Ordner in der Projektmappe abgelegt und per relativen-Pfad verwendet.

Primär lädt NuGet die Dateien in einen lokalen Cache Folder Deines Userprofiles, sodass er nicht dauernd von NuGet laden muss.
Pakete werden dann bei Verwendung (bei .NET Framework) in die Solution Folder kopiert.

.NET Framework hat noch nie das Kopieren von Paketen gemocht. Noch nie.
Was sich in der Zwischenzeit geändert hat; das kann Dir hier keiner sagen.

Die Vermutung liegt nahe, dass Du was am Projekt oder am Tooling geändert hast und Dir die Auswirkungen unklar waren.
"Ich hab nichts gemacht" hat sich in 99% der Fälle so rausgestellt, dass eben was passiert ist, was dem User nicht klar war - oder doch was geändert hat aber das vergessen hat.

Die bessere Variante ohnehin wäre, wenn Du eine Quellcode-Verwaltung verwenden würdest statt die USB Stick (nicht Strick!) Kopiererei.
Dann hättest zum einen die historische Nachvollziehbarkeit und zum anderen ist das das Synchronisieren viel einfacher und weniger fehleranfällig - und Teil des vorhandenen Tooling in Visual Studio.

D
danieljena Themenstarter:in
38 Beiträge seit 2015
vor 3 Jahren

Du gibst ja leider genau 0 Infos von welchen Projekttypen oder ob .NET Framework oder .NET Core zu sprichst; aber mühsam ernährt sich das Eichhörnchen.
Da Du offenbar vom GAC sprichst /oder meinst, wirst Du also .NET Framework haben und die .NET Framework Assemblies meinen.

Ja, Sorry, ich nutze NF 4.7.2

Reference Assembly Folder in Program Files (den wirste wohl meinen, auch wenn ich raten muss) ist nicht für das Referenzieren gedacht, das ist NICHT der GAC. Dieser Ordner existiert (in vollem Umfang) nur auf Entwicklermaschinen und hat SDK Files.

Das wusste ich bisher nicht, ich habe die ganz normal die Einträge vom Referenzierungsfenster in VS verwendet. Aber, der genannte Ordner existiert auf beiden PCs.
Warum hier bei mir nicht auf den GAC gegriffen wird, keine Ahnung.

In 99,999% der Fälle referenzierst Du Framework Assemblies klassisch über den Assembly Dialog und nicht über die manuelle Suche und den Verweis auf den SDK Folder;
Das führt dann auch dazu, dass die Verweise nicht über irgendwelche Pfade in der *.proj Datei angelegt werden sondern eine namentlicher Verweis ähnlich wie bei NuGet erfolgt.

Ich habe nicht manuell referenziert, bin im Ref.Fenster links auf Assemblys und hab mir die notwendigen Einträge ausgewählt. Woher dann die Files gezogen wurden, war mir bisher auch nicht bewusst.

Die bessere Variante ohnehin wäre, wenn Du eine Quellcode-Verwaltung verwenden würdest statt die USB Stick (nicht Strick!) Kopiererei.

Leider kann ich nur lokale Repos verwenden, aber damit dürfte es ja auch funktionieren. Meine Dienststelle macht mit bei GitHub leider einen Strich durch die Rechnung
Strick = Stick = Ja, mhm, ein blöder Tippfehler 😃

Gerade mal in einer *.proj geschaut:


<Reference Include="System" />
<Reference Include="System.Data" />
<Reference Include="System.Xml" />

Die stehen z.B. so drin, und bekommen trotzdem ein gelbes Dreieck.

16.807 Beiträge seit 2008
vor 3 Jahren

Die stehen z.B. so drin, und bekommen trotzdem ein gelbes Dreieck.

Dann ist es prinzipiell richtig referenziert wenn es so in der Projektdatei steht.
Dann referenzierst Du auch (nicht explizit) keine Contract Assemblies; das passt dann soweit.

Lösch mal den *.vs Folder und starte Visual Studio neu.

Im *.vs Ordner legt Visual Studio lokale (Cache)-Dateien an; diese sollten zB auch nicht in SCM synchronisiert und auch nicht auf andere Systeme übertragen werden.

D
danieljena Themenstarter:in
38 Beiträge seit 2015
vor 3 Jahren

Leider hat dies nichts geholfen.

Wie bereits geschrieben funktioniert eine Übertragung der Projekte vom privat PC zum dienstlichen nicht richtig. Umgekehrt funktioniert es jedoch wunderbar.
Muss also irgendwie an meinem PC liegen 😦

Der übertragene Projekt-Ordner im Fall zwei hat dann auf meinen PC sowohl für die Admin- als auch für die Benutzer-Gruppe Vollzugriff.
Erstelle ich aufm meinem privat PC ein neues Projekt und schaue mir die Sicherheit des Projekt-Ordner an, hat die Benutzer-Gruppe nur Lesen-Ausführen-Berechtigungen.
Jedoch stelle ich hier keine Einschränkungen fest, dieses neue Projekt werde ich morgen mal aufm Dienst-PC testen/untersuchen.
Ich werd den Gedanken nicht los, dass es am Berechtigungssystem von Windows liegt.

D
danieljena Themenstarter:in
38 Beiträge seit 2015
vor 3 Jahren

Guten Morgen,
normalerweise ist es doch auch so, dass im Ref.Fenster bei den Assemblies die Haken gesetzt sind, welche bereits referenziert sind. Bei funktionierenden Projekten stimmt dies auch. Nur bei denen wo die Referenz nicht "gefunden" wird, tauchen auch da keine Haken auf.

4.931 Beiträge seit 2008
vor 3 Jahren

Und wenn du da mal die Referenzen hinzufügst und danach mal die beiden Projektdateien vergleichst?

D
danieljena Themenstarter:in
38 Beiträge seit 2015
vor 3 Jahren

so in etwa steht es in beiden:

<Reference Include="System" />
<Reference Include="System.Data" />
<Reference Include="System.Xml" /
D
danieljena Themenstarter:in
38 Beiträge seit 2015
vor 3 Jahren

Kann jemand mit diesen beiden Gruppen in einer *.csproj-Datei etwas anfangen?
1.

  <ItemGroup>
    <BootstrapperPackage Include=".NETFramework,Version=v4.5.2">
      <Visible>False</Visible>
      <ProductName>Microsoft .NET Framework 4.5.2 %28x86 und x64%29</ProductName>
      <Install>true</Install>
    </BootstrapperPackage>
    <BootstrapperPackage Include="Microsoft.Net.Framework.3.5.SP1">
      <Visible>False</Visible>
      <ProductName>.NET Framework 3.5 SP1</ProductName>
      <Install>false</Install>
    </BootstrapperPackage>
  </ItemGroup>

  <Target Name="EnsureNuGetPackageBuildImports" BeforeTargets="PrepareForBuild">
    <PropertyGroup>
      <ErrorText>This project references NuGet package(s) that are missing on this computer. Use NuGet Package Restore to download them.  For more information, see http://go.microsoft.com/fwlink/?LinkID=322105. The missing file is {0}.</ErrorText>
    </PropertyGroup>
    <Error Condition="!Exists('..\packages\linq2db.MySql.2.9.6\build\linq2db.MySql.props')" Text="$([System.String]::Format('$(ErrorText)', '..\packages\linq2db.MySql.2.9.6\build\linq2db.MySql.props'))" />
  </Target>

Beide stehen untereinander in der Datei.
Ich kann hier leider nur Vermutungen anstellen.

D
danieljena Themenstarter:in
38 Beiträge seit 2015
vor 3 Jahren

Soooo, gestern gab es noch den Durchbruch, es geht wieder alles.
Was habe ich gemacht:
Die beiden geposteten Xml-Groups in der *.csproj kamen mir etwas komisch vor. Hab von der Datei nen Backup angelegt, die beiden Abschnitte gelöscht und ... siehe da es geht wieder.

Gleichzeitig bin ich nun auch gleich noch von packages.config auf PackageReference umgesprungen, aber das nur so am Rande erwähnt.