Passa ai contenuti principali

Log.Net: Conflitto Con CrystalReport per Visual Studio 2010

Situazione:
Web Application Asp.Net 4.0, Utilizzo delle librerie di Crystal Report per VS2010. Il progetto web utilizza Log.Net, scaricato dal sito ufficiale. Un problema simile si verifica con applicazioni Windows Form.

Problema:
Le due librerie vanno in conflitto sia in fase di compilazione (1550854 - "Could not load file or assembly 'log4net' or one of its dependencies" Error when building Visual Studio 2010 solution utilizing the Crystal Reports .NET Runtime), sia una volta installata sulla macchiana target (L'inizializzatore di tipo di 'CrystalDecisions.Shared.SharedUtils' ha generato un'eccezione.
Impossibile caricare il file o l'assembly 'log4net, Version=1.2.10.0, Culture=neutral, PublicKeyToken=692fbea5521e1304' o una delle relative dipendenze. La definizione di manifesto dell'assembly specificato non corrisponde al riferimento all'assembly.).

Soluzione Spiegata:
Il thread in cui ne parlano. A quanto ho capito l'ultima risposta è quella più significativa: CrystalReport usa internamente Log4Net, ricompilato con un public key token diverso dalla distribuzione ufficiale (Public key token is 692fbea5521e1304) e, non contenti, lo installano nella GAC. Ad ogni installazione di CrystalReport, sia nella macchina di sviluppo che in quella di produzione, viene reinserita in GAC questa libreria.

Soluzione Veloce:
Rimpiazzare e referenziare la dll di LogFor.Net nel progetto con una versione da scaricare dal sito di Sap CrystalReport (il public key token di questa dll corrisponde a quello registrato in GAC da crystal)
In questo modo il vostro programma userà la stessa libreria di CrystalReport.

Un'altra soluzione può essere deregistrare dalla GAC la dll inserita da crystal dal pc in sviluppo e da quello in produzione. Il problema però potrebbe ripresentarsi se un eventuale aggiornamento di CrystalReport decide di reinserire la stessa dll in GAC.

Nota:
Le versioni ufficiale di Log4Net hanno public key token (stackoverflow):

log4net 1.2.10.0 publickeytoken = 1b44e1d426115821
log4net 1.2.11.0 publickeytoken = 669e0ddf0bb1aa2a


per controllare il public KeyToken di una dll si può usare il comando (VS2010):

"%ProgramFiles%\Microsoft SDKs\Windows\v7.0A\bin\sn.exe" -T assemblyname

Commenti

Post popolari in questo blog

SqlServer di Aruba - Entity Framework 4.0 - Problema dello Schema

Lo schema in MsSql è un elemento intermedio fra il database e le tabelle, lo schema predefinito è dbo e compare nel nome tabella come [dbo].[NomeTabella] .  In fase di generazione di un modello .edmx Entity Framework permette di impostare lo schema tramite la proprietà "Database Schema Name" dell'edmx.  Questo valore però non sarà modificabile a Runtime perchè cablato nei metadati. Il servizio SqlServer di aruba purtroopo crea le tabelle in uno schema che ha lo stesso nome dell'utente (per esempio MSSql123).  Quindi un edmx generato in locale a partire da tabelle definite nello schema dbo non fuzionerà. Vi sono due possibili Soluzioni: In locale definisco le tabelle di sviluppo nello stesso schema in cui saranno sul Sql di Aruba. CREATE SCHEMA  MSSql123 GO CREATE TABLE [MSSql123].NomeTabella] ( ... ......); Impongo che i metadati non vengano inseriti nella dll, ed edito a mano i tre file xml di metadati sostituendo dbo con lo schema in uso su aruba o...

Dotnetnuke non migrerà ad asp .NET MVC

Il grande capo di dnn Shawn Walker ha messo in chiaro che non tenteranno un porting di dnn verso asp .Net MVC, dotnetnuke resterà per sempre su web forms. La scelta è tanto saggia quanto obbligata. Esiste però un modo per estendere DNN o integrarlo con un'applicazione MVC? sembra di si, il completo tutorial in 3 parti direttamnte dai blog ufficiali delgi sviluppatori Dnn: parte1 parte2 parte3 Per completezza qui il famoso post di ScottGu sulla volontà di microsoft di tenere in piedi con uguali risorse sia asp.Net MVC sia WebForms.