6

My Windows Service è un'applicazione .NET. Il servizio ha una dipendenza dal mio accesso ai dati che utilizza EF 4.3 Code First. Ho ricevuto il seguente errore quando il mio servizio è in esecuzione e tenta di accedere ai dati.Decimale come chiave primaria funziona in Dev (Win7/64bit) ma non in produzione (Win2008R2/64bit) Common Language Runtime ha rilevato un programma non valido

errore si è presentato in FullPurgeAndReplace(): System.InvalidProgramException: Common Language Runtime rilevamento di un programma valido . a System.Data.Entity.DynamicProxies.MOMInventoryItem_3ED5D5176D2C03867C62DD8E4381A882350CFD9CD931F3CD551623A6EF5C4D8E.set_Id (decimale ) a lambda_method (chiusura, Shaper) a System.Data.Common.Internal.Materialization.Shaper.HandleEntityAppendOnly [TEntity] (FUNZ 2 constructEntityDelegate, EntityKey entityKey, EntitySet entitySet)
at lambda_method(Closure , Shaper) at System.Data.Common.Internal.Materialization.Coordinator
1.ReadNextElement (Shaper shaper) a System.Data.Common.Internal.Materialization.Shaper 1.SimpleEnumerator.MoveNext() at System.Collections.Generic.List 1..ctor (IEnumerable 1 collection)
at System.Linq.Enumerable.ToList[TSource](IEnumerable
1 fonte) ... più rimosso

sulla stessa macchina ho un'applicazione web che dipende sullo stesso progetto di accesso ai dati e viene eseguito senza problemi. Per quel sito Web in IIS Ho abilitato le applicazioni a 32 bit per il rispettivo pool di applicazioni.

Ho cercato il problema e ho scoperto che potrebbe essere correlato al fatto che l'entità nell'errore (MOMInventoryItem) ha una chiave primaria decimale. Non ho scelta da quando mi sto integrando con un sistema esistente. Tuttavia, quello era presumibilmente un known issue with EF 4.0 da oltre un anno fa e mi aspetterei che venga risolto a questo punto.

Ecco il codice dal mio Entità:

[Table("STOCK")] 
public class MOMInventoryItem 
{ 
    [Key, DatabaseGenerated(DatabaseGeneratedOption.None), Column("STOCK_ID")] 
    public virtual decimal Id { get; set; } 

Ancora una volta, questo funziona bene tramite un app MVC ospitati in IIS, ma non riesce come servizio di Windows, sia sullo stesso server Windows 2008 R2. Funziona anche sulla mia macchina DEV (Win7/VS11). Qual è il mio problema e come potrei risolverlo definitivamente o aggirarlo?

Come sempre l'aiuto è molto apprezzato e ricambiato quando possibile.

+2

Anch'io vorrei eseguire un sistema operativo a 65 bit. Dove posso trovare questa bestia? Best Buy supporta solo Windows a 64 bit. UHG. Ho bisogno di quel pezzo in più! –

+0

LOL, sì ho corretto il titolo, grazie Dan-o! – kingdango

+0

Aw man. Solo un errore di battitura! Pensavo avessi una specie di società segreta con gli illuminati digitali e hai venduto il tuo primogenito per un po 'di più ... o qualcosa del genere. :) –

risposta

2

Provare a impostare il progetto di avvio su target 32 ​​bit, che dovrebbe impedire l'apparente problema a 64 bit. E spiega perché funziona perfettamente con MVC.

+1

Questo ha risolto il problema. Ho anche pubblicato un work-around che ha funzionato per me prima di questa risposta migliore. Pagherei $ 5 :) perché qualcuno mi dica in modo definitivo perché funziona correttamente su Win 7 64-bit e sullo stesso server Win 2008 RC2 sotto IIS ma NON come servizio Windows. – kingdango

0

NOTA: quanto segue è una soluzione che ha funzionato per me PRIMA che avessi una risposta migliore. La risposta migliore era compilare il progetto del servizio Windows per scegliere come destinazione x86 invece di qualsiasi CPU. Questo ancora non risponde perché Windows Server 2008 R2 è diverso da Win 7 ma questa è una domanda diversa per un giorno diverso.

-

ho trovato una soluzione al mio problema. Ho cambiato la mia chiave in un int (poiché è proprio quello che viene archiviato nel DB comunque, anche se tecnicamente una colonna decimale) e fornisco esplicitamente TypeName = "Decimal" nell'attributo Column.

[Table("STOCK")] 
public class MOMInventoryItem 
{ 
    [Key, DatabaseGenerated(DatabaseGeneratedOption.Identity), Column("STOCK_ID", TypeName = "Decimal")] 
    public virtual int Id { get; set; } 

Nel mio caso non scrivo mai su questo tavolo, anche se potrei averne bisogno in futuro. Non sono sicuro al 100% di come questo avrà un impatto sulle righe di scrittura, ma poiché la colonna è contrassegnata come DatabaseGenerated suppongo che non sarà un problema.

Io credo che sia possibile che se io x86 invece di qualsiasi CPU allora potrebbe risolverlo e cercherò che la prossima, come suggerito dal @leppie

Ciò nonostante, sono ancora curioso di sapere perché questo sarebbe presenta questo tipo di errore: Common Language Runtime ha rilevato un programma non valido.

+0

Potrebbe essere preferibile usare 'long' invece di' int', dato che un decimale 'deciso era una buona scelta per una chiave pubblica; p – leppie