visual tutorial studio proyectos instalar form ejemplos aparece c# .net winforms visual-studio

tutorial - windows forms c# visual studio 2017



La creación de Visual Studio falla: no se puede copiar el archivo exe de obj / debug a bin / debug (30)

Cambiar el nombre del archivo .exe y .pub funcionó para mí, pero realmente tedioso. También me enfrento al problema de que no pude editar durante una sesión de depuración. Finalmente, fui a la Página de configuración de seguridad avanzada, según:

https://msdn.microsoft.com/query/dev10.query?appId=Dev10IDEF1&l=EN-US&k=k%28%22VS.ERR.DEBUG_IN_ZONE_NO_HOSTPROC%3a11310%22%29;k%28TargetFrameworkMoniker-%22.NETFRAMEWORK%2cVERSION % 3dV4.0% 22% 29 & rd = true

Desmarque y luego vuelva a seleccionar la casilla de verificación "Habilitar la configuración de seguridad de ClickOnce". Ha estado libre de problemas durante algunos días ...

Actualización: un proyecto de muestra que reproduce este error se puede encontrar aquí en Microsoft Connect . También probé y verifiqué que la solución dada en la respuesta aceptada a continuación funciona en ese proyecto de muestra. Si esta solución no funciona para usted, probablemente tenga un problema diferente (que pertenece a otra pregunta).

Esta es una pregunta hecha antes, tanto aquí en Stack Overflow como en otros lugares, pero ninguna de las sugerencias que he encontrado hasta aquí me ha ayudado, así que solo tengo que intentar hacer una nueva pregunta.

Escenario: tengo una aplicación simple de Windows Forms (C #, .NET 4.0, Visual Studio 2010). Tiene un par de formas básicas heredadas de la mayoría de las otras formas, usa Entity Framework (y clases POCO) para el acceso a la base de datos. Nada de lujo, sin multi-threading ni nada.

Problema: todo estuvo bien por un tiempo. Entonces, de la nada, Visual Studio no pudo construir cuando estaba a punto de iniciar la aplicación. Recibí la advertencia "No se pudo eliminar el archivo ''... bin / Debug / [ProjectName] .exe''. Se deniega el acceso a la ruta ''... bin / Debug / [ProjectName] .exe''." y el error "No se puede copiar el archivo ''obj / x86 / Debug / [ProjectName] .exe'' a ''bin / Debug / [ProjectName] .exe''. El proceso no puede acceder al archivo ''bin / Debug / [ProjectName] .exe ''porque está siendo utilizado por otro proceso''. (Recibo la advertencia y el error al ejecutar Rebuild, pero solo el error al ejecutar Build, ¿no cree que es relevante?)

Entiendo perfectamente bien lo que dice el mensaje de advertencia y error: Visual Studio obviamente está intentando sobrescribir el archivo exe mientras que al mismo tiempo tiene un bloqueo en él por algún motivo. Sin embargo, esto no me ayuda a encontrar una solución al problema ... Lo único que he encontrado trabajando es cerrar Visual Studio y volver a iniciarlo. La creación y el lanzamiento funcionan, hasta que realizo un cambio en algunos de los formularios, entonces vuelvo a tener el mismo problema y tengo que reiniciar ... ¡Muy frustrante!

Como mencioné anteriormente, este parece ser un problema conocido, por lo que hay muchas soluciones sugeridas. Voy a enumerar lo que ya he intentado aquí, para que la gente sepa qué omitir:

  • Creando una nueva solución limpia y solo copia los archivos de la solución anterior.

  • Agregando lo siguiente a lo siguiente al evento de preconstrucción del proyecto:

    if exist "$(TargetPath).locked" del "$(TargetPath).locked" if not exist "$(TargetPath).locked" if exist "$(TargetPath)" move "$(TargetPath)" "$(TargetPath).locked"

  • Agregando lo siguiente a las propiedades del proyecto (archivo .csproj):

    <GenerateResourceNeverLockTypeAssemblies>true</GenerateResourceNeverLockTypeAssemblies>

Sin embargo, ninguno de ellos funcionó para mí, por lo que probablemente puedas ver por qué estoy empezando a frustrarme un poco. No sé dónde más buscar, ¡así que espero que alguien tenga algo que darme! ¿Es esto un error en VS, y si es así hay un parche? ¿O he hecho algo mal, tengo una referencia circular o similar y, de ser así, cómo podría averiguarlo?

Cualquier sugerencia es altamente apreciada :)

