c# - studio - La aplicación.NET se ejecutará como una aplicación de consola, pero no como formularios Windows Forms, Debug Works
publicar solucion visual studio 2017 (2)
Tengo una aplicación para Windows que funcionaba una vez antes en .NET 2.0, y solo quería llevarla a .NET Framework 4. He hecho esto cientos de veces antes sin ningún problema.
Larga historia corta: después de actualizar, puedo ejecutar la aplicación de Windows (escrita en C #) desde los modos de depuración y lanzamiento. Todas mis asambleas están configuradas para construir la segmentación (x86) para asegurarse de que las dependencias de 32 bits se ejecutarán en Windows 7 x64. Lo extraño es que cuando ejecuto el ejecutable desde los directorios bin / x86 / Debug o Release, no sucede nada. Literalmente nada. La aplicación se inicia y, a continuación, se detiene de inmediato, y no hay mensajes de error, no se bloquea, no se escriben elementos en el registro de eventos. Simplemente comienza y luego se detiene.
La parte loca es que si cambio el tipo de salida del proyecto a "Aplicación de consola", ¡entonces funciona para ejecutarlo desde un archivo exe! (Solo tiene una ventana de consola molesta y fea en la parte posterior de la aplicación mientras se ejecuta).
¿Alguien ha escuchado algo como esto antes?
Aquí están las cosas que he probado y más información:
- Se buscó cualquier mención de errores en el registro de eventos.
- Intenté correr como administrador
- Ya soy el administrador de la computadora con acceso completo a todos los directorios.
- Intenté poner sentencias de MessageBox.Show en la función Main ()
- Intenté poner sentencias Console.WriteLine en la función Main ()
- Intenté hacer públicas las funciones principales.
- Intenté iniciar la aplicación exe haciendo doble clic en ella y ejecutándola desde la línea de comandos (la salida de la consola no apareció en ese caso).
- Ejecutables probados compilados para Debug AND Release
- Se intentó eliminar la llamada para iniciar MainForm.cs, donde solo permanece el código de MessageBox.
- Otras aplicaciones de Windows Forms que son puramente .NET 4.0 se ejecutan bien desde su ejecutable.
- El .NET Framework 4.0 no parece estar dañado, sin embargo, no he intentado volver a instalarlo en su totalidad.
- Intenté agregar un try / catch en la función principal para capturar e informar cualquier error.
- Windows 7, 64 bits
- Visual Studio 2010
- Actualizaciones de Windows realizadas regularmente
- C # para todo el código
¿Alguien ha visto algo como esto? He estado trabajando con C # durante más de 14 años y no he visto este comportamiento antes.
Edición: Agregar código desde Program.cs menos las etiquetas de espacio de nombres y usar declaraciones
static class Program
{
/// <summary>
/// The main entry point for the application.
/// </summary>
[STAThread]
static void Main()
{
try
{
MessageBox.Show("Start");
Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(false);
Application.Run(new MainForm());
MessageBox.Show("End");
}
catch (Exception exp)
{
ExceptionDisplay.LaunchUnexpected(exp);
}
}
}
La clase ExceptionDisplay es solo un simple formulario de Windows que muestra e informa el error inesperado. En este caso, no importa si el bloque try / catch está presente o no. El mismo comportamiento ocurre con el ejecutable.
EDIT: Agregar códigos de salida cuando está en modo de depuración
The thread ''vshost.RunParkingWindow'' (0xf70) has exited with code 0 (0x0).
The thread ''<No Name>'' (0x25c0) has exited with code 0 (0x0).
The program ''[13496] MyProgram.vshost.exe: Managed (v4.0.30319)'' has exited with code 0 (0x0).
EDITAR: Agregar elementos del Grupo de propiedades del archivo .csproj
<PropertyGroup>
<Configuration Condition=" ''$(Configuration)'' == '''' ">Debug</Configuration>
<Platform Condition=" ''$(Platform)'' == '''' ">AnyCPU</Platform>
<ProductVersion>9.0.30729</ProductVersion>
<SchemaVersion>2.0</SchemaVersion>
<ProjectGuid>{C5FE7F9D-57BB-4A6F-AD53-43BE99BAB6CF}</ProjectGuid>
<OutputType>WinExe</OutputType>
<AppDesignerFolder>Properties</AppDesignerFolder>
<RootNamespace>MyNamespace</RootNamespace>
<AssemblyName>MyAssemblyName</AssemblyName>
<TargetFrameworkVersion>v4.0</TargetFrameworkVersion>
<FileAlignment>512</FileAlignment>
<FileUpgradeFlags>
</FileUpgradeFlags>
<UpgradeBackupLocation>
</UpgradeBackupLocation>
<OldToolsVersion>3.5</OldToolsVersion>
<TargetFrameworkProfile />
<IsWebBootstrapper>true</IsWebBootstrapper>
<PublishUrl>http://localhost/MyNamespace/</PublishUrl>
<Install>true</Install>
<InstallFrom>Web</InstallFrom>
<UpdateEnabled>true</UpdateEnabled>
<UpdateMode>Foreground</UpdateMode>
<UpdateInterval>7</UpdateInterval>
<UpdateIntervalUnits>Days</UpdateIntervalUnits>
<UpdatePeriodically>false</UpdatePeriodically>
<UpdateRequired>false</UpdateRequired>
<MapFileExtensions>true</MapFileExtensions>
<ApplicationRevision>0</ApplicationRevision>
<ApplicationVersion>1.0.0.%2a</ApplicationVersion>
<UseApplicationTrust>false</UseApplicationTrust>
<BootstrapperEnabled>true</BootstrapperEnabled>
</PropertyGroup>
<PropertyGroup Condition=" ''$(Configuration)|$(Platform)'' == ''Debug|AnyCPU'' ">
<DebugSymbols>true</DebugSymbols>
<DebugType>full</DebugType>
<Optimize>false</Optimize>
<OutputPath>bin/Debug/</OutputPath>
<DefineConstants>DEBUG;TRACE</DefineConstants>
<ErrorReport>prompt</ErrorReport>
<WarningLevel>4</WarningLevel>
</PropertyGroup>
<PropertyGroup Condition=" ''$(Configuration)|$(Platform)'' == ''Release|AnyCPU'' ">
<DebugType>pdbonly</DebugType>
<Optimize>true</Optimize>
<OutputPath>bin/Release/</OutputPath>
<DefineConstants>TRACE</DefineConstants>
<ErrorReport>prompt</ErrorReport>
<WarningLevel>4</WarningLevel>
</PropertyGroup>
<PropertyGroup Condition=" ''$(Configuration)|$(Platform)'' == ''Debug|x86'' ">
<DebugSymbols>true</DebugSymbols>
<OutputPath>bin/x86/Debug/</OutputPath>
<DefineConstants>DEBUG;TRACE</DefineConstants>
<DebugType>full</DebugType>
<PlatformTarget>x86</PlatformTarget>
<ErrorReport>prompt</ErrorReport>
</PropertyGroup>
<PropertyGroup Condition=" ''$(Configuration)|$(Platform)'' == ''Release|x86'' ">
<OutputPath>bin/x86/Release/</OutputPath>
<DefineConstants>TRACE</DefineConstants>
<Optimize>true</Optimize>
<DebugType>pdbonly</DebugType>
<PlatformTarget>x86</PlatformTarget>
<ErrorReport>prompt</ErrorReport>
</PropertyGroup>
<PropertyGroup>
<ApplicationIcon>security.ico</ApplicationIcon>
</PropertyGroup>
<PropertyGroup>
<SignAssembly>true</SignAssembly>
</PropertyGroup>
<PropertyGroup>
<AssemblyOriginatorKeyFile>company.snk</AssemblyOriginatorKeyFile>
</PropertyGroup>
<PropertyGroup>
<StartupObject />
</PropertyGroup>
ACTUALIZACIÓN: Intenté mover todos los archivos de un proyecto a otro proyecto nuevo, y después de compilarlo, el archivo exe estaba funcionando. Luego, en preparación para la implementación, hice algunas cosas para el proyecto (incluida la firma con un nombre seguro, cambiando el icono del programa, etc.) y luego el exe dejó de funcionar. Después de limitarlo a la última secuencia de eventos que realicé, alterné cada uno de los elementos que cambié recientemente de uno en uno, y descubrí que el elemento que está causando que el archivo exe no esté configurando un ícono no predeterminado .
Si cambio el icono predeterminado a un archivo .ico, se depurará pero no ejecutará el archivo exe. Si vuelvo a cambiar el ícono a (Ícono Predeterminado) en Aplicación >> Recursos >> Ícono y Manifiesto, entonces el archivo ejecutará perfectamente fuera del depurador ??? ¿Alguien tiene alguna idea de por qué cambiar algo tan inocuo como el icono predeterminado del programa haría que el EXE no se ejecute? Buscaré / investigaré esto más a fondo después de darme cuenta de la parte que está causando que no se ejecute.
@Matt Parece que tiene una política de seguridad aplicada en su máquina que impide cualquier ejecutable desconocido (al hacer clic de forma individual). Esto funciona bien en la depuración porque el proceso del host se habría marcado como seguro para esa política. Intente ejecutar el .exe en otra máquina donde no se apliquen las políticas de permisos elevados personalizados o póngase en contacto con su administrador de TI.
La respuesta a este problema terminó siendo algo totalmente inesperado. El problema radica en el icono de la aplicación .
Después de seguir con la solución de problemas, noté que cuando creé un nuevo proyecto, agregué todos los archivos al proyecto y lo compilé, el programa se ejecutaría desde el archivo EXE. Seguí haciendo cambios en el proyecto y luego, después de algunos toques finales (que incluían cambiar el ícono de la aplicación, agregar un nombre seguro y otras cosas que he hecho en muchas otras aplicaciones), noté que, de repente, el EXE se detuvo. Trabajando al hacer doble clic sobre él.
Finalmente lo reduje al hecho de que cuando tenía un Icono de aplicación predeterminado (Propiedades del proyecto >> Icono de la aplicación >>), la aplicación funcionaba bien cuando se ejecutaba desde un archivo EXE. Sin embargo, cuando cambié el icono al que estaba usando, el EXE dejó de funcionar.
He usado los íconos de aplicaciones antes, así que creé un proyecto de prueba que no hizo nada, pero donde cambié el ícono de la aplicación a este. Efectivamente, cuando hice eso, el EXE del programa de prueba dejó de funcionar.
A continuación, intenté usar un ícono diferente al que estaba usando, y el EXE de esa persona funcionó. Entonces, ahora lo había reducido a un problema con el ícono particular que estaba usando. Noté que el que funcionaba tenía una imagen de 4x16 4 bits y 32x32 de 4 bits dentro de ella. Entonces abrí el que no funciona. El que no funciona tiene íconos de 48, 32, 24 y 16 píxeles para cada uno de (paletas de 4 bits, 8 bits y 32 bits).
Después de probar varias combinaciones para eliminar varias imágenes del ícono, ¡descubrí que las imágenes de íconos de colores de 8 bits estaban causando el problema! Después de eliminar todas las imágenes de 8 bits del icono, ¡el programa ahora funciona normalmente!
Entonces, la moraleja de la historia es que si bien los iconos con imágenes de 8 bits pueden funcionar bien para formularios y otros propósitos, no funcionan bien con aplicaciones .NET como un icono de aplicación.