Kon bestand of assembly of een van zijn afhankelijkheden niet laden

Ik heb nog een van deze “Kan bestand of assembly of een van de afhankelijkheden niet laden” problemen.

Aanvullende informatie: kon niet laden
bestand of assembly
‘Microsoft.Practices.Unity,
Versie=1.2.0.0, Cultuur=neutraal,
PublicKeyToken=31bf3856ad364e35’ of
een van zijn afhankelijkheden. de gelegen
De manifestdefinitie van assembly doet dat wel
komen niet overeen met de montagereferentie.
(Uitzondering op HRESULT: 0x80131040)

Ik heb geen idee wat dit veroorzaakt of hoe ik het kan debuggen om de oorzaak te vinden.

Ik heb gezocht in mijn oplossingscatalogi .csproj-bestanden, en overal waar ik Unity heb:

Referentie
Include=”Microsoft.Practices.Unity,
Versie=2.0.414.0, Cultuur=neutraal,
PublicKeyToken=31bf3856ad364e35,
processorArchitecture=MSIL”

Kan nergens een referentie vinden die in strijd is met 1.2.0.0 in een van mijn projecten.

Enig idee hoe ik dit moet oplossen?

Ik zou ook graag tips ontvangen over het oplossen van problemen zoals deze in het algemeen.

Antwoord 1, autoriteit 100%

1. Controleer of je verwijst naar een assembly die op zijn beurt verwijst naar een oude versie van unity. Stel dat u bijvoorbeeld een assembly heeft met de naam ServiceLocator.dlldie een oude versie van Unity-assembly nodig heeft. Als u nu naar de ServiceLocatorverwijst, moet u deze voorzien van de oude versie van Eenheid, en dat maakt het probleem.

2. Misschien is de uitvoermap waar alle projecten hun assemblages bouwen, een oude versie van unity.

U kunt FusLogVw gebruiken om erachter te komen wie de oude assembly’s laadt, definieert u gewoon een pad voor het logboek en voert u uw oplossing uit, controleert u vervolgens (in FusLogvw) de eerste regel waar de Unity-assembly is geladen, dubbelklikt u erop en ziet u de aanroepende montage, en daar gaat u.

Antwoord 2, autoriteit 72%

IIS-beheer openen

Applicatiepools selecteren

selecteer vervolgens de pool die u gebruikt

ga naar geavanceerde instellingen (aan de rechterkant)

Verander de vlag van Enable 32-bit application false in true.

Antwoord 3, autoriteit 68%

Voor mij werkte geen van de andere oplossingen (inclusief de clean/rebuild-strategie). Ik heb een andere tijdelijke oplossing gevonden, namelijk het sluiten en opnieuw openen van Visual Studio.

Ik denk dat dit Visual Studio dwingt om de oplossing en alle projecten opnieuw te laden, waarbij de afhankelijkheden in het proces opnieuw worden gecontroleerd.

Antwoord 4, autoriteit 45%

Probeer de Debug- en Release-mappen in uw oplossing op te schonen. Verwijder en voeg vervolgens weer eenheid toe.

Antwoord 5, autoriteit 24%

Bij 99% wordt het probleem Kon bestand of assembly niet geladen of een van de afhankelijkhedenveroorzaakt door afhankelijkheden! Ik raad je aan deze stappen te volgen:

1. Download Dependency Walkervan http://www.dependencywalker.com/

2. Start Dependency Walkeren open de dll (in mijn geval NativeInterfaces.dll)

3. U kunt een of meer dll’s zien met de fout in het rood Fout bij openen van bestand…

4. Dit betekent dat deze DLL in uw systeem ontbreekt; In mijn geval is de DLL-naam MSVCR71.DLL

5. U kunt Missings DLL downloaden van Google en Kopiëren op het juiste pad (in mijn geval c:\windows\system32)

6. Op dit punt moet u de nieuwe DLL registreren in de GAC (Global Assembly Cache): Open een DOS-terminal en schrijf:

   cd \Windows\System32
    regsvr32 /i msvcr71.dll
   

7. Start uw aanvraag opnieuw

Antwoord 6, Autoriteit 19%

Ondanks de oorspronkelijke vraag die vijf jaar geleden wordt geplaatst, blijft het probleem nog steeds en is nogal irritant.

De algemene oplossing is een grondige analyse van alle verwezenlijke assemblies om te begrijpen wat er mis gaat. Om deze taak gemakkelijker te maken heb ik een hulpmiddel gemaakt (een visuele studio-extensie) waarmee een .net-assemblage (een .dllof .exeBestand) een grafiek van is alle verwezenlijkingen die worden verwezen tijdens de hoogte brengen van conflicterende of ontbrekende referenties.

De tool is verkrijgbaar in Visual Studio Gallery: HTPS: // Marketplace .visualstudio.com / vsgallery / 051172F3-4B30-4BBC-8DA6-D55F70402734

