By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,364 Members | 1,272 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,364 IT Pros & Developers. It's quick & easy.

Problem with vss and visual studio 2003

P: n/a
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

Oct 6 '06 #1
Share this Question
Share on Google+
11 Replies


P: n/a
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:
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

Oct 6 '06 #2

P: n/a
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...
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

Oct 6 '06 #3

P: n/a
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...
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

Oct 6 '06 #4

P: n/a

//directory like c:\work rather than wwwroot.//

You can do this, but I'd strongly suggest ~~everyone has to use the same
one. No exceptions.

The magic is opening up and looking in notepad the .webinfo file.

The info in there has to match where the virtual directory is. You can
manually fix this as necessary.

The reason that c:\inetpub\wwwroot\ works is that everybody has it.

IF all developers use the same alternate directory
c:\work
AND
you create a virtual directory
http://localhost/work/ that points to c:\work\

and before checking files in, make sure the .webinfo is correct

then you can with this in an multiuser environment.

The key is that when developer2 checks out a project that developer1
started, all the stars need to align.

Or else developer2's version of .webinfo is off, and thus VS2003 tries to
auto create the virutal directory for them, in that "_1" style.

how do I know this? Cuz I used to work with a guy who started all projects,
and didn't attempt to synchronize, and causes huge headaches for me and my
ability to produce. And when I checked stuff back in , he'd rat out to my
boss "He broke the build after checking stuff back in".

Individuality is good, but not when it comes to VS2003 and VSS.

...


"brianlanning" <br**********@gmail.comwrote in message
news:11**********************@b28g2000cwb.googlegr oups.com...
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

Oct 6 '06 #5

P: n/a

Baski wrote:
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
Ah! I have no webinfo file in source safe. Maybe it's recreating one
incorrectly which is the source of the confusion?

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.
I'll try the first one once I get the project back together. The other
two didn't help.

thanks

brian

Oct 6 '06 #6

P: n/a
wbeinfo is just simple file

<VisualStudioUNCWeb>
<Web URLPath = "http://localhost/subdirectory/your web project
name.csproj" />
</VisualStudioUNCWeb>

save the above content as your web project name.csproj.webinfo

"brianlanning" <br**********@gmail.comwrote in message
news:11**********************@m7g2000cwm.googlegro ups.com...
>
Baski wrote:
>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

Ah! I have no webinfo file in source safe. Maybe it's recreating one
incorrectly which is the source of the confusion?

>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.

I'll try the first one once I get the project back together. The other
two didn't help.

thanks

brian

Oct 6 '06 #7

