Empresas
Empleos
  • Sobre nosotros
  • Soluciones
    • Publicación de vacantes
      Publica tu vacante y recibe candidatos calificados en 48h.
    • Evaluación de candidatos
      500+ pruebas técnicas y psicológicas, más anti-fraude.
    • Headhunting
      Búsqueda ejecutiva a la medida de principio a fin.
    • Nómina + EOR
      Dispersión de nómina y EOR en más de 15 países de LATAM.
  • Precios
  • Empleos

0

348
Vistas
Working with 2 Visual Studio 2015 instances : error CS2012 "file is being used by another process"

With Visual Studio 2013, I used to open 2 instances of Visual Studio :

  • one for a "server" solution (say a WCF host),
  • one for a "client" solution (say a WPF app).

The 2 solutions have a common project, but this was not an issue : I could start the first in debug mode, start the second in debug mode, find a bug, stop one to fix the bug, and start it again (without stopping the second).

This scenario is no more possible with VS2015 : when I stop-fix-start one, I get a build error on the common project :

error CS2012: Cannot open 'D:\MyProject\obj\Debug\myCommonLib.dll' for writing -- 
'The process cannot access the file 'D:\MyProject\obj\Debug\myCommonLib.dll' because it is being used by another process.'

Is there a way to configure this error as "non blocking" for visual studio 2015 OR to go back to the vs2013 behavior ?

EDIT

Process explorer shows this handles when the client app is started :

  • On VS2013 :

Handles on VS2013

  • On VS2015 :

Handles on VS2015

==> we can show here 2 more handles on dll in the "obj" folder. This seems to be the problem.

over 4 years ago · Santiago Trujillo
2 Respuestas
Responde la pregunta

0

From VS configure a new buid type for the project, this need to be configured the same as the Debug mode. Then run one of them in "Debug" and the other one in "Debug 2".

I hope these picture-guide could help you.

Goto Menu Debug and choose Config Manager

Create a new build configuration

Name it as you want

over 4 years ago · Santiago Trujillo Denunciar

0

To have a common project in two solutions is simply wrong. If it has worked in VS2013 I would consider it as a bug, which according to you has been fixed in VS2015.

The correct way forward, is to either join the two solutions into one with different projects, or to isolate the common project into a separate solution to help VS2015 distinguish between the three parts:

  • the server part
  • the client part
  • the common part
over 4 years ago · Santiago Trujillo Denunciar
Responde la pregunta
Encuentra empleos remotos

¡Descubre la nueva forma de encontrar empleo!

Top de empleos
Top categorías de empleo
Empresas
Publicar vacante Precios Comercial
Legal
Términos y condiciones Política de privacidad
© 2026 PeakU Inc. All Rights Reserved.
Andres GPT
Recomiéndame algunas ofertas
Necesito ayuda