VS.NET file locking problem : Totally screwed

[Sin]

I've tried everything and I've come to the conclusion that I'm screwed. If
anyone can help, I would be eternaly greatful.

I have a solution which has 47 projects.. This is includes (very roughly) :

1- plain win32 C++ DLL projects (little over a dozen, refered to as BASE
OBJECTS)

2- ATL/COM/C++ DLLs which use the plain win32 DLLs (another dozen, refered
to as COM WRAPPERS)

3- VB.NET interface projects exposing COM classes which use the ATL/COM
DLLs. (another dozen, refered to as VB GUI)

4- One of the base objects is shared by all others, the same object's
wrapper is also shared, and so is it's VB gui project. This component is
refered to as the KERNEL.

5- The main application is VB.NET and uses the VB GUI projects

ALL projects are outputed to the same directory... Before you jump at this,
I have already tried outputing ALL of them to different directories and the
problem remains, so there's something else and I think it's related to COM.

So as you've probably guessed by now, everytime I do a build/rebuild on this
solution, there are a couple of projects which won't compile because I get
"Cannot access file because it's locked by another process" or similar
messages (there are actually 3 different ones, all pertaining to locked
DLLs).

Anytime this happens, the kernel's wrapper is usually one of those having
problems but it's VB gui also causes problems from time to time. There are 2
other wrappers which are almost always there too, but I have no clue why as
they are built the same way as others and are not used differently either.
When this happens I need to delete all the contents of my debug directories,
close VC and usually even reboot to fix the problem. It's getting extremely
iritating.

ALL these project's outputs are bigger than the 64K mentionne in the KB
articles.

I'm totally lost.... How can I make this work?

Thanks in advance... And please reply if you have ANY tip concerning this...
At this point I'm willing to try voodoo, weejaa and any other trick that
might help.

Alex.

[Charles Law]

Hi Alex

I get a similar problem with a solution with far fewer projects. Do you need
to work on all the projects at the same time? By that I mean could you build
some of the core projects, or some of the globally referenced projects, and
then remove them from the solution? The rest of the projects could still
reference the built dlls, but they would not get rebuilt every time. It
would also speed up the building of the solution quite a bit.

HTH

Charles
"Sin" <br****@hotmail.com> wrote in message
news:O5**************@TK2MSFTNGP12.phx.gbl...

I've tried everything and I've come to the conclusion that I'm screwed. If
anyone can help, I would be eternaly greatful.

I have a solution which has 47 projects.. This is includes (very roughly) :
1- plain win32 C++ DLL projects (little over a dozen, refered to as BASE
OBJECTS)

2- ATL/COM/C++ DLLs which use the plain win32 DLLs (another dozen, refered
to as COM WRAPPERS)

3- VB.NET interface projects exposing COM classes which use the ATL/COM
DLLs. (another dozen, refered to as VB GUI)

4- One of the base objects is shared by all others, the same object's
wrapper is also shared, and so is it's VB gui project. This component is
refered to as the KERNEL.

5- The main application is VB.NET and uses the VB GUI projects

ALL projects are outputed to the same directory... Before you jump at this, I have already tried outputing ALL of them to different directories and the problem remains, so there's something else and I think it's related to COM.
So as you've probably guessed by now, everytime I do a build/rebuild on this solution, there are a couple of projects which won't compile because I get
"Cannot access file because it's locked by another process" or similar
messages (there are actually 3 different ones, all pertaining to locked
DLLs).

Anytime this happens, the kernel's wrapper is usually one of those having
problems but it's VB gui also causes problems from time to time. There are 2 other wrappers which are almost always there too, but I have no clue why as they are built the same way as others and are not used differently either.
When this happens I need to delete all the contents of my debug directories, close VC and usually even reboot to fix the problem. It's getting extremely iritating.

ALL these project's outputs are bigger than the 64K mentionne in the KB
articles.

I'm totally lost.... How can I make this work?

