Solución:
Experimenté este problema hoy.
los machine.config los archivos se encuentran en:
C:WindowsMicrosoft.NETFrameworkv2.0.50727CONFIGmachine.configC:WindowsMicrosoft.NETFrameworkv4.0.30319Configmachine.configC:WindowsMicrosoft.NETFramework64v2.0.50727CONFIGmachine.configC:WindowsMicrosoft.NETFramework64v4.0.30319Configmachine.config
La versión corrupta de machine.config contiene:
<system.data>
<DbProviderFactories>
<add name="IBM DB2 for i .NET Provider" invariant="IBM.Data.DB2.iSeries" description=".NET Framework Data Provider for IBM i" type="IBM.Data.DB2.iSeries.iDB2Factory, IBM.Data.DB2.iSeries, Version=12.0.0.0, Culture=neutral, PublicKeyToken=9cdb2ebfb1f93a26" />
</DbProviderFactories>
<DbProviderFactories/>
</system.data>
La instalación de los controladores de iSeries dañó lo siguiente machine.config archivos:
| Framework | Platform | Factory Added? | Corrupted Machine.config? |
|-----------|----------|----------------|---------------------------|
|v4.0.30319 | x64 | Yes | Yes |
|v4.0.30319 | x86 | Yes | Yes |
|v2.0.50727 | x86 | No | No |
|v2.0.50727 | x64 | No | No |
Es bueno que solo tenga que preocuparse de que IBM corrompa la mitad de su machine.config archivos; y de aquellas únicas aplicaciones que utilizan .NET 4.
Archivos para arreglar
-
C:WindowsMicrosoft.NETFrameworkv2.0.50727CONFIGmachine.config(OK) -
C:WindowsMicrosoft.NETFrameworkv4.0.30319Configmachine.config(OK) -
C:WindowsMicrosoft.NETFramework64v2.0.50727CONFIGmachine.config(corrupto) -
C:WindowsMicrosoft.NETFramework64v4.0.30319Configmachine.config(corrupto)
Desde un Bloc de notas elevado, abra los dos archivos y elimine el vacío extraño <DbProviderFactories/> elemento, dejándote con:
<system.data>
<DbProviderFactories>
<add name="IBM DB2 for i .NET Provider" invariant="IBM.Data.DB2.iSeries" description=".NET Framework Data Provider for IBM i" type="IBM.Data.DB2.iSeries.iDB2Factory, IBM.Data.DB2.iSeries, Version=12.0.0.0, Culture=neutral, PublicKeyToken=9cdb2ebfb1f93a26" />
</DbProviderFactories>
</system.data>
Y estás arreglado.
El problema se debe a la instalación de IBM iAccess para Windows, específicamente el componente .NET Provider para DB2. Lo he visto de primera mano en V7R1, pero otros han hecho referencia al mismo problema con V6R1.
IBM es consciente del problema y tiene una solución en una de las versiones de servicio.
De la documentación de la versión del servicio V7R1:
DESCRIPCIÓN DEL PROBLEMA SOLUCIONADO PARA EL APAR SE45767:
En circunstancias desconocidas, se producen daños en el archivo XML machine.config cuando se instala el proveedor de datos .Net (ya sea como parte de un tipo de instalación completa o personalizada). La corrupción se aísla a porciones de los datos XML relacionados con DbProviderFactories y, en general, se ha observado que incluye la duplicación de algunas líneas de los datos XML.
CORRECCIÓN PARA APAR SE45767:
Se proporcionará una solución preventiva que eliminará la causa probable de la corrupción de machine.config.
No se proporcionará una solución correctiva para actualizar los archivos machine.config ya dañados. Utilice la solución local documentada o la elusión si es posible.
ELUSIÓN PARA APAR SE45767:
Si no se necesita el proveedor de datos .Net, este problema puede evitarse realizando una instalación personalizada y asegurándose de que no se instalará el proveedor de datos .Net. Si se requiere el proveedor .Net, no se conoce ninguna elusión. Utilice la solución local para resolver el problema.
En cuanto a solucionar el problema una vez que ha ocurrido, necesita arreglar machine.config (tanto de 32 bits como de 64 bits), porque no se ajusta al esquema definido para system.data. Eso es fácil: simplemente escriba una aplicación .NET simple que use XmlDocument para cargar machine.config, ubique el elemento DbProviderFactories duplicado, elimínelo y guarde el archivo. O use un script de PowerShell o cualquier otra cosa que pueda manipular documentos XML.
Aquí hay un APAR de IBM que analiza este problema en V6R1.