Voorbeeld van uitvoer:

Antwoord 7, Autoriteit 13%

Microsoft Enterprise Library (waarnaar wordt verwezen door .nettariaten) was ons probleem, dat op zijn beurt een oudere versie van eenheid was verwijzen. Om het probleem op te lossen, gebruikten we de volgende bindende omleiding in het web.config:

<configuration>
    <runtime>
        <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
            <dependentAssembly>
                <assemblyIdentity name="Microsoft.Practices.Unity" publicKeyToken="31bf3856ad364e35" culture="neutral" />
                <bindingRedirect oldVersion="1.0.0.0-2.0.414.0" newVersion="2.1.505.0" />
            </dependentAssembly>
            <dependentAssembly>
                <assemblyIdentity name="Microsoft.Practices.Unity.Configuration" publicKeyToken="31bf3856ad364e35" culture="neutral" />
                <bindingRedirect oldVersion="1.0.0.0-2.0.414.0" newVersion="2.1.505.0" />
            </dependentAssembly>
        </assemblyBinding>
    </runtime>
</configuration>

Als alternatief kunt u de Enterprise Library gewoon updaten naar de nieuwste versie.

Antwoord 8, autoriteit 13%

Het volgende werkte voor mij.

• Tijdelijke bestanden verwijderen C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET-bestanden
• VSTS sluiten en weer openen
• Dezelfde DLL’s verwijderen en toevoegen (Opmerking: u voegt dezelfde overeenkomende versies toe)

Antwoord 9, autoriteit 12%

Controleer het bestand Web.config/App.config in uw project. Kijk of de versienummers correct zijn.

<bindingRedirect oldVersion="X.X.X.X-X.X.X.X" newVersion="X.X.X.X" />

Dit werkte voor mij.

Antwoord 10, autoriteit 10%

Klik in oplossingsverkenner met de rechtermuisknop op project (niet oplossing), kies in het tabblad Bouwen Platformdoel: “Elke CPU”.

Antwoord 11, autoriteit 9%

Juntos Antwoord is correct maar u moet ook overwegen:

Voor de Unity V2.1.505.2 Verschillende AssemblyVersion en AssemblyFileversion Attributen zijn opgegeven:

AssemblyFileVersion wordt gebruikt door de Nuget maar CLR geeft er niet om!
CLR gaat alleen Assemblyversion !

Dus uw omleidingen moeten worden toegepast op een versie die is opgegeven in AssemblyVersion Attribuut. Dus 2.1.505.0 moet worden gebruikt

<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
 <assemblyIdentity name="Microsoft.Practices.Unity" publicKeyToken="31bf3856ad364e35" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-2.1.505.0" newVersion="2.1.505.0" />
</dependentAssembly>
</assemblyBinding>

Zie ook:
Wat zijn verschillen tussen assemblagversie, assemblyfileversie en assemblyinformationalversion?

Antwoord 12, Autoriteit 5%

Ik heb ook deze vreselijke fout en vond hiervoor een oplossing …

1. Klik met de rechtermuisknop op de naam van de oplossing
2. Klik op Clean Solution
3. Start visuele studio
4. Goto-projecteigenschappen & GT; & GT; Bouwen
5. Wijzig Configuratie Naar Release
6. Begin Debugging (F5)

1), 2)

4) , 5)

Ik hoop dat dit jou ook zal helpen.

Antwoord 13, autoriteit 4%

• Ga naar :Oplossing-> Pakket
• Klik op het tabblad Geavanceerd(vind onder de pagina)
• Voeg uw dlltoe aan extra assembly’s (op deze manier kunnen we externe dll’s toevoegen in sharepoint).

Antwoord 14, autoriteit 4%

Ik weet niet zeker of dit kan helpen.

Controleer of de assembly-naam en de standaardnaamruimte in de eigenschappen in uw assembly’s overeenkomen. Dit loste mijn probleem op dat dezelfde fout opleverde.

Antwoord 15, autoriteit 4%

In mijn geval in de bin-map was een niet-referentie-dll genaamd Unity.MVC3 , ik heb geprobeerd een verwijzing naar dit in Visual Studio te zoeken zonder succes, dus mijn oplossing was zo eenvoudig als het verwijderen van die dll uit de bin-map.

Antwoord 16, autoriteit 4%

Ik had hetzelfde probleem, ik heb het opgelost via de onderstaande instructies:

1. open het menu Extra en selecteer de optie
2. ga in het venster Opties naar Projecten en Oplossingen/Webprojecten
3. vink aan use the 64bit version of IIS ...

Antwoord 17, autoriteit 3%

Bedankt Riddhi M.
Het volgen werkte voor mij.

Tijdelijke bestanden verwijderen C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET-bestanden
Sluit VSTS en open opnieuw
Verwijder en voeg dezelfde DLL’s toe (Opmerking: u voegt dezelfde overeenkomende versies toe)

