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.
14  1666 
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.
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.
> 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.
> 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.
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.
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.
> 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.
> 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.
> 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.
> 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.
Have you tried deleting the files in the bin directory prior to compiling?
Have you tried deleting the files in the bin directory prior to compiling?
> 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.
> 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.
This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Corne' Cornelius |
last post by:
Hi,
When you open a file for writing/appending with open() or fopen(), and
you have multiple applications that might want to write to the same file
at the same time, could that cause weirdness...
|
by: McFly Racing |
last post by:
Thread Locking In Static Methods
I have the need for a Log Manger class that has static methods. Normally I
would use the lock statement or a Monitor statement both of which take a...
|
by: Sin |
last post by:
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)...
|
by: Eric S. Johansson |
last post by:
are there any simple examples of how to do record locking with bsddb3?
the bsddb3 documentation is reasonably opaque. For example, the DB
initialization requires a DBEnv instance for certain...
|
by: George |
last post by:
Hi,
I am re-writing part of my application using C#. This application starts
another process which execute a "legacy" program. This legacy program writes
to a log file and before it ends, it...
|
by: shineofleo |
last post by:
Here is the situation: I wrote a VB programm, which stores all the
information in a single Access database file using jet engine. It
worked well, however one of my customs reported that there was...
|
by: Matt Brandt |
last post by:
I am trying to get multiple threads to lock specific regions of a file.
However, since each thread has the same PID, it appears that a lock by
one thread does not block another thread from the same...
|
by: Don |
last post by:
I wrote an app that alerts a user who attempts to open a file that the
file is currently in use. It works fine except when the file is
opened by Notepad. If a text file is opened, most computers...
|
by: Bill H |
last post by:
I am wondering if this is possible. I have a file that is accessed by
multiple users and keeps track of activity (the file is polled by
flash every 2 seconds). As users leave, the flash program...
|
by: taylorcarr |
last post by:
A Canon printer is a smart device known for being advanced, efficient, and reliable. It is designed for home, office, and hybrid workspace use and can also be used for a variety of purposes. However,...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: aa123db |
last post by:
Variable and constants
Use var or let for variables and const fror constants.
Var foo ='bar';
Let foo ='bar';const baz ='bar';
Functions
function $name$ ($parameters$) {
}
...
|
by: ryjfgjl |
last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
| |