Thanks in advance... And please reply if you have ANY tip concerning this... At this point I'm willing to try voodoo, weejaa and any other trick that
might help.

Alex.

[Charles Law]

Hi Alex

I get a similar problem with a solution with far fewer projects. Do you need
to work on all the projects at the same time? By that I mean could you build
some of the core projects, or some of the globally referenced projects, and
then remove them from the solution? The rest of the projects could still
reference the built dlls, but they would not get rebuilt every time. It
would also speed up the building of the solution quite a bit.

HTH

Charles
"Sin" <br****@hotmail.com> wrote in message
news:O5**************@TK2MSFTNGP12.phx.gbl...

I've tried everything and I've come to the conclusion that I'm screwed. If
anyone can help, I would be eternaly greatful.

I have a solution which has 47 projects.. This is includes (very roughly) :
1- plain win32 C++ DLL projects (little over a dozen, refered to as BASE
OBJECTS)

2- ATL/COM/C++ DLLs which use the plain win32 DLLs (another dozen, refered
to as COM WRAPPERS)

3- VB.NET interface projects exposing COM classes which use the ATL/COM
DLLs. (another dozen, refered to as VB GUI)

4- One of the base objects is shared by all others, the same object's
wrapper is also shared, and so is it's VB gui project. This component is
refered to as the KERNEL.

5- The main application is VB.NET and uses the VB GUI projects

ALL projects are outputed to the same directory... Before you jump at this, I have already tried outputing ALL of them to different directories and the problem remains, so there's something else and I think it's related to COM.
So as you've probably guessed by now, everytime I do a build/rebuild on this solution, there are a couple of projects which won't compile because I get
"Cannot access file because it's locked by another process" or similar
messages (there are actually 3 different ones, all pertaining to locked
DLLs).

Anytime this happens, the kernel's wrapper is usually one of those having
problems but it's VB gui also causes problems from time to time. There are 2 other wrappers which are almost always there too, but I have no clue why as they are built the same way as others and are not used differently either.
When this happens I need to delete all the contents of my debug directories, close VC and usually even reboot to fix the problem. It's getting extremely iritating.

ALL these project's outputs are bigger than the 64K mentionne in the KB
articles.

I'm totally lost.... How can I make this work?

Thanks in advance... And please reply if you have ANY tip concerning this... At this point I'm willing to try voodoo, weejaa and any other trick that
might help.

Alex.

[Sin]

> I get a similar problem with a solution with far fewer projects. Do you
need

to work on all the projects at the same time? By that I mean could you build some of the core projects, or some of the globally referenced projects, and then remove them from the solution? The rest of the projects could still
reference the built dlls, but they would not get rebuilt every time. It
would also speed up the building of the solution quite a bit.

Most of the time we will work on one of the objects (ie: the base object,
it's wrapper, and it's interface)... Indeed your solution would work and
don't worry we've though about it but ideally we would like a solution where
we can build all our projects without opening a couple dozen solutions...

Is there a way to compile a solution from the command line? I suppose if we
could then we could have a batch file compile all our solutions when
needed....

The idea is to keep things easy to work with... It will often happen that I
need to flush my entire project dir and replace it with a backup (a newer
version from my co-worker) and then recompile all...

Another problem is debugging... I need to be able to debug all projects
without switching from a solution to another. Note that this is something
I'm not even able to do now... Seems I can't trace from VB to C.......

I'll experiment along those lines... But ideally we'd want a single
solution... We've been working like this for 15 years, it would suck to
change the mentality :)

Alex.

[Sin]

> I get a similar problem with a solution with far fewer projects. Do you
need

to work on all the projects at the same time? By that I mean could you build some of the core projects, or some of the globally referenced projects, and then remove them from the solution? The rest of the projects could still
reference the built dlls, but they would not get rebuilt every time. It
would also speed up the building of the solution quite a bit.

Most of the time we will work on one of the objects (ie: the base object,
it's wrapper, and it's interface)... Indeed your solution would work and
don't worry we've though about it but ideally we would like a solution where
we can build all our projects without opening a couple dozen solutions...

