checking in .net website after a rebind to fortress
Moderator: SourceGear
checking in .net website after a rebind to fortress
I'll describe the steps to put question/issue in context:
1. successfully rebind a solution from vault 3.5 to fortress within visual studio.
2. rebuild a website within the solution, containing several assembly references. e.g. class.dll.refresh files in the bin directory under source control.
previously, in vault 3.5, the project check in would only see or import the .dll.refresh file in the bin directory. but now its seems, with the fortress VS client, that it sees the dll's themselves as new files to be checked in after the rebuild...which is not the desirable functionality.
so, not sure if this is a bug or more of a feature request. please let me know.
Thanks,
Chris
1. successfully rebind a solution from vault 3.5 to fortress within visual studio.
2. rebuild a website within the solution, containing several assembly references. e.g. class.dll.refresh files in the bin directory under source control.
previously, in vault 3.5, the project check in would only see or import the .dll.refresh file in the bin directory. but now its seems, with the fortress VS client, that it sees the dll's themselves as new files to be checked in after the rebuild...which is not the desirable functionality.
so, not sure if this is a bug or more of a feature request. please let me know.
Thanks,
Chris
This reminds me of an old bug that was fixed in VS2005 SP1, the /bin/ folder of web applications (along with its contents, compiled binaries or not) was being checked in.
I assume you have VS2005 SP1, right? Otherwise it just might be the same bug showing up because of the change in the source control binding to VS2005 with Vault 4...
Here is the old bug report:
http://connect.microsoft.com/VisualStud ... kID=105516
The workarounds posted on that web page may work out for you...
I assume you have VS2005 SP1, right? Otherwise it just might be the same bug showing up because of the change in the source control binding to VS2005 with Vault 4...
Here is the old bug report:
http://connect.microsoft.com/VisualStud ... kID=105516
The workarounds posted on that web page may work out for you...
gabriel magana-gonzalez
Actually, I'll have to take that back. I'm still having this issue with some web site's. We also had an incident with checking in a modified solution. We modified it and proceed to checkin, with the checkin window only showing the solution (as expected). We then came to find out that it checked in (added) all of the referenced dll's, pdb's, and xml comment files from the 2 web sites in the solution in the background. So now the problems appears to be even more complex.
please let me know,
Chris
please let me know,
Chris
This is a confirmed problem on Web site projects (not to be confused with web application or web service projects). Unfortunately the fix did not make 1.0.3 or 1.0.4 (which was just 1.0.3 with a corrected installer). I expect it to be in the next maintenance release.
Note that the issue only manifests itself when Adding things to source control. So any time you do one of the following:
1) Add solution containing a web site to Fortress
2) Add a new web site project to a Fortress-controlled solution
3) Add a new folder to a Fortress-controlled web site project
You simply need to remove any pending adds from the list that you don't want included.
If you already have files like this in source control, you have to delete them from the repository, which is easiest via the stand-alone client.
Note that the issue only manifests itself when Adding things to source control. So any time you do one of the following:
1) Add solution containing a web site to Fortress
2) Add a new web site project to a Fortress-controlled solution
3) Add a new folder to a Fortress-controlled web site project
You simply need to remove any pending adds from the list that you don't want included.
If you already have files like this in source control, you have to delete them from the repository, which is easiest via the stand-alone client.
Ian Olsen
SourceGear
SourceGear