vss和visual studio 2003的问题 [英] Problem with vss and visual studio 2003

问题描述

我们在2003年有一个Web应用程序。该解决方案包含用于Web应用程序的项目

和用于共享程序集的其他五个项目。

我们有两个问题。


首先，我们要将整个解决方案放在其他

目录中，例如c：\ work而不是wwwroot。我们可以使用vss来获取最新版本的b $ b，但是只要我们从visual

studio中打开解决方案，vs将主要的web应用程序源文件复制到新的

inetpub / wwwroot / projectname目录下的wwwroot。我们想要的是wwwroot中的一个

虚拟目录，但是其他地方的文件。这是
导致我们出现问题，因为我们现在拥有该项目中所有源

文件的两个副本，c：\ work区域中有一个副本，另一个副本位于

wwwroot /项目名称区域。奇怪的是，我们之前已经能够完成这项工作，但现在不能。知道什么是错的吗？我们已经删除了vscache目录并确保绑定正确。

我们还确保在vss中正确设置目录。任何

想法？


第二个问题是这个解决方案不再干净地构建。

有时我们可以正确构建单个项目。但如果你重建整个解决方案，那么它就会失败。它告诉我们它不能写出输出到工作目录的
，因为DLL文件被另一个进程锁定了

。在这种情况下，我们知道其他过程是视觉上的b $ b $ studio。并且有问题的DLL实际构建。它就像它构建，

然后不释放DLL上的锁，然后尝试再次构建它

遇到错误。一个线索可能是我们开始遇到问题当我们将所有项目构建到一个共同的

目录时，这是一个来自构建/部署部门的愚蠢策略。没有

的文件名是相同的，所以这不应该是一个问题。

并且所有东西都是从其他部门正确构建的

命令行实用程序。知道这个是怎么回事吗？


brian

We have a web application in 2003. The solution contains the project
for the web application and five other projects for shared assemblies.
We have two issues.

The first is that we want to place the entire solution in some other
directory like c:\work rather than wwwroot. We can use vss to do a get
latest version, but as soon as we open the solution from within visual
studio, vs copies the main web application source files to a new
inetpub/wwwroot/projectname directory under wwwroot. What we want is a
virtual directory in wwwroot, but the files somewhere else. This is
causing us a problem because we now have two copies of all the source
files in that project, one copy in the c:\work area and another in the
wwwroot/project name area. The weird thing is that we''ve been able to
make this work before, but can''t now. Any idea what''s wrong? We''ve
deleted the vscache directory and made sure the bindings are correct.
We''ve also made sure the directories are set correctly in vss. Any
ideas?

The second problem is that this solution no longer cleanly builds.
Somtimes we can build individual projects correctly. But if you
rebuild the entire solution, it fails. It tells us that it can''t write
the output to the working directory because the DLL file is locked by
another process. In this case, we know the other process is visual
studio. And the DLL in question actually builds. It''s like it builds,
then doesn''t release the lock on the DLL, then tries to build it again
encountering the error. One clue may be that we started to encounter
problems when we directed all the projects to build to a common
directory, a stupid policy from the build/deployment department. None
of the file names are the same though so this shouldn''t be an issue.
And everything builds correctly for the other department from their
command line utility. Any idea what''s going on with this one?

brian

推荐答案

你不能创建一个指向你的c：\驱动器的虚拟目录吗？当你

指定你的虚拟站点指向wwwroot下的某些东西时，它会将这些文件放在其下面。但是，如果您指定虚拟站点指向

到c：\<文件夹名称，希望它应该可以工作。

-

Ameet Phadnis

Sr.技术顾问
$ b $是Tek Global Inc.

ASP联盟作者页面： http://aspalliance.com/author.aspx?uId=44260

" brianlanning" ;写道：

Can''t you create a virtual directory pointing to your c:\ drive? When you
specify your virtual site pointing to something under wwwroot it is going to
put those files underneath that. But if you specify the virtual site to point
to c:\<folder namethen hopefully it should work.
--
Ameet Phadnis
Sr. Technical Consultant
e Tek Global Inc.
ASP Alliance Author Page: http://aspalliance.com/author.aspx?uId=44260
"brianlanning" wrote:

我们在2003年有一个Web应用程序。该解决方案包含用于Web应用程序的项目

和用于共享程序集的其他五个项目。

我们有两个问题。


首先，我们要将整个解决方案放在其他一些

