Business
Jobs
  • About Us
  • Solutions
    • Job Postings
      Post your job and receive qualified candidates in 48h.
    • Candidate Assessments
      500+ technical and psychological tests, plus anti-fraud.
    • Headhunting
      Tailor-made executive search from start to finish.
    • Payroll + EOR
      Payroll dispersal and EOR across 15+ LATAM countries.
  • Pricing
  • Jobs

0

346
Views
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 answers
Answer question

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 Report

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 Report
Answer question
Find remote jobs

Discover the new way to find a job!

Top jobs
Top job categories
Business
Post vacancy Pricing Sales
Legal
Terms and conditions Privacy policy
© 2026 PeakU Inc. All Rights Reserved.
Andres GPT
Show me some job opportunities
There's an error!