Ik werk aan een WPF, C# 3.0-project en ik krijg deze foutmelding:
Error 1 Metadata file
'WORK=- \Tools\VersionManagementSystem\BusinessLogicLayer\bin\Debug
\BusinessLogicLayer.dll' could not be found C:\-=WORK=- \Tools
\VersionManagementSystem\VersionManagementSystem\CSC VersionManagementSystem
Zo verwijs ik naar mijn gebruikerscontroles:
xmlns:vms="clr-namespace:VersionManagementSystem"
<vms:SignOffProjectListing Margin="5"/>
Het gebeurt na elke mislukte build. De enige manier waarop ik de oplossing kan compileren, is door al mijn gebruikersbesturingselementen uit commentaar te geven en het project opnieuw te bouwen, en dan verwijder ik de gebruikersbesturingselementen en alles is in orde.
Ik heb de configuraties van buildorders en afhankelijkheden gecontroleerd.
Zoals je kunt zien, lijkt het erop dat het absolute pad van het DLL-bestand is afgekapt… Ik heb gelezen dat er een fout is in de lengte. Is dit een mogelijk probleem?
Het is erg vervelend en als je commentaar moet geven, bouwen en commentaar geven, wordt het bouwen extreem vermoeiend.
Antwoord 1, autoriteit 100%
Ik had net hetzelfde probleem. Visual Studio bouwt niet het project waarnaar wordt verwezen.
Schriftelijke instructies:
- Klik met de rechtermuisknop op de oplossing en klik op Eigenschappen.
- Klik op Configuratie aan de linkerkant.
- Zorg ervoor dat het selectievakje onder ‘Bouw’ voor het project dat het niet kan vinden is aangevinkt. Als het al aangevinkt is, verwijder dan het vinkje, klik op toepassen en vink de vakjes opnieuw aan.
- (Optioneel) Je moest het doen voor zowel de Release- als Debug-modi in de oplossingseigenschappen.
Instructies voor schermopname:
- Ze zeggen dat een foto meer zegt dan duizend woorden. Klik op de GIF om in te zoomen, en hopelijk is het gemakkelijk te volgen:
Antwoord 2, autoriteit 24%
Dit kan nog steeds gebeuren in nieuwere versies van Visual Studio (ik heb het net laten gebeuren in Visual Studio 2013):
Een ander ding dat u kunt proberen is om Visual Studio te sluiten en het bestand .suo naast het bestand .sln te verwijderen. (Het wordt opnieuw gegenereerd de volgende keer dat u Save all (of Visual Studio afsluit)).
Ik heb dit probleem gehad toen ik nieuwe projecten aan de oplossing op een andere machine toevoegde en vervolgens de revisies binnenhaalde, maar het bestand .suo kan ook in andere gevallen beschadigd raken en leiden tot zeer vreemd Visual Studio-gedrag, dus het verwijderen ervan is een van de dingen die ik altijd probeer.
Houd er rekening mee dat als u het bestand .suo verwijdert, de opstartprojecten van de oplossing worden gereset.
Meer over het .suo-bestand is hier.
Antwoord 3, autoriteit 20%
Het voorgestelde antwoord werkte niet voor mij. De fout is een lokmiddel voor een ander probleem.
Ik kwam erachter dat ik me op een iets andere versie van .NET richtte en dit werd door de compiler als een waarschuwing gemarkeerd, maar het bouwen mislukte.
Dit had moeten worden gemarkeerd als een fout en niet als een waarschuwing.
Antwoord 4, autoriteit 11%
Nou, mijn antwoord is niet alleen de samenvatting van alle oplossingen, maar het biedt meer dan dat.
Sectie (1):
Algemene oplossingen:
Ik had vier van dit soort fouten ( metagegevensbestand kon niet worden gevonden ) en één fout met de melding ‘Bronbestand kon niet worden geopend ( Niet-gespecificeerde fout )’.
Ik heb geprobeerd de fout ‘metadatabestand kan niet gevonden’ te verwijderen. Daarom heb ik veel berichten, blogs, enz. gelezen en ontdekte dat deze oplossingen effectief kunnen zijn (hier vat ik ze samen):
-
Start Visual Studio opnieuw en probeer opnieuw te bouwen.
-
Ga naar ‘Solution Explorer’. Klik met de rechtermuisknop op Oplossing. Ga naar Eigenschappen. Ga naar ‘Configuratiebeheer’. Controleer of de selectievakjes onder ‘Build’ zijn aangevinkt of niet. Als een of meer van deze niet zijn aangevinkt, vink ze dan aan en probeer opnieuw te bouwen.
-
Als de bovenstaande oplossing(en) niet werken, volg dan de volgorde die is vermeld in stap 2 hierboven, en zelfs als alle selectievakjes zijn aangevinkt, schakelt u ze uit, vinkt u opnieuw aan en probeert u opnieuw te bouwen.
-
Order- en projectafhankelijkheden opbouwen:
Ga naar ‘Solution Explorer’. Klik met de rechtermuisknop op Oplossing. Ga naar ‘Projectafhankelijkheden…’. Je ziet twee tabbladen: ‘Afhankelijkheden’ en ‘Order opbouwen’. Deze buildvolgorde is degene waarin de oplossing wordt gebouwd. Controleer de projectafhankelijkheden en de bouwvolgorde om te verifiëren of een project (zeg ‘project1’) dat afhankelijk is van een ander (zeg ‘project2’) probeert te bouwen voor dat ene (project2). Dit kan de oorzaak van de fout zijn.
-
Controleer het pad van de ontbrekende .dll:
Controleer het pad van de ontbrekende .dll. Als het pad spatie of een ander ongeldig padteken bevat, verwijder het dan en probeer opnieuw te bouwen.
Als dit de oorzaak is, pas dan de bouwvolgorde aan.
Sectie (2):
Mijn specifieke geval:
Ik heb alle bovenstaande stappen geprobeerd met verschillende permutaties en combinaties door Visual Studio een paar keer opnieuw op te starten. Maar het heeft me niet geholpen.
Dus heb ik besloten om de andere fout die ik tegenkwam (‘Bronbestand kon niet worden geopend ( Niet-gespecificeerde fout )’) te verwijderen.
Ik kwam een blogpost tegen: TFS-fout Bronbestand kon niet worden geopend ( Niet-gespecificeerde fout )
Ik heb de stappen geprobeerd die in die blogpost worden genoemd, en ik heb de fout ‘Bronbestand kon niet worden geopend ( Unspecified error )’ verwijderd en verrassend genoeg heb ik andere fouten verwijderd ( metadata-bestand kan niet worden gevonden ) ook.
Sectie (3):
Moraal van het verhaal:
Probeer alle oplossingen zoals vermeld in paragraaf (1) hierboven (en alle andere oplossingen) om van de fout af te komen. Als niets werkt, zoals in de blog vermeld in paragraaf (2) hierboven, verwijder de vermeldingen van alle bronbestanden die niet langer aanwezig zijn in het bronbeheer en het bestandssysteem uit uw .csproj-bestand.
Antwoord 5, autoriteit 4%
In mijn geval werd het veroorzaakt door een niet-overeenkomende versie van .NET Framework.
Eén project was 3.5 en het andere refererende project 4.6.1.
Antwoord 6, autoriteit 3%
Afsluiten en heropenen van Visual Studio 2013 werkte voor mij!
Antwoord 7, autoriteit 2%
Nou, niets in de vorige antwoorden werkte voor mij, dus het zette me aan het denken over waarom ik klik en hoop wanneer we als ontwikkelaars echt moeten proberen te begrijpen wat hier aan de hand is.
Het leek me duidelijk dat deze onjuiste metagegevensbestandsreferentie ergens moet worden bewaard.
Een snelle zoektocht in het .csproj-bestand leverde de schuldige regels op. Ik had een sectie genaamd <itemGroup> die aan het oude onjuiste bestandspad leek te hangen.
<ItemGroup>
<ProjectReference Include="..\..\..\MySiteOld\MySite.Entities\MySite.Entities.csproj">
<Project>{5b0a347e-cd9a-4746-a3b6-99d6d010a6c2}</Project>
<Name>Beeyp.Entities</Name>
</ProjectReference>
...
Dus eigenlijk een simpele oplossing:
- Maak een back-up van uw .csproj-bestand.
- Zoek de verkeerde paden in het .csproj-bestand en wijzig de naam op de juiste manier.
Gelieve zorg ervoor dat u een back-up maakt van uw oude .csproj voordat u gaat spelen.
Antwoord 8, autoriteit 2%
Visual Studio 2019 dit werkte voor mij:
- Visual Studio sluiten
- Verwijder de verborgen map
.vs - Open Visual Studio opnieuw en herbouw de oplossing.
Antwoord 9, autoriteit 2%
Ik heb dit probleem ook ontmoet. Eerst moet u uw DLL-project handmatig bouwen door met de rechtermuisknop op Build te klikken. Dan zal het werken.
Antwoord 10, autoriteit 2%
In mijn geval heb ik mijn geïnstalleerde map op een verkeerde manier.
Als uw oplossingspad zoiets is als “Mijn Project%2c Zeer populaire%2c Unit Testing%2c Software en Hardware.zip”, kan het het metagegevensbestand niet oplossen, misschien moeten we enkele ongeldige woorden zoals %2c voorkomen.
p>
Het hernoemen van het pad naar de normale naam loste mijn probleem op.
Antwoord 11
Ik kreeg dezelfde foutmelding “Metadatabestand ‘.dll’ kan niet worden gevonden”, en ik heb verschillende dingen geprobeerd die hierboven zijn beschreven, maar de reden voor de fout was dat ik verwees naar een DLL-bestand van derden dat een . NET-versie hoger dan mijn projectdoel .NET-versie. Dus de oplossing was om het doelkader van mijn project te veranderen.
Antwoord 12
Voor mij probeerde het een DLL te vinden in een pad dat vroeger het Project bevatte, maar we hadden het naar een nieuwe map verplaatst. De oplossing had het juiste pad naar het project, maar Visual Studio bleef op de een of andere manier op de oude locatie zoeken.
Oplossing: hernoem elk probleemproject – voeg gewoon een teken toe of wat dan ook – en hernoem het dan terug naar de oorspronkelijke naam.
Dit moet een of andere globale cache in Visual Studio resetten, omdat dit zowel dit probleem als verschillende soortgelijke problemen oplost, terwijl dingen als Clean dat niet doen.
Antwoord 13
Ik heb een nieuw project aan mijn oplossing toegevoegd en kreeg dit.
De reden? Het project dat ik binnenbracht was gericht op een ander .NET-framework (4.6 en mijn andere twee waren 4.5.2).
Antwoord 14
Het lijkt erop dat dergelijke fouten te maken hebben met het feit dat Visual Studio geen correcte informatie geeft over een fout. De ontwikkelaar begrijpt niet eens de reden voor de mislukte build. Het kan een syntaxisfout zijn of iets anders. Om dergelijke problemen op te lossen, moet u gewoonlijk de oorzaak van het probleem vinden (kijk bijvoorbeeld naar het bouwlogboek).
In mijn geval was het probleem in feite dat het venster Error List geen fouten liet zien. Maar er waren echt syntaxisfouten; Ik vond deze fouten in het venster Output en nadat ze waren verholpen, was het probleem opgelost.
Antwoord 15
Voor mij gebeurde het toen ik een nieuw project aan een oplossing toevoegde.
Visual Studio selecteert automatisch .NET Framework 4.5.
Ik ben overgestapt naar versie .NET 4.5.2 zoals de andere bibliotheken, en het werkte.
Antwoord 16
Voor mij werkten de volgende stappen:
- Zoek het project dat niet aan het bouwen is
- Verwijder/voeg verwijzingen toe naar projecten binnen de oplossing.
Antwoord 17
Ik trok mijn haren ook uit met dit probleem, maar nadat ik de vorige antwoorden had geprobeerd, was het enige dat voor mij werkte, om elk project in mijn oplossing 1 voor 1 te openen en ze afzonderlijk te bouwen.
Toen sloot ik Visual Studio 2013, heropende mijn oplossing en het compileerde prima.
Het is vreemd, want als ik op elk project in mijn Solution Explorer klikte en ze op die manier probeerde te bouwen, mislukten ze allemaal. Ik moest ze alleen openen in hun eigen oplossingen.
Antwoord 18
In mijn geval was het probleem dat ik handmatig een niet-compilatiebestand had verwijderd dat was gemarkeerd als “ontbrekend”. Nadat ik de verwijzing naar het nu ontbrekende bestand had verwijderd en opnieuw had gecompileerd, was alles in orde.
Antwoord 19
Als je een spatie in de naam van je oplossing hebt, zal dit ook het probleem veroorzaken. Als u de spatie uit uw oplossingsnaam verwijdert, zodat het pad geen %20 bevat, wordt dit opgelost.
Antwoord 20
Om hier een paar jaar later op terug te komen, dit probleem heeft meer dan waarschijnlijk te maken met de maximale padlimiet van Windows:
Bestanden, paden een naam geven , en naamruimten, Maximale padlengtebeperking
Antwoord 21
Mijn exemplaar van het probleem werd veroorzaakt door een algemeen project met een dubbele klassenaam (onder een andere bestandsnaam). Het is vreemd dat Visual Studio dat niet kon detecteren en in plaats daarvan het bouwproces opblies.
Antwoord 22
Ik kreeg dit probleem in Visual Studio 2012 in een oplossing met veel projecten. Het handmatig opnieuw opbouwen van elk project in de oplossing in dezelfde volgorde als de Project Build Order (rechtsklik en opnieuw opbouwen in Solution Explorer) loste het voor mij op.
Uiteindelijk kreeg ik er een die me een compileerfout gaf. Ik heb de fout verholpen en daarna zou de oplossing correct worden opgebouwd.
Antwoord 23
In mijn geval werd het probleem veroorzaakt door een eenvoudige bouwfout,
fout CS0067: De gebeurtenis ‘XYZ’ wordt nooit gebruikt
die, om welke reden dan ook, niet verscheen in het foutvenster.
Daarom leek het Visual Studio-buildsysteem de fout te missen en probeerde het afhankelijke projecten te bouwen, wat op zijn beurt mislukte met het vervelende metadatabericht.
De aanbeveling is -hoe stom het ook klinkt-:
Kijk eerst naar uw Uitvoervenster!
Het kostte me een half uur voordat ik op dit idee kwam…
Antwoord 24
Ook ik had dezelfde fout. Het verbergt zich zoals in het onderstaande pad.
Het pad waarnaar ik verwees voor het DLL-bestand is als “D:\Assemblies Folder\Assembly1.dll”.
Maar het oorspronkelijke pad waarnaar de assembly verwijst was “D:\Assemblies%20Folder\Assembly1.dll”.
Vanwege deze variatie in padnaam kon de assembly niet worden opgehaald uit het oorspronkelijke pad en wordt daarom de fout ‘Metadata niet gevonden’ gegenereerd.
De oplossing zit in de Stack Overflow-vraag Hoe vervang ik alle spaties door %20 in C#?.
Antwoord 25
Ik had hetzelfde probleem gehad. In mijn geval had ik verwezen naar een klassenbibliotheekproject met een hogere .Net-versie dan mijn project en VS slaagden er niet in om het project te bouwen en deed dezelfde fout opkomen die jij hebt gepost.
Ik heb eenvoudig .Net-versie van mijn klassenbibliotheekproject (degene die de build had verbroken) identiek ingesteld aan de .Net-versie van het project waarnaar wordt verwezen en het probleem is opgelost.
Antwoord 26
Ik wijs alleen op het overduidelijk voor de hand liggende: als je “Toon uitvoervenster wanneer build start” niet hebt ingeschakeld, zorg er dan voor dat je merkt dat je build mislukt (kleine “build mislukt”-fout linksonder)!! !!
Antwoord 27
Ik kreeg deze fout toen ik probeerde een webtoepassing te publiceren. Bleek dat een van de eigenschappen van een klasse was ingepakt in
#if DEBUG
public int SomeProperty { get; set; }
#endif
maar het eigendomsgebruik was dat niet. De publicatie is gedaan in de Release-configuratie zonder het DEBUG-symbool, uiteraard.
Antwoord 28
Op basis van de foutmelding geloof ik niet dat het bestandspad wordt afgekapt. Het lijkt gewoon onjuist te zijn. Als ik het bericht goed lees, lijkt het te zoeken naar het DLL-bestand op …
WORK=-\Tools\VersionManagementSystem\BusinessLogicLayer\bin\Debug\BusinessLogicLayer.dll
Dit is geen geldig pad. Is het mogelijk dat je een macrodefinitie in het bouwproces hebt ingesteld op een ongeldige waarde?
Antwoord 29
Ik had dit probleem omdat .nuget\NuGet.exe niet in mijn repository was opgenomen. Hoewel ik DownloadNuGetExe in NuGet.targets heb ingeschakeld, meldde het een proxyfout bij het downloaden ervan. Hierdoor mislukte de rest van het project.
Antwoord 30
Deze fout kan worden weergegeven als u nep-assembly’s gebruikt. Het verwijderen van vervalsingen leidt tot een succesvolle opbouw van het project.