目录中c：\ work而不是wwwroot。我们可以使用vss来获取最新版本的b $ b，但是只要我们从visual

studio中打开解决方案，vs将主要的web应用程序源文件复制到新的

inetpub / wwwroot / projectname目录下的wwwroot。我们想要的是wwwroot中的一个

虚拟目录，但是其他地方的文件。这是
导致我们出现问题，因为我们现在拥有该项目中所有源

文件的两个副本，c：\ work区域中有一个副本，另一个副本位于

wwwroot /项目名称区域。奇怪的是，我们之前已经能够完成这项工作，但现在不能。知道什么是错的吗？我们已经删除了vscache目录并确保绑定正确。

我们还确保在vss中正确设置目录。任何

想法？


第二个问题是这个解决方案不再干净地构建。

有时我们可以正确构建单个项目。但如果你重建整个解决方案，那么它就会失败。它告诉我们它不能写出输出到工作目录的
，因为DLL文件被另一个进程锁定了

。在这种情况下，我们知道其他过程是视觉上的b $ b $ studio。并且有问题的DLL实际构建。它就像它构建，

然后不释放DLL上的锁，然后尝试再次构建它

遇到错误。一个线索可能是我们开始遇到问题当我们将所有项目构建到一个共同的

目录时，这是一个来自构建/部署部门的愚蠢策略。没有

的文件名是相同的，所以这不应该是一个问题。

并且所有东西都是从其他部门正确构建的

命令行实用程序。知道这个是怎么回事吗？


brian

We have a web application in 2003. The solution contains the project
for the web application and five other projects for shared assemblies.
We have two issues.

The first is that we want to place the entire solution in some other
directory like c:\work rather than wwwroot. We can use vss to do a get
latest version, but as soon as we open the solution from within visual
studio, vs copies the main web application source files to a new
inetpub/wwwroot/projectname directory under wwwroot. What we want is a
virtual directory in wwwroot, but the files somewhere else. This is
causing us a problem because we now have two copies of all the source
files in that project, one copy in the c:\work area and another in the
wwwroot/project name area. The weird thing is that we''ve been able to
make this work before, but can''t now. Any idea what''s wrong? We''ve
deleted the vscache directory and made sure the bindings are correct.
We''ve also made sure the directories are set correctly in vss. Any
ideas?

The second problem is that this solution no longer cleanly builds.
Somtimes we can build individual projects correctly. But if you
rebuild the entire solution, it fails. It tells us that it can''t write
the output to the working directory because the DLL file is locked by
another process. In this case, we know the other process is visual
studio. And the DLL in question actually builds. It''s like it builds,
then doesn''t release the lock on the DLL, then tries to build it again
encountering the error. One clue may be that we started to encounter
problems when we directed all the projects to build to a common
directory, a stupid policy from the build/deployment department. None
of the file names are the same though so this shouldn''t be an issue.
And everything builds correctly for the other department from their
command line utility. Any idea what''s going on with this one?

brian

1。从你的inetpub目录中删除你的项目主管（进行备份

复制这个文件夹，如果你的代码更改存储在这里）


假设我们的项目是在C：\ MyCompnay \Projects \ MyWebApp

2.打开窗口浏览器转到C：\ Inetpub / wwwroot /并创建相同的

目录结构如上所示

如下所示C：\Inetpub / wwwroot \ MyCompany \Projects \


3.打开IIS MMC导航到C：\Inetpub / wwwroot \ MyCompany \Projects \和

创建新的虚拟目录并将其称为与webApp相同

所以它将是C：\\ \\ inetpub / wwwroot \ MyCompany \Projects\WebApp（Virtual

目录）并将其映射到C：\ MyCompnay \Projects \ MyWebApp


4.在notpad中打开你的project.webinfo文件并确保它指向

正确的位置。


5.打开你的解决方案，删除你的卷筒纸项目，然后从C：\ MyPnay \Projects \ MyWebApp添加你的网络项目

，它可能是

问你的http路径指向哪里
http：// localhost / MyCompany / Projects / WebApp

至于你的第二个问题是关注，


这是已知的问题，它可能有助于阻止你的索引服务。


或

杀死你的aspnet_wp.exe进程并试一试


或


关闭并重新打开你的解决方案吧将编译没有任何问题。


谢谢

Baski

" brianlanning" < br ********** @ gmail.com写信息

新闻：11 ******************** **@b28g2000cwb.googlegr oups.com ...