Actualización: como mencioné en el comentario a continuación, también he comprobado usando Process Explorer que en realidad es Visual Studio que está bloqueando el archivo.

Como no recibí más comentarios sobre este tema, pensé que simplemente compartiría lo que terminó siendo mi solución:

Como sugirió Barry en un comentario a la publicación original, cambiar manualmente el nombre ''... bin / Debug [ProjectName] .exe'' a otra cosa (por ejemplo, ''[ProjectName] 1.exe'' ) es una solución alternativa (I '' Sin embargo, no puedo borrar el archivo yo mismo, y debo decir que me parece un poco raro ya que uno podría creer que el mismo bloqueo que evita la eliminación también evitaría el cambio de nombre ...). No es una buena solución, pero es razonablemente rápido (al menos después de haberlo hecho un par de veces, casi se convierte en una rutina), y al menos mucho más rápido que reiniciar Visual Studio, que es lo que hice al principio.

En caso de que alguien se pregunte, también podría agregar que solo veo este problema de forma semi-aleatoria. Suele suceder después de que he hecho algunos cambios en el modo de diseño de un formulario (pero no siempre). Por lo general, no sucede si solo cambio el código de lógica de negocios o el código no visual relacionado (pero a veces lo hace ...). Frustrante, de hecho, pero al menos tengo un truco que funciona para mí, solo esperamos que mi próximo proyecto no enfrente este problema también ...

@Barry: si desea obtener crédito por su comentario, no dude en publicarlo como respuesta y me aseguraré de aceptarlo :)

