Unable to find assembly Microsoft.IdentityModel

Dávid Zoli barátommal épp egy HTML 5-ös, MVC-s, Azure-os, Facebook és Live loginos projekten dolgozunk, ahol a bejelentkezést a Windows Azure AppFabric Access Control Service (a marketingesek úgy látszik karakterszám alapján kapják a fizetést) segítségével oldottuk meg. Mivel ez lényegében Windows Identity Foundation az alkalmazás szempontjából, ezért a WIF telepítését megúsztuk annyival, hogy a Microsoft.IdentityModel.dll-t szépen bemásoltuk a website bin mappájába. Éljen a bin deployment!

Ez szépen is működött, ám amint elkezdtük használni a blog storage-ot, az alábbi hibaüzenet fogadott:

Unable to find assembly ‘Microsoft.IdentityModel, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35’.

Hasonló néha előfordul, de ez a hibaüzenet két ok miatt furcsa:

  1. Semmi nem változott, továbbra is ott csücsül pont ez a DLL a bin-ben.
  2. A hibaüzenet nem egy authentikációval vagy authorizációval kapcsolatos kódrészletnél jött, hanem egy Azure blobos RoleEnvironment.IsAvailable hívásnál.

A Windows Azure hibaelhárítási tippek között szerepel egy idevonatkozó is, miszerint telepítsem újra a WIF-et. Csakhogy én soha nem telepítettem és nem is szeretném!

Végül a megoldás az lett, hogy gacutil /i-vel bedobtuk a DLL-t a GAC-ba, ami a fejlesztői gépen megoldotta a hibát, de az éles környezetbe történő telepítésnél sajnos le kell mondanunk bin deploymentről Szomorú arc

 

7 thoughts on “Unable to find assembly Microsoft.IdentityModel

  1. ersekattila

    A WIF-től nem kell félni, a 4.5-ös verzióban már a framework része, így addig együtt kell élni vele. (És érdemes együtt élni vele).
    Az, hogy minek nem elég a probing path viszont érdemes lenne debug-olni, engem mindenesetre érdekelne az eredmény!

  2. athalay

    Arra esetleg van valakinek best practice-e, manualja, hogyan erdemes megoldani egy AccessControl services-es) FB, Live, Google, akarmi) logint egy olyan oldalra, ahol mar van forms authentikacio?

    Szoval hogyan tud ez a ketto megelni egymas mellett. Kulonos tekintettel arra is, hogy esetleg meglevo userekhez kossunk FB/Google/Live accountokat, hogy eddigi mar regisztralt forms-authos userek is belephessenek a sajat kulso provideres loginjukkal.

    Az vilagos, hogy a DB-ben el kell majd tarolni az adott providernek vmilyen userre vonatkozo azonositojat, csak hogyan erdemes/tanacsos ezt csinalni, erre nem igazan talaltam semmilyen doksit, leirast.

  3. athalay

    Igen, ezt nem ertem en sem, hogy mindenki arrol cikkez, hogy mennyire jo az ACS, ilyen-olyan konnyu a kulso nagy providerek hasznalata, de kerem mi van a migracioval? Mi van ha valaki letezo, mukodo site-hoz akarja _migralni_ a fentieket, ahol termeszetesen szoba sem jon a komplett csere (forms auth eldobasa)?

    Miert van az, hogy mindig mindent csak “New project”-tel kezdenek, es a tobbinel meg mindenki talalja fel a maga kereket?!😦

    Bocs a kifakadasert :]

    1. Balássy György Szerző

      Szerintem teljesen igazad van. Épp most hallottam arról, hogy az MS komolyan ráfekszik arra, hogy a jövőben ne készítsen demoware technológiákat, hanem csak olyanokat, amik a valós igényeknek is meg tudnak felelni, és azt életszagúbb példákon keresztül mutassák be.

Vélemény, hozzászólás?

Adatok megadása vagy bejelentkezés valamelyik ikonnal:

WordPress.com Logo

Hozzászólhat a WordPress.com felhasználói fiók használatával. Kilépés / Módosítás )

Twitter kép

Hozzászólhat a Twitter felhasználói fiók használatával. Kilépés / Módosítás )

Facebook kép

Hozzászólhat a Facebook felhasználói fiók használatával. Kilépés / Módosítás )

Google+ kép

Hozzászólhat a Google+ felhasználói fiók használatával. Kilépés / Módosítás )

Kapcsolódás: %s