IIS虚拟目录、根路径部署ASP.NET
我需要一些关于如何创建项目结构以便从 VSS 迁移到 SVN 的指导，就目前情况而言，它具有：
开发 主干-------------------------------->http://localhost/myapp
测试环境分支 ---------->http://test.myapp.com
生产环境 分支-->http://www.myapp.com
这里的交易是路径，如你所见每个环境的根都会发生变化，因为它使用的是 IIS 6 本地站点（主干），而且，我们使用的是绝对路径，由于路径的原因，这是分支之间不一致的合并，即使我已经做了很多更改并且在服务器控件中使用 ~/ 同时获取 <% Virtualpath("~/") & /js/test.js %> 或者在某些客户端控件中 runat="server" enableviewstate="false" ，但一般来说，此方法对环境有些不透明，并且容易出错，并且会破坏一些 javascript 路径（仍未解决）。
我了解 VS 中包含的 Web 开发服务器，但我也注意到我们在使用功能时可能会遇到问题，例如身份验证、上下文安全、虚拟文件夹。
所有这些都使用本地 IIS 6、VS2005，您能分享一些您如何处理这个问题的经验吗？
I need a few pointers about how to make a project structure in order to migrate from VSS to SVN, as it stands now it has:
Dev
trunk-------------------------------->http://localhost/myappTest environment branch
---------->http://test.myapp.comProduction environment
branch-->http://www.myapp.com
The deal here are the paths, as you see the root of each environment changes because it's using IIS 6 local site(trunk), and more, we're using absolute paths, this is a inconsistent merge between branches because of the paths, even when i've done a lot of changes and using the ~/ in the server controls while getting <% Virtualpath("~/") & /js/test.js %> or runat="server" enableviewstate="false" in some client controls, but in general this method is a some how not transparent to the environments and prone to errors, and breaking some javascript paths(still not resolved).
I know about the Web Development server included in VS but I have also noticed that we can have problems with in-use features, like autentication, context security, virtual folders.
All this using local IIS 6, VS2005, could you share some of your experience in how to deal with this problem?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您可能应该只在源代码管理中维护您的 DEV 分支，使用项目部署将网站移至测试，然后通过代码将其提升到生产环境。
这样您就可以确定：
充分利用源代码控制分支/标签（在 VSS 或 SVN 或其他方式中）可以让您的开发人员查看、调试和修改测试或生产代码，但代码应该遵循测试通道中的结构化路径，并且只能升级到生产环境使用定义的代码升级流程。
You should probably only be maintaining your DEV branch in source control, using project deployment to move the web site to test, then code promoting it into production.
That way you're sure that:
Good use of source control branching/labeling (in VSS or SVN or whatever) can allow your developer to look at, debug and modify test or prod code, but the code should follow a strucutred path through your testing lane and only be promoted to production using a defined code-promotion process.