Cuando me enfrenté a un problema similar, lo único que parecía funcionar era:

  • Haga clic con el botón derecho en el proyecto, vaya a Configuración y asegúrese de que tanto las compilaciones de Depuración como de Liberación se dirigen a la misma configuración o tienen la configuración que la aplicación intenta cargar o guardar.
  • Eliminando la carpeta C: / Users (YourUserAccount) / AppData / Local (YourAppName).
  • Asegurándome de que ningún archivo que tenía allí se consideraba "Bloqueado". Al hacer clic con el botón derecho en los archivos incluidos en mi proyecto, me di cuenta de que un ícono en realidad estaba bloqueado y se consideraba malo porque se había descargado de Internet. Tuve que hacer clic en el botón Desbloquear (en ejemplo, mira esto: http://devierkoeden.com/Images/Articles/Dynamicweb/CustomModules/Part1/BlockedFiles.png - "Este archivo vino de otra computadora y podría estar bloqueado para ayudar proteger esta computadora ").

Cuando me he encontrado con este problema, tengo que ver con el hecho de que el proyecto que intento crear está configurado como el proyecto de inicio en la solución que hace que el archivo .exe en la carpeta obj esté bloqueado (también aparece en su administrador de tareas) Haga clic derecho en otro proyecto en su solución y elija establecer proyecto de inicio. Esto liberará el bloqueo, lo eliminará del administrador de tareas y debería permitirle construir.

Deshabilitar "Habilitar el proceso de alojamiento de Visual Studio"

Encontré una solución simple, simplemente deshabilite los Servicios de Index Server de Windows para la carpeta del proyecto y las subcarpetas

Enfrenté el mismo error.

Resolví el problema borrando todo el contenido de las carpetas bin de todos los proyectos / bibliotecas dependientes.

Este error ocurre principalmente debido a cambios de versión.

Esto es comúnmente causado por Avast.

Por lo general, puedo ejecutar mis proyectos en Release independientemente, pero cuando ejecuto la depuración fallará con bastante frecuencia.

Acabo de agregar una exclusión para la carpeta de proyectos y el problema parece desaparecer. Supongo que esto también podría ser causado por otro software antivirus.

Esto va a sonar estúpido, pero probé todas estas soluciones, ejecutando VS2010 en Windows 7. Ninguno de ellos funcionó, excepto el cambio de nombre y construcción, que fue MUY tedioso por decir lo menos. Eventualmente, localicé al culpable, y me resulta difícil de creer. Pero estaba usando el siguiente código en AssemblyInfo.cs ...

[assembly: AssemblyVersion("2.0.*")]

Esto es bastante común, pero por alguna razón, cambiar la versión a 2.0.0.0 hizo que las cosas funcionen nuevamente. No sé si es algo específico de Windows 7 (solo lo he usado durante 3-4 semanas), o si es aleatorio, o qué, pero lo solucioné para mí. Supongo que VS estaba controlando cada archivo que generaba, por lo que sabría cómo incrementar las cosas. Realmente no estoy seguro y nunca he visto esto suceder antes. Pero si alguien más está tirando de sus cabellos, pruébalo.

Haz las cosas simples primero.

Verifique que parte de su solución no esté bloqueada por un proceso en ejecución.

Por ejemplo, ejecuté "InstallUtil" en mi servicio de Windows (que normalmente pruebo en una unidad desde una consola).

Esto bloqueó algunos de mis dlls en la carpeta bin del proyecto de servicio de Windows. Cuando hice una reconstrucción obtuve la excepción en este tema.

Paré el servicio de Windows, reconstruí y tuve éxito.

Verifique el Administrador de tareas de Windows para su Aplicación, antes de seguir cualquiera de los pasos avanzados en este tema.

Entonces, cuando oigas pasos, piensa en caballos, no en cebras. (del estudiante de medicina amigo)

He encontrado con VS2013 que recibo este error regularmente. Algo que parece funcionar razonablemente bien es realizar una Solución de reconstrucción antes de intentar ejecutar la aplicación. Descubrí que realizar una LIMPIEZA a veces funciona, pero la Solución de reconstrucción parece funcionar de manera más consistente.

Intenté varias soluciones que me proporcionó, pero ocasionalmente recibo este error. Estoy seguro de que mi proceso no se está ejecutando, y cuando intento eliminar el archivo ejecutable con Internet Explorer, lo elimino de la lista de archivos, pero luego presiono F5 y listo, el archivo está de vuelta. No ha sido eliminado en absoluto.

Pero si elimino el archivo a través de TotalCommander, el archivo exe se borra y puedo crear el proyecto correctamente.

Estoy usando Windows 7 x64 y total commander 7.56a 32 bit.

Ninguna de las otras respuestas funcionó para mí, pero el cierre de todas las pestañas abiertas en Visual Studio parece haber resuelto el problema.

Para los Servicios de Windows que usan WCF, terminé el proceso de host de WFC y funcionó. Odio cuando sucede esto, y sucede aleatoriamente a veces.

Para mí, esto fue causado por tener un símbolo del sistema abierto en la carpeta de destino ( C:/users/username/source/repos/project/project/bin/debug/app.publish ).

No estoy seguro de por qué DEBUGGING requiere acceso a la carpeta de publicación, pero el hecho de cerrar la ventana de comandos me solucionó el problema.

Probé todas las otras sugerencias en las respuestas aquí, ninguna de las cuales funcionó. Eventualmente utilicé Process Monitor para descubrir que mi .exe que VS2010 no podía construir estaba bloqueado por el proceso del Sistema (PID = 4). Buscar SO para situaciones que involucran esto arrojó this respuesta.

Resumido: si tiene el servicio Application Experience desactivado (como yo lo hice), vuelva a habilitarlo e inícielo. Dos años de agravación terminaron.

Reiniciar IIS: podría ser un proceso adjunto al depurador

Sé que esta es una pregunta muy antigua, pero recientemente experimenté el error "no se puede copiar de obj a bin" en VS 2012. Cada vez que intenté reconstruir un proyecto determinado, recibí el mensaje. La única solución fue hacer una limpieza antes de cada reconstrucción.

Después de mucha investigación, resultó que tenía una declaración de advertencia de pragma incompleta en uno de mis archivos que no impidió que la compilación tuviera éxito, pero de alguna manera confundía VS para mantener el archivo (s) bloqueado.

En mi caso, tenía lo siguiente en la parte superior del archivo:

#pragma warning(

Eso es. Creo que estaba intentando hacer algo hace un tiempo y me distraí y nunca terminé el proceso, pero las advertencias de VS sobre esa línea en particular se perdieron en la confusión. Eventualmente noté la advertencia, eliminé la línea y reconstruí trabajos desde entonces.

Si ninguno de los anteriores funciona, y está desarrollando una aplicación de consola:

Intente escribir cualquier caracter en Program.cs, luego bórrelo. No tengo idea de por qué funciona, pero parece resolver el problema de "No se puede copiar" todo el tiempo.

También tuve un problema muy similar a esto y encontré que la razón en mi caso era que había hecho que la carpeta bin / debug estuviera disponible como una carpeta compartida bajo VMware y VMware, Explorer debajo del invitado de la VM o incluso un antivirus. programa debajo del invitado (aunque no creo que tuviera uno instalado) estaba sosteniendo un control para el archivo (s).

Tengo el mismo problema (MSB3021) con el proyecto WPF en VS2008 (en Windows 7 x32). El problema aparece si trato de volver a ejecutar la aplicación demasiado rápido después de la ejecución anterior. Después de unos minutos, el archivo exe se desbloqueó solo y puedo volver a ejecutar la aplicación nuevamente. Pero una pausa tan larga me enoja. Lo único que realmente me ayudó fue ejecutar VS como administrador.

Tuve el mismo problema Decía que no podía copiar de bin / debug a obj .....

Cuando construyo un proyecto web, encontré que mi dll estaba en la carpeta bin y no en bin / debug. Durante publicación vs estaba buscando archivos en bin / debug. Así que abrí el archivo de proyecto web en el editor y busqué instancias de bin / debug y encontré que todas las dll se mencionaron como bin / debug / mylibrary.dll. Eliminé todo / depuración de la ruta y publiqué de nuevo. Esta vez vs fue capaz de encontrar todo el dll en la carpeta bin y publicar con éxito.

No tengo idea de cómo se cambió esta ruta en el archivo de proyecto web.

Pasé más de 5 horas depurando esto y finalmente encontré la solución por mi cuenta.

Esta es la respuesta correcta .

Usando Visual Studio, nunca podría llegar a un proyecto simple para reproducir el error.

Mi solución fue inhabilitar el proceso de Visual Studio Hosting.

Para los interesados ​​he adjuntado un identificador de control para el identificador ofensivo:

0:044> !htrace 242C -------------------------------------- Handle = 0x000000000000242c - OPEN Thread ID = 0x0000000000001cd0, Process ID = 0x0000000000001a5c 0x000000007722040a: ntdll!ZwCreateFile+0x000000000000000a 0x0000000074b4bfe3: wow64!whNtCreateFile+0x000000000000010f 0x0000000074b3cf87: wow64!Wow64SystemServiceEx+0x00000000000000d7 0x0000000074ac276d: wow64cpu!TurboDispatchJumpAddressEnd+0x0000000000000024 0x0000000074b3d07e: wow64!RunCpuSimulation+0x000000000000000a 0x0000000074b3c549: wow64!Wow64LdrpInitialize+0x0000000000000429 0x00000000772184c8: ntdll!LdrpInitializeProcess+0x00000000000017e2 0x0000000077217623: ntdll! ?? ::FNODOBFM::`string''+0x000000000002bea0 0x000000007720308e: ntdll!LdrInitializeThunk+0x000000000000000e 0x00000000773d0066: ntdll_773b0000!NtCreateFile+0x0000000000000012 0x000000007541b616: KERNELBASE!CreateFileW+0x000000000000035e 0x0000000075b42345: KERNEL32!CreateFileWImplementation+0x0000000000000069 0x000000006a071b47: mscorwks_ntdef!StgIO::Open+0x000000000000028c -------------------------------------- Handle = 0x000000000000242c - CLOSE Thread ID = 0x0000000000000cd4, Process ID = 0x0000000000001a5c 0x000000007721ffaa: ntdll!ZwClose+0x000000000000000a 0x0000000074b3f2cd: wow64!whNtClose+0x0000000000000011 0x0000000074b3cf87: wow64!Wow64SystemServiceEx+0x00000000000000d7 0x0000000074ac276d: wow64cpu!TurboDispatchJumpAddressEnd+0x0000000000000024 0x0000000074b3d07e: wow64!RunCpuSimulation+0x000000000000000a 0x0000000074b3c549: wow64!Wow64LdrpInitialize+0x0000000000000429 0x000000007724d177: ntdll! ?? ::FNODOBFM::`string''+0x000000000002bfe4 0x000000007720308e: ntdll!LdrInitializeThunk+0x000000000000000e 0x00000000773cf992: ntdll_773b0000!ZwClose+0x0000000000000012 0x0000000075b42642: KERNEL32!BaseRegCloseKeyInternal+0x0000000000000041 0x0000000075b425bc: KERNEL32!RegCloseKey+0x000000000000007d *** WARNING: Unable to verify checksum for mscorlib.ni.dll 0x0000000068f13ca3: mscorlib_ni+0x0000000000233ca3 0x0000000069bc21db: mscorwks_ntdef!CallDescrWorker+0x0000000000000033 0x0000000069be4a2a: mscorwks_ntdef!CallDescrWorkerWithHandler+0x000000000000008e -------------------------------------- Handle = 0x000000000000242c - OPEN Thread ID = 0x00000000000006cc, Process ID = 0x0000000000001a5c 0x0000000077220e0a: ntdll!NtOpenKeyEx+0x000000000000000a 0x0000000074b5d1c9: wow64!Wow64NtOpenKey+0x0000000000000091 0x0000000074b5313b: wow64!whNtOpenKeyEx+0x0000000000000073 0x0000000074b3cf87: wow64!Wow64SystemServiceEx+0x00000000000000d7 0x0000000074ac276d: wow64cpu!TurboDispatchJumpAddressEnd+0x0000000000000024 0x0000000074b3d07e: wow64!RunCpuSimulation+0x000000000000000a 0x0000000074b3c549: wow64!Wow64LdrpInitialize+0x0000000000000429 0x000000007724d177: ntdll! ?? ::FNODOBFM::`string''+0x000000000002bfe4 0x000000007720308e: ntdll!LdrInitializeThunk+0x000000000000000e 0x00000000773d0fca: ntdll_773b0000!NtOpenKeyEx+0x0000000000000012 0x0000000075b42721: KERNEL32!LocalBaseRegOpenKey+0x000000000000010c 0x0000000075b428c9: KERNEL32!RegOpenKeyExInternalW+0x0000000000000130 0x0000000075b427b5: KERNEL32!RegOpenKeyExW+0x0000000000000021 -------------------------------------- Handle = 0x000000000000242c - CLOSE Thread ID = 0x0000000000000cd4, Process ID = 0x0000000000001a5c 0x000000007721ffaa: ntdll!ZwClose+0x000000000000000a 0x0000000074b3f2cd: wow64!whNtClose+0x0000000000000011 0x0000000074b3cf87: wow64!Wow64SystemServiceEx+0x00000000000000d7 0x0000000074ac276d: wow64cpu!TurboDispatchJumpAddressEnd+0x0000000000000024 0x0000000074b3d07e: wow64!RunCpuSimulation+0x000000000000000a 0x0000000074b3c549: wow64!Wow64LdrpInitialize+0x0000000000000429 0x000000007724d177: ntdll! ?? ::FNODOBFM::`string''+0x000000000002bfe4 0x000000007720308e: ntdll!LdrInitializeThunk+0x000000000000000e 0x00000000773cf992: ntdll_773b0000!ZwClose+0x0000000000000012 0x0000000075b42642: KERNEL32!BaseRegCloseKeyInternal+0x0000000000000041 0x0000000075b425bc: KERNEL32!RegCloseKey+0x000000000000007d 0x0000000068f13ca3: mscorlib_ni+0x0000000000233ca3 0x0000000069bc21db: mscorwks_ntdef!CallDescrWorker+0x0000000000000033 0x0000000069be4a2a: mscorwks_ntdef!CallDescrWorkerWithHandler+0x000000000000008e -------------------------------------- Handle = 0x000000000000242c - OPEN Thread ID = 0x0000000000001cd0, Process ID = 0x0000000000001a5c 0x0000000077220e0a: ntdll!NtOpenKeyEx+0x000000000000000a 0x0000000074b5d1c9: wow64!Wow64NtOpenKey+0x0000000000000091 0x0000000074b5313b: wow64!whNtOpenKeyEx+0x0000000000000073 0x0000000074b3cf87: wow64!Wow64SystemServiceEx+0x00000000000000d7 0x0000000074ac276d: wow64cpu!TurboDispatchJumpAddressEnd+0x0000000000000024 0x0000000074b3d07e: wow64!RunCpuSimulation+0x000000000000000a 0x0000000074b3c549: wow64!Wow64LdrpInitialize+0x0000000000000429 0x00000000772184c8: ntdll!LdrpInitializeProcess+0x00000000000017e2 0x0000000077217623: ntdll! ?? ::FNODOBFM::`string''+0x000000000002bea0 0x000000007720308e: ntdll!LdrInitializeThunk+0x000000000000000e 0x00000000773d0fca: ntdll_773b0000!NtOpenKeyEx+0x0000000000000012 0x0000000075b42721: KERNEL32!LocalBaseRegOpenKey+0x000000000000010c 0x0000000075b428c9: KERNEL32!RegOpenKeyExInternalW+0x0000000000000130 -------------------------------------- Handle = 0x000000000000242c - CLOSE Thread ID = 0x0000000000000cd4, Process ID = 0x0000000000001a5c 0x000000007721ffaa: ntdll!ZwClose+0x000000000000000a 0x0000000074b3f2cd: wow64!whNtClose+0x0000000000000011 0x0000000074b3cf87: wow64!Wow64SystemServiceEx+0x00000000000000d7 0x0000000074ac276d: wow64cpu!TurboDispatchJumpAddressEnd+0x0000000000000024 0x0000000074b3d07e: wow64!RunCpuSimulation+0x000000000000000a 0x0000000074b3c549: wow64!Wow64LdrpInitialize+0x0000000000000429 0x000000007724d177: ntdll! ?? ::FNODOBFM::`string''+0x000000000002bfe4 0x000000007720308e: ntdll!LdrInitializeThunk+0x000000000000000e 0x00000000773cf992: ntdll_773b0000!ZwClose+0x0000000000000012 0x0000000075b42642: KERNEL32!BaseRegCloseKeyInternal+0x0000000000000041 0x0000000075b425bc: KERNEL32!RegCloseKey+0x000000000000007d 0x0000000068f13ca3: mscorlib_ni+0x0000000000233ca3 0x0000000069bc21db: mscorwks_ntdef!CallDescrWorker+0x0000000000000033 0x0000000069be4a2a: mscorwks_ntdef!CallDescrWorkerWithHandler+0x000000000000008e -------------------------------------- Handle = 0x000000000000242c - OPEN Thread ID = 0x0000000000001cd0, Process ID = 0x0000000000001a5c 0x0000000077220e0a: ntdll!NtOpenKeyEx+0x000000000000000a 0x0000000074b5d1c9: wow64!Wow64NtOpenKey+0x0000000000000091 0x0000000074b5313b: wow64!whNtOpenKeyEx+0x0000000000000073 0x0000000074b3cf87: wow64!Wow64SystemServiceEx+0x00000000000000d7 0x0000000074ac276d: wow64cpu!TurboDispatchJumpAddressEnd+0x0000000000000024 0x0000000074b3d07e: wow64!RunCpuSimulation+0x000000000000000a 0x0000000074b3c549: wow64!Wow64LdrpInitialize+0x0000000000000429 0x00000000772184c8: ntdll!LdrpInitializeProcess+0x00000000000017e2 0x0000000077217623: ntdll! ?? ::FNODOBFM::`string''+0x000000000002bea0 0x000000007720308e: ntdll!LdrInitializeThunk+0x000000000000000e 0x00000000773d0fca: ntdll_773b0000!NtOpenKeyEx+0x0000000000000012 0x0000000075b42721: KERNEL32!LocalBaseRegOpenKey+0x000000000000010c 0x0000000075b428c9: KERNEL32!RegOpenKeyExInternalW+0x0000000000000130 -------------------------------------- Parsed 0x358E stack traces. Dumped 0x7 stack traces. 0:044> !handle 242c ff Handle 242c Type File Attributes 0 GrantedAccess 0x120089: ReadControl,Synch Read/List,ReadEA,ReadAttr HandleCount 2 PointerCount 3 No Object Specific Information available

Aquí hay otra posibilidad:

Después de recibir este error en vs2012 / win7, fui y traté de eliminar el archivo en el directorio bin y el explorador indicó que el diseñador de UI de XAML estaba usando el archivo.

Cerré todas las pestañas que tenía abiertas en VS, cerré VS, luego me aseguré de eliminar todos los procesos de MSBuild en taskmanager. Finalmente, después de reiniciar VS, pude construir la solución.

y otra posible causa:

He notado otra causa posible para este problema. Después de hacer un poco de refactorización de código, mover proyectos dentro y fuera de una solución, mis referencias de proyecto ya no hicieron referencia a los proyectos en la solución como se esperaba.

Este estudio visual engañoso cree que podría construir algunos proyectos al mismo tiempo, creando así los bloqueos de archivos.

EDITAR: He tenido esto en algunas ocasiones, incluso recientemente, con VS2012 y lo soluciona una vez que establezco el orden de compilación en las dependencias correctas, elimino todos los procesos de msbuild que VS dejó en ejecución, y luego reinicio VS. Mato los procesos de msbuild solo para estar seguro, pero cerrar VS también debería matarlos.

Lo que suelo hacer para causar esto es refactorizar un proyecto de tal manera que confíe en otro proyecto dentro de la solución que no estaba haciendo referencia en la última compilación. Esto a veces parece confundir VS y no actualiza el orden de compilación.

Para verificar el orden de compilación: Haga clic con el botón derecho en la Solución en el Explorador de soluciones y seleccione "Orden de compilación del proyecto ..." y verifique que las dependencias se anoten adecuadamente para cada proyecto.

Deshabilita el antivirus y prueba. También me enfrentaba a ese problema ... pero en mi caso el antivirus estaba bloqueando mi aplicación cuando desactivé el antivirus.

Mi solución no tiene nada que ver con las versiones, los procesos que se bloquean, reiniciar o eliminar archivos.

El problema se debió en realidad a la falla de compilación, y no dio el error correcto. El problema real era un defecto de diseño:

// Either this should be declared outside the function, or.. SomeObject a = new SomeObject(); Task.Factory.StartNew(() => { while (true) { a.waitForSomething(); } }); // ...this should not be called a.doSomething();

Después de cambiar el alcance de "a" a fuera de la función, o no usar "a" después de Task.Factory.StartNew(); , Pude construir de nuevo.

Esto sucedió al usar VS2012 Update 4 en Windows7x64 sp1.

Mensaje de error:

C: / Windows / Microsoft.NET / Framework / v4.0.30319 / Microsoft.Common.targets (3390,5): error MSB3030: No se pudo copiar el archivo "obj / x86 / Debug / xxx.exe" porque no se encontró .

SI SU PROBLEMA NO SE RESUELVE AÚN:

El error de Visual Studio es:

"El proceso no puede acceder al archivo ''bin / Debug ** app.exe **'' porque está siendo utilizado por otro proceso."

Por lo tanto, vaya al administrador de tareas de Windows (Ctrl + Shift + Esc), encuentre el nombre de su aplicación y fuerce que se cierre por Endprocces.