6

Mi servicio de Windows es una aplicación .NET. El servicio tiene una dependencia en mi acceso a datos que utiliza EF 4.3 Code First. Recibo el siguiente error cuando se ejecuta mi servicio e intento acceder a los datos.Decimal como clave principal funciona en Dev (Win7/64bit) pero no en producción (Win2008R2/64bit) Common Language Runtime detectó un programa no válido

error ocurrido en FullPurgeAndReplace(): System.InvalidProgramException: Common Language Runtime detecta un programa no válido . en System.Data.Entity.DynamicProxies.MOMInventoryItem_3ED5D5176D2C03867C62DD8E4381A882350CFD9CD931F3CD551623A6EF5C4D8E.set_Id (decimal ) en lambda_method (Cierre, Shaper) en System.Data.Common.Internal.Materialization.Shaper.HandleEntityAppendOnly [TEntity] (Func 2 constructEntityDelegate, EntityKey entityKey, EntitySet entitySet)
at lambda_method(Closure , Shaper) at System.Data.Common.Internal.Materialization.Coordinator
1.ReadNextElement (Shaper shaper) en 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 fuente) ... más alejado

en la misma máquina que tienen una aplicación web que depende en el mismo proyecto de acceso a datos y se ejecuta sin problemas. Para ese sitio web en IIS HAGO que se activen las aplicaciones de 32 bits para el grupo de aplicaciones respectivo.

Investigué el problema y encontré que PUEDE estar relacionado con el hecho de que la entidad en el error (MOMInventoryItem) tiene una clave primaria decimal. No tengo otra opción ya que me estoy integrando con un sistema existente. Sin embargo, se suponía que era known issue with EF 4.0 desde hace más de un año y esperaría que se resolviera por ahora.

Aquí hay un código de mi Entidad:

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

Una vez más, esto funciona bien a través de una aplicación MVC alojado en IIS pero falla como un servicio de Windows, tanto en el mismo servidor Windows 2008 R2. También funciona en mi máquina DEV (Win7/VS11). ¿Cuál es mi problema y cómo podría resolverlo permanentemente o solucionarlo?

Como siempre, la ayuda es muy apreciada y correspondida cuando es posible.

+2

Yo también quisiera ejecutar un sistema operativo de 65 bits. ¿Dónde puedo encontrar esta bestia? Best Buy solo tiene Windows de 64 bits. Uhg. ¡NECESITO ese poco más! –

+0

LOL, sí, he corregido el título, gracias Dan-o! – kingdango

+0

Aw hombre. ¡Solo un error tipográfico! Pensé que tenías algún tipo de sociedad secreta con los illuminati digitales y vendiste a tu primogénito por un poco más ... o algo así. :) –

Respuesta

2

Intente configurar el proyecto de inicio para que apunte a 32bits, eso debería evitar el aparente problema de 64 bits. Y explica por qué funciona bien con MVC.

+1

Esto resolvió el problema. También publiqué un trabajo que funcionó para mí antes de esta mejor respuesta. Pagaría $ 5 :) para que alguien me diga definitivamente por qué funciona bien en Win 7 de 64 bits y en el mismo servidor Win 2008 RC2 bajo IIS pero NO como un servicio de Windows. – kingdango

0

NOTA: La siguiente es una solución que funcionó para mí ANTES de obtener una mejor respuesta. La mejor respuesta fue compilar el proyecto de servicio de Windows para apuntar a x86 en lugar de a cualquier CPU. Todavía no se explica por qué Windows Server 2008 R2 es diferente de Win 7, pero esa es una pregunta diferente para un día diferente.

-

He encontrado una solución a mi problema. Cambié mi clave a una int (ya que eso es lo que realmente se está almacenando en la BD de todos modos, aunque técnicamente es una columna decimal) y proporciono explícitamente el TypeName = "Decimal" en el atributo Column.

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

En mi caso, nunca escribo en esta tabla, aunque es posible que tenga que hacerlo en el futuro. No estoy 100% seguro de cómo afectará esto a las filas de escritura, pero como la columna está marcada como DatabaseGenerated, asumo que no será un problema.

yo creo que es posible que si me meta x 86 en lugar de cualquiera de las CPU entonces podría resolverlo y voy a probar que la próxima según lo sugerido por @leppie

No obstante, todavía estoy curioso por saber qué esto presente este tipo de error: Common Language Runtime detectó un programa no válido.

+0

Podría ser mejor usar 'long' en lugar de' int', dado que alguien decidió que 'decimal' era una buena opción para una clave pública; p – leppie

Cuestiones relacionadas