VS.NET文件锁定问题：完全搞砸了 [英] VS.NET file locking problem : Totally screwed
问题描述
我已经尝试了一切，我得出的结论是，我搞砸了。如果
任何人都可以提供帮助，我会非常满意。
我有一个有47个项目的解决方案..这包括（非常粗略）：
1-普通win32 C ++ DLL项目（一点一点，简称为BASE
OBJECTS）
2- ATL / COM / C ++ DLL使用普通的win32 DLL（另外打了几个，提到了
作为COM WRAPPERS）
3- VB.NET界面暴露使用ATL / COM
DLL的COM类的项目。 （另外打，称为VB GUI）
4-其中一个基础对象由所有其他对象共享，同一个对象的
包装器也是共享的，它也是VB的gui项目。这个组件是
被称为KERNEL。
5-主要应用程序是VB.NET并使用VB GUI项目
所有项目都输出到同一目录......在你跳转之前，
我已经尝试将所有项目输出到不同的目录和
问题仍然存在，所以还有别的东西，我认为它与COM有关。
所以你现在可能已经猜到了，每次我做一个在这个
解决方案上构建/重建，有几个项目不能编译因为我得到
无法访问文件，因为它被锁定了另一个过程或类似的
消息（实际上有3个不同的消息，都与锁定的
DLL有关）。
任何时候发生这种情况，内核的包装器通常是那些有b / b $ b问题的包装器，但它的VB gui也会不时引起问题。还有2
其他包装纸几乎总是在那里，但我不知道为什么
它们的构建方式与其他包装方式相同，并且使用方式也不同。
当发生这种情况时，我需要删除调试目录的所有内容，
关闭VC，通常甚至重启以解决问题。这是非常好的
。
所有这些项目的输出都大于KB中提到的64K
文章。
我完全迷失了......我怎样才能做到这一点？
提前致谢...如果你有关于此的任何提示，请回复...
此时我很愿意尝试伏都教，weejaa和其他任何可能有帮助的技巧。
Alex。
你好Alex
对于项目少得多的解决方案，我遇到了类似的问题。您是否需要
同时处理所有项目？我的意思是你可以建立一些核心项目，或者一些全球引用的项目，然后
然后从解决方案中删除它们？其余的项目仍然可以参考内置的dll，但它们不会每次都重建。它还可以加快解决方案的构建速度。
HTH
Charles
" Sin" <峰; br **** @ hotmail.com>在消息中写道
新闻：O5 ************** @ TK2MSFTNGP12.phx.gbl ...我试过了一切，我得出结论，我搞砸了。如果有人可以提供帮助，我会非常满意。
我有一个有47个项目的解决方案..这包括（非常粗略）
：
1 - 普通的win32 C ++ DLL项目（一点一点，称为BASE
OBJECTS）
2- ATL / COM / C ++ DLL使用普通的win32 DLL（另外十二个，引用
作为COM WRAPPERS）
3- VB.NET接口项目公开使用ATL / COM
DLL的COM类。 （另外十几个，称为VB GUI）
4-其中一个基础对象由所有其他对象共享，同一对象的
包装器也是共享的，因此它也是如此'VB gui项目。这个组件被称为KERNEL。
5-主要应用程序是VB.NET并使用VB GUI项目
所有项目都被输出到相同的目录...在你跳到
之前，我已经尝试将所有这些输出到不同的目录而
问题仍然存在，所以还有别的东西，我认为它是相关的到
COM。
所以你现在可能已经猜到了，每次我在
这个解决方案上进行构建/重建时，有几个项目都不会编译，因为我得到
无法访问文件，因为它已被另一个进程锁定或类似的消息（实际上有3个不同的，都与锁定的
DLL有关）。
任何时候发生这种情况，内核的包装通常是其中一个
问题，但它的VB gui也不时引起问题。还有
2其他包装器几乎总是在那里，但我不知道为什么
，因为它们的构建方式和其他的一样，并且也没有区别。
当发生这种情况时我需要删除我的debug
目录的所有内容，关闭VC，通常甚至重启以解决问题。它正在获得
极其苛刻。
所有这些项目的输出都比KB
文章中提到的64K更大。
我完全迷失了......我怎么能做到这一点呢？
提前致谢...如果你有关于
的任何提示，请回复...这个我愿意尝试伏都教，weejaa和任何其他可能有帮助的技巧。
Alex。
嗨Alex
我遇到类似问题的解决方案项目少得多。您是否需要
同时处理所有项目？我的意思是你可以建立一些核心项目，或者一些全球引用的项目，然后
然后从解决方案中删除它们？其余的项目仍然可以参考内置的dll，但它们不会每次都重建。它还可以加快解决方案的构建速度。
HTH
Charles
" Sin" <峰; br **** @ hotmail.com>在消息中写道
新闻：O5 ************** @ TK2MSFTNGP12.phx.gbl ...我试过了一切，我得出结论，我搞砸了。如果有人可以提供帮助，我会非常满意。
我有一个有47个项目的解决方案..这包括（非常粗略）
：
1 - 普通的win32 C ++ DLL项目（一点一点，称为BASE
OBJECTS）
2- ATL / COM / C ++ DLL使用普通的win32 DLL（另外十二个，引用
作为COM WRAPPERS）
3- VB.NET接口项目公开使用ATL / COM
DLL的COM类。 （另外十几个，称为VB GUI）
4-其中一个基础对象由所有其他对象共享，同一对象的
包装器也是共享的，因此它也是如此'VB gui项目。这个组件被称为KERNEL。
5-主要应用程序是VB.NET并使用VB GUI项目
所有项目都被输出到相同的目录...在你跳到
之前，我已经尝试将所有这些输出到不同的目录而
问题仍然存在，所以还有别的东西，我认为它是相关的到
COM。
所以你现在可能已经猜到了，每次我在
这个解决方案上进行构建/重建时，有几个项目都不会编译，因为我得到
无法访问文件，因为它已被另一个进程锁定或类似的消息（实际上有3个不同的，都与锁定的
DLL有关）。
任何时候发生这种情况，内核的包装通常是其中一个
问题，但它的VB gui也不时引起问题。还有
2其他包装器几乎总是在那里，但我不知道为什么
，因为它们的构建方式和其他的一样，并且也没有区别。
当发生这种情况时我需要删除我的debug
目录的所有内容，关闭VC，通常甚至重启以解决问题。它正在获得
极其苛刻。
所有这些项目的输出都比KB
文章中提到的64K更大。
我完全迷失了......我怎么能做到这一点呢？
提前致谢...如果你有关于
的任何提示，请回复...这个我愿意尝试伏都教，weejaa和任何其他可能有帮助的技巧。
Alex。
>对于项目少得多的解决方案，我遇到了类似的问题。你是否需要来同时处理所有项目？我的意思是你可以
构建一些核心项目，或者一些全球引用的项目，
然后从解决方案中删除它们？其余的项目仍然可以参考内置的dll，但每次都不会重建。它还可以加快解决方案的构建速度。
大部分时间我们都会处理其中一个对象（即：基础对象，
它的包装，它的界面）......确实你的解决方案可行，
别担心我们已经虽然关于它，但理想情况下我们想要一个解决方案
我们可以在不打开几十个解决方案的情况下构建我们的所有项目...
有没有办法从命令行编译解决方案？我想如果我们
那么我们就可以有一个批处理文件来编译所有我们的解决方案时需要
....
我的想法是让事情变得容易......我经常会发生这样的事情：我需要刷新我的整个项目目录并用备份替换它（更新的
版本来自我的同事）然后重新编译所有...
另一个问题是调试......我需要能够调试所有项目
没有从解决方案切换到另一个。请注意，这就是
我现在甚至无法做到......似乎我无法从VB转到C .......
我会按照这些方法进行试验......但理想情况下我们需要一个单一的
解决方案......我们已经这样工作了15年，它会很糟糕
改变心态:)
Alex。
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.
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
needto 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.
这篇关于VS.NET文件锁定问题：完全搞砸了的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
