|
(This post was originally in the wrong topic... sorry)
I've created a Web site on a network server in-house using Visual Studio 2005. The Web site runs perfectly well and is accessible from all computers within my domain.
I've also created a Team Project under which I would like to add the Web site project to source control. Attempting to do so gives this error:
"Microsoft Visual Studio cannot add some of the projects you have selected to source control because they are Web projects that are using FrontPage Web access. The Visual Studio Team Foundation source control plug-in does not support source control operations on this type of Web project."
Note: The Web site was created by using File > New > Web Site and specifying something similar to "http://website.domain" (using Windows DNS Management for in-house sub-domains).
Getting TFS to work has been a never ending battle with error after error.
Naturally, in order to create a Web site using Visual Studio, one needs FrontPage Server Extensions installed. Is this different than what is referred to as "FrontPage Web access" in the above error message? Any thoughts on how to rectify this issue? | | Christopher Janecek | Just curious, is there a reason why you would want all of your developers to work in a non-isolated environment where one developer can easily stomp on another's code. We are in this unfortunate position today due to security policies not allowing developers to have IIS on thier workstations. We are VERY excited that VS.NET 2005 has its own lightweight web server that is only accessible via localhost.
I just tried to create a new web site using a location of "HTTP" and it seems to require frontpage server extensions. Once I added FrontPage Server Extensions it gave me the following error message:
Microsoft Visual Studio cannot add some of the projects you have selected to source cotnrol because they are Web projects that are using FrontPage Web access. The Visual Studio Team Foundation source control plug-in does not support source control operations on this type of web project.
Jason Camp, MCSE, MCSD, MCDBA, MCAD, MCSA, CISSP, SCSA | | Jason D. Camp | I'm not sure if our environment goals are optimal, but we would like to have an in-house development server that mirrors as closely as possible our live production server. Also, to allow reviewing of Web sites as they are developed, we like the idea of the development server "feeling" like a live server.
In other words, we have a server called "dev" within our domain. For each Web site put into production, we would like to create a subdomain of "dev" (CNAMEs in DNS) corresponding to that Web site. So, for example, if Company 1 has a new Web site in production, people within our organization can see the developers' work-in-progress on the site by visiting http://company1.dev/ internally. People outside our organization (e.g. the client) can see the developers' work-in-progress by visiting http://company1.dev.our-organization.com/.
So, the goal for our environment is to deploy this setup using Visual Studio 2005 and apply source control to each Web project on the "dev" server. Thus, we would have a situation in which only developers could access the source code and make changes while other people can view the developers' progress. Of course, to keep developers from stomping on each other's code, we would utilized source control provided by TFS.
---
Anyway... We discovered a way to put the Web site into source control within Visual Studio 2005: instead of opening the project from the remote site using HTTP, we opened the project using the local (network) filesystem. That allowed the project to be added to source control.
| | Christopher Janecek | I believe that the setup you describe above will work in most circumstances, but you might want to reconsider if you have multiple developers working on the same web site. We have a very similar setup today in with VS.NET 2003 and I believe these same issues would hold true for VS.NET 2005. If one developer saves a file to the shared working space that doesn?? compile, it will negatively impact the other developers working on that web site. You will also run into issues if you allow multiple checkouts since the developers are sharing the same ??orking folder?? I am beginning to plug the holes in my Swiss cheese understanding of VSTS, but it?? just a huge system and will take some time to do so. If we do get the go-ahead to purchase VSTS, I think we will have all the developers work in isolated mode so as not to negatively impact one another. We will run daily builds of the web sites and deploy them to a shared development server. A peer reviewer could bring all the code locally to their workstation and debug locally if need be. A last peer review would happen before code gets deployed from a development to staging. (Developers don?? have write access to staging.) The implementation process would be tested and QA would have a ?渇rozen??environment for testing purposes.
Jason Camp, MCSE, MCSD, MCDBA, MCAD, MCSA, CISSP, SCSA | | Jason D. Camp | I came across this thread while searching for info on an error trying to add a Web project to Team Foundation. I'm not sure I'm following the issues here. First, trying to add an existing web site to TF gives me an error about FrontPage Web Access. From what I read here, if I mapped to the directory where the web code lives, I could add the project without trouble. This, however, raises issues about how to best configure Team Foundation for this type of project. If I follow what's going on here, the suggestion is that TF only contain compiled, working, code. Developers each have a complete copy of the site on their own machines -- not by checkout but by file copy -- and send completed code to TF. Is that right? How does that prevent one developer from killing code written by another? What suggestions do folks have, in broad terms, for the best way to use TF in large, complex, web site development and maintenance?
Thanks.
Randy | | rchrismor013 |
|
index > Team Foundation Server - General > Adding Web Site to Source Control - Error FrontPage Web Access