Antwoord 18, autoriteit 2%

Je zegt dat je veel projecten in je oplossing hebt… nou, begin met een aan de bovenkant van de bouwvolgorde. Laat die bouwen en als je er eenmaal achter bent, kun je dezelfde oplossing op de rest toepassen.

Eerlijk gezegd moet je waarschijnlijk gewoon je referentie vernieuwen. Het klinkt alsof je ofwel je versie hebt bijgewerkt en de referenties niet hebt bijgewerkt, of dat het een relatief padprobleem is als je je oplossing onder bronbeheer houdt. Verifieer gewoon je aannames en voeg de referentie opnieuw toe.

Antwoord 19, autoriteit 2%

Het volgende werkte voor mij.

• Tijdelijke bestanden verwijderen C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET-bestanden
  • klik vervolgens met de rechtermuisknop op Tijdelijke Asp.net-bestanden>properties>beveiliging
    en geef totale controle toegang tot IIS en alle gebruikers die mijn project uitvoeren

Antwoord 20, autoriteit 2%

Dit probleem deed zich voor waarbij een van mijn afhankelijke bibliotheken een DLL aan het compileren was met “Elke CPU” terwijl de bovenliggende bibliotheek een compilatie van “x64” verwachtte.

Antwoord 21, autoriteit 2%

U moet uw appname.dll-bestand uit uw uitvoermap verwijderen.
Opschonen van mappen voor foutopsporing en vrijgeven.
Herbouw en kopieer naar de uitvoermap geregenereerd dll-bestand.

Antwoord 22, autoriteit 2%

Ik ‘Instellen als opstartproject’de verwijderde/niet gevonden bibliotheek/het project.

Vervolgens geïmplementeerd.

Het werkte!

Ik denk dat het de .dll niet kon vinden omdat het eerst niet in de assembly zat.

Antwoord 23, autoriteit 2%

Als u deze foutmelding krijgt door een toepassing op uw Windows XP te openen, betekent dit dat u eerst die app hebt geïnstalleerd omdat deze niet werkt zonder net framework 4 en service pack 3 . je hebt beide geïnstalleerd en opnieuw krijg je deze foutmelding, dus je moet die app opnieuw installeren, maar eerst verwijderen via toevoegen en verwijderen

Als dit niet werkt, misbruik me dan niet. ik ben ook een junior

Antwoord 24, autoriteit 2%

Een andere mogelijke oorzaak: zorg ervoor dat je niet per ongeluk beide projecten dezelfde assembly-naam hebt gegeven in de projecteigenschappen.

Antwoord 25, autoriteit 2%

Mijn oplossing voor .NET 4.0, met behulp van Enterprise Library 5, was om een verwijzing toe te voegen naar:

Microsoft.Practices.Unity.Interception.dll

Antwoord 26, autoriteit 2%

Pas op voor tegenstrijdige verwijzingen. Zelfs na het opschonen en opnieuw opbouwen, zullen conflicterende verwijzingen nog steeds een probleem veroorzaken. Mijn probleem was tussen AForge en Accord. Ik heb beide verwijzingen verwijderd en de verwijzingen opnieuw toegevoegd door de specifieke verwijzing opnieuw te kiezen (in het bijzonder voor mijn geval, alleen Accord).

Antwoord 27, autoriteit 2%

In mijn geval werkte geen van de voorgestelde antwoorden.

Dit is wat voor mij werkte:

1. Verwijder de referentie
2. De naam van de DLL wijzigen
3. Importeer de referentie opnieuw

De tweede stap was blijkbaar belangrijk omdat het niet werkte zonder.

Antwoord 28, autoriteit 2%

Probeer te controleren of de eigenschap “Kopieer naar lokaal” voor de verwijzing is ingesteld op waar en de specifieke versie is ingesteld op waar. Dit is relevant voor toepassingen in Visual Studio.

Antwoord 29, autoriteit 2%

Ik had dit vandaag, en in mijn geval was het probleem heel vreemd:

 <dependentAssembly>
    <assemblyIdentity name="Microsoft.Owin.Host.SystemWeb" publicKeyToken="31bf3856ad364e35" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-3.1.0" newVersion="3.1.0.0" />
  </dependentAssembly>0.

Noteer de zwerfkarakters aan het einde van de XML – op een of andere manier waren die zijn verplaatst van het versienummer tot het einde van dit blok XML!

 <dependentAssembly>
    <assemblyIdentity name="Microsoft.Owin.Host.SystemWeb" publicKeyToken="31bf3856ad364e35" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-3.1.0.0" newVersion="3.1.0.0" />
  </dependentAssembly>

veranderd in de bovenstaande en voila! Alles werkte weer.

Antwoord 30, Autoriteit 2%

Voor mij opnieuw opbouwen van het Unity-spel zonder Unity C # Projects CheckMark werkte.