Is there a way to compile a solution from the command line? I suppose if we
could then we could have a batch file compile all our solutions when
needed....

The idea is to keep things easy to work with... It will often happen that I
need to flush my entire project dir and replace it with a backup (a newer
version from my co-worker) and then recompile all...

Another problem is debugging... I need to be able to debug all projects
without switching from a solution to another. Note that this is something
I'm not even able to do now... Seems I can't trace from VB to C.......

I'll experiment along those lines... But ideally we'd want a single
solution... We've been working like this for 15 years, it would suck to
change the mentality :)

Alex.

[Charles Law]

I agree. I'm sure MS could fix this particular problem right now if they
would only release a service pack for the VS IDE. There are many other such
'niggles' that they are definitely aware of and which they must surely have
a fix for by now.

One other consideration that may improve the situation: have a look at the
linkage of your projects within the solution. I find that the problem is
greater when there is tight coupling and low cohesion. I have resolved this
issue on occasions by refactoring my solution to reduce the amount of
coupling between projects.

Charles
"Sin" <br****@hotmail.com> wrote in message
news:O8**************@TK2MSFTNGP09.phx.gbl...

I get a similar problem with a solution with far fewer projects. Do you need

to work on all the projects at the same time? By that I mean could you

build

some of the core projects, or some of the globally referenced projects,

and

then remove them from the solution? The rest of the projects could still
reference the built dlls, but they would not get rebuilt every time. It
would also speed up the building of the solution quite a bit.

Most of the time we will work on one of the objects (ie: the base object,
it's wrapper, and it's interface)... Indeed your solution would work and
don't worry we've though about it but ideally we would like a solution

where we can build all our projects without opening a couple dozen solutions...

Is there a way to compile a solution from the command line? I suppose if we could then we could have a batch file compile all our solutions when
needed....

The idea is to keep things easy to work with... It will often happen that I need to flush my entire project dir and replace it with a backup (a newer
version from my co-worker) and then recompile all...

Another problem is debugging... I need to be able to debug all projects
without switching from a solution to another. Note that this is something
I'm not even able to do now... Seems I can't trace from VB to C.......

I'll experiment along those lines... But ideally we'd want a single
solution... We've been working like this for 15 years, it would suck to
change the mentality :)

Alex.

[Charles Law]

I agree. I'm sure MS could fix this particular problem right now if they
would only release a service pack for the VS IDE. There are many other such
'niggles' that they are definitely aware of and which they must surely have
a fix for by now.

One other consideration that may improve the situation: have a look at the
linkage of your projects within the solution. I find that the problem is
greater when there is tight coupling and low cohesion. I have resolved this
issue on occasions by refactoring my solution to reduce the amount of
coupling between projects.

Charles
"Sin" <br****@hotmail.com> wrote in message
news:O8**************@TK2MSFTNGP09.phx.gbl...

I get a similar problem with a solution with far fewer projects. Do you need

to work on all the projects at the same time? By that I mean could you

build

some of the core projects, or some of the globally referenced projects,

and

then remove them from the solution? The rest of the projects could still
reference the built dlls, but they would not get rebuilt every time. It
would also speed up the building of the solution quite a bit.

Most of the time we will work on one of the objects (ie: the base object,
it's wrapper, and it's interface)... Indeed your solution would work and
don't worry we've though about it but ideally we would like a solution

where we can build all our projects without opening a couple dozen solutions...

Is there a way to compile a solution from the command line? I suppose if we could then we could have a batch file compile all our solutions when
needed....

The idea is to keep things easy to work with... It will often happen that I need to flush my entire project dir and replace it with a backup (a newer
version from my co-worker) and then recompile all...

Another problem is debugging... I need to be able to debug all projects
without switching from a solution to another. Note that this is something
I'm not even able to do now... Seems I can't trace from VB to C.......

I'll experiment along those lines... But ideally we'd want a single
solution... We've been working like this for 15 years, it would suck to
change the mentality :)