P: n/a
(i'm really replying to everyone)

So I create all of this. I have the entire tree in c:\work.

The project and solution file are here:

c:\work\fleetsynergy\websource\fleetsynergyimport\ FleetSynergyImport.csproj
(and sln)

The .webinfo file looks like this:

<VisualStudioUNCWeb>
<Web URLPath =
"http://localhost/work/fleetsynergy/websource/fleetsynergyimport/FleetSynergyImport.csproj"
/>
</VisualStudioUNCWeb>

I place the webinfo file in sourcesafe with the other project files. I
created a virtual directory that links http://localhost/work to
c:\work.

When I try to open the solution, I get a dialog that says "Set Project
Location". The text says that I need to set the working directory for
the project. The default is http://localhost/fleetsynergy which is
exactly where I don't want it. So I change the path to point to the
direcory containing the project, like this:

http://localhost/work/fleetsynergy/w...tSynergyImport

It underlines the path in red, then tells me that I have to choose a
different path because this directory already contains a web project
(duh).

So what now?

brian

sloan wrote:
//directory like c:\work rather than wwwroot.//

You can do this, but I'd strongly suggest ~~everyone has to use the same
one. No exceptions.

The magic is opening up and looking in notepad the .webinfo file.

The info in there has to match where the virtual directory is. You can
manually fix this as necessary.

The reason that c:\inetpub\wwwroot\ works is that everybody has it.

IF all developers use the same alternate directory
c:\work
AND
you create a virtual directory
http://localhost/work/ that points to c:\work\

and before checking files in, make sure the .webinfo is correct

then you can with this in an multiuser environment.

The key is that when developer2 checks out a project that developer1
started, all the stars need to align.

Or else developer2's version of .webinfo is off, and thus VS2003 tries to
auto create the virutal directory for them, in that "_1" style.

how do I know this? Cuz I used to work with a guy who started all projects,
and didn't attempt to synchronize, and causes huge headaches for me and my
ability to produce. And when I checked stuff back in , he'd rat out to my
boss "He broke the build after checking stuff back in".

Individuality is good, but not when it comes to VS2003 and VSS.

..


"brianlanning" <br**********@gmail.comwrote in message
news:11**********************@b28g2000cwb.googlegr oups.com...
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
Oct 6 '06 #8

P: n/a
When I try to open the solution, I get a dialog that says "Set Project
Location". The text says that I need to set the working directory for
the project. The default is http://localhost/fleetsynergy which is
exactly where I don't want it. So I change the path to point to the
direcory containing the project, like this:
When it ask for working directory select your
c:\work\fleetsynergy\websource\fleetsynergyimport\
<br**********@gmail.comwrote in message
news:11*********************@b28g2000cwb.googlegro ups.com...
(i'm really replying to everyone)

So I create all of this. I have the entire tree in c:\work.

The project and solution file are here:

c:\work\fleetsynergy\websource\fleetsynergyimport\ FleetSynergyImport.csproj
(and sln)

The .webinfo file looks like this:

<VisualStudioUNCWeb>
<Web URLPath =
"http://localhost/work/fleetsynergy/websource/fleetsynergyimport/FleetSynergyImport.csproj"
/>
</VisualStudioUNCWeb>

I place the webinfo file in sourcesafe with the other project files. I
created a virtual directory that links http://localhost/work to
c:\work.

When I try to open the solution, I get a dialog that says "Set Project
Location". The text says that I need to set the working directory for
the project. The default is http://localhost/fleetsynergy which is
exactly where I don't want it. So I change the path to point to the
direcory containing the project, like this:

http://localhost/work/fleetsynergy/w...tSynergyImport

It underlines the path in red, then tells me that I have to choose a
different path because this directory already contains a web project
(duh).

So what now?

brian

sloan wrote:
>//directory like c:\work rather than wwwroot.//

You can do this, but I'd strongly suggest ~~everyone has to use the same
one. No exceptions.

The magic is opening up and looking in notepad the .webinfo file.

The info in there has to match where the virtual directory is. You can
manually fix this as necessary.

The reason that c:\inetpub\wwwroot\ works is that everybody has it.

IF all developers use the same alternate directory
c:\work
AND
you create a virtual directory
http://localhost/work/ that points to c:\work\

and before checking files in, make sure the .webinfo is correct

then you can with this in an multiuser environment.

The key is that when developer2 checks out a project that developer1
started, all the stars need to align.

Or else developer2's version of .webinfo is off, and thus VS2003 tries to
auto create the virutal directory for them, in that "_1" style.

how do I know this? Cuz I used to work with a guy who started all
projects,
and didn't attempt to synchronize, and causes huge headaches for me and
my
ability to produce. And when I checked stuff back in , he'd rat out to
my
boss "He broke the build after checking stuff back in".

Individuality is good, but not when it comes to VS2003 and VSS.

..


"brianlanning" <br**********@gmail.comwrote in message
news:11**********************@b28g2000cwb.googleg roups.com...
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

Oct 6 '06 #9

P: n/a
Baski wrote:
When it ask for working directory select your
c:\work\fleetsynergy\websource\fleetsynergyimport\

But it wants a url. When I enter the url directly like I posted, I
get that error message about a project already being there. If I click
the browse elipsis, I get an empty window that doesn't contain anything
on the localhost web server. If I choose the working directory in the
tree, it says it wants a url.

brian

Oct 6 '06 #10

P: n/a
Ok here is something weired, close everything , delet your soultion .suo
file and reope the soultion.

"brianlanning" <br**********@gmail.comwrote in message
news:11**********************@i3g2000cwc.googlegro ups.com...
Baski wrote:
>When it ask for working directory select your
c:\work\fleetsynergy\websource\fleetsynergyimport \


But it wants a url. When I enter the url directly like I posted, I
get that error message about a project already being there. If I click
the browse elipsis, I get an empty window that doesn't contain anything
on the localhost web server. If I choose the working directory in the
tree, it says it wants a url.

brian

Oct 6 '06 #11

P: n/a
Baski wrote:
Ok here is something weired, close everything , delet your soultion .suo
file and reope the soultion.
It looks like that did it, deleting the suo file. It looks like a lot
of references are out of whack though so it need some work. Thanks for
your help.

brian

Oct 6 '06 #12

This discussion thread is closed

Replies have been disabled for this discussion.