1. Delete your project director from your inetpub directory ( make a backup
copy this folder , if incase your code changes are stored here )

Assume your we projects are under C:\MyCompnay\Projects\MyWebApp

2. Open window explorer go to C:\Inetpub/wwwroot/ and create the same
directory structre like above
as show below C:\Inetpub/wwwroot\MyCompany\Projects\

3. Open IIS MMC navigate to C:\Inetpub/wwwroot\MyCompany\Projects\ and
create new virtual directory and call it same as your webApp
so it will be C:\Inetpub/wwwroot\MyCompany\Projects\WebApp(Virtual
directory) and map it to C:\MyCompnay\Projects\MyWebApp

4. open your project.webinfo file in notpad and make sure it points to the
right place.

5.Open your solution, remove your web project and then add your web project
from C:\MyCompnay\Projects\MyWebApp, it might
ask where is your http path poin to
http://localhost/MyCompany/Projects/WebApp
as far as your second question is concern,

It''s known issue, it may help stop your indexing service .

or
kill your aspnet_wp.exe process and give it a shot

or

close and reopen your solution it will compile without any problem.

Thanks
Baski
"brianlanning" <br**********@gmail.comwrote in message
news:11**********************@b28g2000cwb.googlegr oups.com...

我们在2003年有一个Web应用程序。该解决方案包含项目

for Web应用程序和其他五个共享程序集项目。

我们有两个问题。


首先，我们要将整个解决方案放在其他一些

目录如c：\ work而不是wwwroot。我们可以使用vss来获取最新版本的b $ b，但是只要我们从visual

studio中打开解决方案，vs将主要的web应用程序源文件复制到新的

inetpub / wwwroot / projectname目录下的wwwroot。我们想要的是wwwroot中的一个

虚拟目录，但是其他地方的文件。这是
导致我们出现问题，因为我们现在拥有该项目中所有源

文件的两个副本，c：\ work区域中有一个副本，另一个副本位于

wwwroot /项目名称区域。奇怪的是，我们之前已经能够完成这项工作，但现在不能。知道什么是错的吗？我们已经删除了vscache目录并确保绑定正确。

我们还确保在vss中正确设置目录。任何

想法？


第二个问题是这个解决方案不再干净地构建。

有时我们可以正确构建单个项目。但如果你重建整个解决方案，那么它就会失败。它告诉我们它不能写出输出到工作目录的
，因为DLL文件被另一个进程锁定了

。在这种情况下，我们知道其他过程是视觉上的b $ b $ studio。并且有问题的DLL实际构建。它就像它构建，

然后不释放DLL上的锁，然后尝试再次构建它

遇到错误。一个线索可能是我们开始遇到问题当我们将所有项目构建到一个共同的

目录时，这是一个来自构建/部署部门的愚蠢策略。没有

的文件名是相同的，所以这不应该是一个问题。

并且所有东西都是从其他部门正确构建的

命令行实用程序。知道这个是怎么回事吗？


brian

We have a web application in 2003. The solution contains the project
for the web application and five other projects for shared assemblies.
We have two issues.

The first is that we want to place the entire solution in some other
directory like c:\work rather than wwwroot. We can use vss to do a get
latest version, but as soon as we open the solution from within visual
studio, vs copies the main web application source files to a new
inetpub/wwwroot/projectname directory under wwwroot. What we want is a
virtual directory in wwwroot, but the files somewhere else. This is
causing us a problem because we now have two copies of all the source
files in that project, one copy in the c:\work area and another in the
wwwroot/project name area. The weird thing is that we''ve been able to
make this work before, but can''t now. Any idea what''s wrong? We''ve
deleted the vscache directory and made sure the bindings are correct.
We''ve also made sure the directories are set correctly in vss. Any
ideas?

The second problem is that this solution no longer cleanly builds.
Somtimes we can build individual projects correctly. But if you
rebuild the entire solution, it fails. It tells us that it can''t write
the output to the working directory because the DLL file is locked by
another process. In this case, we know the other process is visual
studio. And the DLL in question actually builds. It''s like it builds,
then doesn''t release the lock on the DLL, then tries to build it again
encountering the error. One clue may be that we started to encounter
problems when we directed all the projects to build to a common
directory, a stupid policy from the build/deployment department. None
of the file names are the same though so this shouldn''t be an issue.
And everything builds correctly for the other department from their
command line utility. Any idea what''s going on with this one?