Alex.

[Sin]

> I agree. I'm sure MS could fix this particular problem right now if they

would only release a service pack for the VS IDE. There are many other such 'niggles' that they are definitely aware of and which they must surely have a fix for by now.
I guess we can keep dreaming... VB6 had the same problem and it never got
fixed after years and years of service packs... In VB6 if you had a EXE
project and a ActiveX DLL project and switched from one to the other the DLL
would stay locked and you'd need to close and re-open VB to recompile the
DLL.... Extremely annoying when you're working on BOTH.....

One other consideration that may improve the situation: have a look at the
linkage of your projects within the solution. I find that the problem is
greater when there is tight coupling and low cohesion. I have resolved this issue on occasions by refactoring my solution to reduce the amount of
coupling between projects.

I'll keep that in mind..... My boss is the lead designer and I'll see with
him what opions he wants to go with. As far as I'm concerned all 47 projects
could easily be merged in 2 projects (1 C++/COM, 1 VB) but he's been working
with separate projects for 15+ years... The objects are actually plugins to
the main application but there are really just final release 2
configurations (a normal and a pro version of the product, the pro version
includes all plugins while the normal version only has a subset of them).

Merging them would eliminate 45 potential sources of the error we're
having... hehe... It would certainly help.

Thanks for the input....

Alex.

[Sin]

> I agree. I'm sure MS could fix this particular problem right now if they

would only release a service pack for the VS IDE. There are many other such 'niggles' that they are definitely aware of and which they must surely have a fix for by now.
I guess we can keep dreaming... VB6 had the same problem and it never got
fixed after years and years of service packs... In VB6 if you had a EXE
project and a ActiveX DLL project and switched from one to the other the DLL
would stay locked and you'd need to close and re-open VB to recompile the
DLL.... Extremely annoying when you're working on BOTH.....

One other consideration that may improve the situation: have a look at the
linkage of your projects within the solution. I find that the problem is
greater when there is tight coupling and low cohesion. I have resolved this issue on occasions by refactoring my solution to reduce the amount of
coupling between projects.

I'll keep that in mind..... My boss is the lead designer and I'll see with
him what opions he wants to go with. As far as I'm concerned all 47 projects
could easily be merged in 2 projects (1 C++/COM, 1 VB) but he's been working
with separate projects for 15+ years... The objects are actually plugins to
the main application but there are really just final release 2
configurations (a normal and a pro version of the product, the pro version
includes all plugins while the normal version only has a subset of them).

Merging them would eliminate 45 potential sources of the error we're
having... hehe... It would certainly help.

Thanks for the input....

Alex.

[Sin]

> I find that closing all the open source files SOMETIMES clears it.

I use DotNet 1.1 & C#.

Doesn't change a thing here... In fact I rarely compile with any documents
open.

Alex.

[Sin]

> I find that closing all the open source files SOMETIMES clears it.

I use DotNet 1.1 & C#.

Doesn't change a thing here... In fact I rarely compile with any documents
open.

Alex.

[TomG]

Have you tried deleting the files in the bin directory prior to compiling?

[TomG]

Have you tried deleting the files in the bin directory prior to compiling?

[Sin]

> Have you tried deleting the files in the bin directory prior to compiling?

For some reason the problem has lessenend after some changes to the
solution/project configs... I can usually fix the problem by simply
restarting VS now.. when that doesn't work I need to flush the bin and debug
dirs...... Haven't had to reboot yet...

It's still a very annoying bug and it cost be alot of time this week. Damn
thing....

Alex.

[Sin]

> Have you tried deleting the files in the bin directory prior to compiling?

For some reason the problem has lessenend after some changes to the
solution/project configs... I can usually fix the problem by simply
restarting VS now.. when that doesn't work I need to flush the bin and debug
dirs...... Haven't had to reboot yet...

It's still a very annoying bug and it cost be alot of time this week. Damn
thing....

Alex.