18

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.

JYL
  • 8,228
  • 5
  • 39
  • 63
  • 2
    Any reason why you don't have the server and client in the same solution? Would make it easier to debug. – Lasse V. Karlsen Aug 04 '15 at 08:35
  • 2
    @Lasse : when you edit just a small part of the server or the client, it's really faster to restart just one and not both. In particular if you have a complex scenario which requires tons of clicks at the client-side, you're really happy to not start over at client side just to fix a server bug. – JYL Aug 04 '15 at 08:41
  • Sorry if I'm way off the mark, but possible duplicate of http://stackoverflow.com/questions/11646047/error-cannot-access-file-bin-debug-because-it-is-being-used-by-another-proc ? – Max von Hippel Aug 06 '15 at 17:37
  • I (inadvertently) posted the same question and someone suggested a different solution which worked well for me: https://stackoverflow.com/questions/32148635/visual-studio-2015-locks-dll-during-debugging – Shea Sep 01 '15 at 18:11

2 Answers2

14

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

JuanK
  • 2,056
  • 19
  • 32
-8

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
holroy
  • 3,047
  • 25
  • 41
  • Thanks for your answer, I completely understand what you mean. However, our process is working well since Visual Studio 2005 (7 years ago) for teams up to 20 developers. I can't ask them to change their mind just because we upgraded to VS2015. – JYL Aug 12 '15 at 08:46
  • I see a hack has been given to workaround this, but at some point you really ought to do "the right thing". You can, and should, expect to change processes as the world progress. – holroy Aug 12 '15 at 08:49
  • 4
    This is your opinion. Our process evolve constantly on things that matters. This is not one of these. – JYL Aug 12 '15 at 11:29