brian

1。删除所有locall

2.下载整棵树

3.在Windows资源管理器中，转到网页目录的属性并制作一个

web应用程序（也可以在IIS管理器中完成）

4.删除网络目录中的所有文件。

5.打开解决方案文件

6.它现在将使用网络文件填充新目录

7.流行打开冷淡的成人饮料并放松


-

Gregory A. Beamer

MVP; MCP：+ I，SE，SD，DBA
http：//gregorybeamer.spaces。 live.com


******************************* ******************

在盒子外面思考！

********** *******************************************

" brianlanning" ; < br ********** @ gmail.com写信息

新闻：11 ******************** **@b28g2000cwb.googlegr oups.com ...

1. Delete everything locall
2. Download the entire tree
3. In windows explorer, go to properties for the web directory and make a
web app (can also be done in IIS manager)
4. Delete all files from the web directory.
5. Open the solution file
6. It will now populate the new directory with the web files
7. Pop open a frosty adult beverage and relax

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA
http://gregorybeamer.spaces.live.com

*************************************************
Think outside of the box!
*************************************************
"brianlanning" <br**********@gmail.comwrote in message
news:11**********************@b28g2000cwb.googlegr oups.com...

我们在2003年有一个Web应用程序。该解决方案包含项目

for Web应用程序和其他五个共享程序集项目。

我们有两个问题。


首先，我们要将整个解决方案放在其他一些

目录如c：\ work而不是wwwroot。我们可以使用vss来获取最新版本的b $ b，但是只要我们从visual

studio中打开解决方案，vs将主要的web应用程序源文件复制到新的

inetpub / wwwroot / projectname目录下的wwwroot。我们想要的是wwwroot中的一个

虚拟目录，但是其他地方的文件。这是
导致我们出现问题，因为我们现在拥有该项目中所有源

文件的两个副本，c：\ work区域中有一个副本，另一个副本位于

wwwroot /项目名称区域。奇怪的是，我们之前已经能够完成这项工作，但现在不能。知道什么是错的吗？我们已经删除了vscache目录并确保绑定正确。

我们还确保在vss中正确设置目录。任何

想法？


第二个问题是这个解决方案不再干净地构建。

有时我们可以正确构建单个项目。但如果你重建整个解决方案，那么它就会失败。它告诉我们它不能写出输出到工作目录的
，因为DLL文件被另一个进程锁定了

。在这种情况下，我们知道其他过程是视觉上的b $ b $ studio。并且有问题的DLL实际构建。它就像它构建，

然后不释放DLL上的锁，然后尝试再次构建它

遇到错误。一个线索可能是我们开始遇到问题当我们将所有项目构建到一个共同的

目录时，这是一个来自构建/部署部门的愚蠢策略。没有

的文件名是相同的，所以这不应该是一个问题。

并且所有东西都是从其他部门正确构建的

命令行实用程序。知道这个是怎么回事吗？


brian

We have a web application in 2003. The solution contains the project
for the web application and five other projects for shared assemblies.
We have two issues.

The first is that we want to place the entire solution in some other
directory like c:\work rather than wwwroot. We can use vss to do a get
latest version, but as soon as we open the solution from within visual
studio, vs copies the main web application source files to a new
inetpub/wwwroot/projectname directory under wwwroot. What we want is a
virtual directory in wwwroot, but the files somewhere else. This is
causing us a problem because we now have two copies of all the source
files in that project, one copy in the c:\work area and another in the
wwwroot/project name area. The weird thing is that we''ve been able to
make this work before, but can''t now. Any idea what''s wrong? We''ve
deleted the vscache directory and made sure the bindings are correct.
We''ve also made sure the directories are set correctly in vss. Any
ideas?

The second problem is that this solution no longer cleanly builds.
Somtimes we can build individual projects correctly. But if you
rebuild the entire solution, it fails. It tells us that it can''t write
the output to the working directory because the DLL file is locked by
another process. In this case, we know the other process is visual
studio. And the DLL in question actually builds. It''s like it builds,
then doesn''t release the lock on the DLL, then tries to build it again
encountering the error. One clue may be that we started to encounter
problems when we directed all the projects to build to a common
directory, a stupid policy from the build/deployment department. None
of the file names are the same though so this shouldn''t be an issue.
And everything builds correctly for the other department from their
command line utility. Any idea what''s going on with this one?

brian

这篇关于vss和visual studio 2003的问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！