SharpDevelop Community

The default project is not being set or it has something wrong with it.

When I set a project as the startup project and I press F5 I want that only the assemblies that this project references (and that the others project references - dependencies) are compiled and then the project that I selected as startup is launched.

But when I press the F5, the #D begin to compile all projects, so if one of theses projects has an error, but it is not a dependence for the startup of their libraries, the launcher stops and don't launch the startup project.

 

Other thing, when I compile, execute and finish the application, then do the same thing some times, the #D locks one of the assemblies (in my case a reference assembly - Status.dll) and the next compilation won't get to compile the project again, because the output won't be abble to overwrite the locked file...

 

ehhhhh, Did you understood what I say? My english is not very good :P

F5 building just the startup project instead of rebuilding the entire solution has been added to the tracker as a feature request.

The second problem looks like the debugger is locking the assembly. Which version of SharpDevelop 2.1 are you using?
 

The last from the svn!



 

I've been getting the same locking issue for a week or so.  After every one or two compiles and runs I need to close #D completely and restart it.  Often if I'm doing a lot of updates and debugging it's just easier to use VS.Net.

I never got the debugger locking problem for "simple" projects (only one project in solution); but it occurs frequently when debugging SharpDevelop.sln.

Ops, I almost missed this post because of the generic "I got a problem" name.

The assembly locking is an evil problem because is it hard to reproduce. Personaly, I have not seen it for over a half a year  -  that is, when I have done a lot of work to try to fix it.

I have done some major changes in revs 1685 - 1691  (10.8.2006). Is it possible that the locking problem is happening since then?

Also, have anyone seen this problem with #D 2.0 final release?

I've seen it from time to time with every version. It seems to happen more frequently when solution is complex. The debugger doesn't lock the .exe being debugged, only some of the referenced libraries are locked.

I reproduced it on SharpDevelop 2.1.0.1744 just now: Open SharpDevelop.sln, run with debugger, exit the debugged SharpDevelop instance.

Change something in ICSharpCode.SharpDevelop (e.g. insert some whitespace somewhere), rebuild:

C:\Windows\Microsoft.NET\Framework\v2.0.50727\Microsoft.Common.targets(2314,9) : Error MSB3021: Unable to copy file "obj\Debug\ICSharpCode.SharpDevelop.dll" to "..\..\..\..\bin\ICSharpCode.SharpDevelop.dll". The process cannot access the file '..\..\..\..\bin\ICSharpCode.SharpDevelop.dll' because it is being used by another process.

Can reproduce with 1744 (1st try)

Can not reproduce with 2.0 release (6 tryes) 

I have to leave soon, but a quick question: Is it possible to find out how many COM objects in Debugger.Interop stay referenced after a debugee is stopped? One of the main purposes of Debugger.Wrappers namespace is to track all COM objects and then relesease them with FinalReleaseComObject in ResourceManager.cs

 

I don't know how to reproduce this problem, but I am using the last version from SVN and my solution folders has more than one executable projects. The problem with me, occurs when I open some project, execute another one with the debugger then forces the debugging finishing or just exit the program and re-run the project.

 

But only with more than one dependencies for the projects.

Hopefuly fixed in rev. 1832.

This bug is a real pain, took nearly whole day