2010-04-14 21 views
3

我目前正在一个项目,涉及三个不同的网站,有很多共同的功能。目前,通用功能被放置在一个充满用户控制的不同网站中。共享用户控件acrros多个网站

问题是在多个网站上共享用户控件。环顾SO和其他网站,唯一的解决方案似乎是使用虚拟目录。由于这是一个可行的解决方案(我们目前在这方面),它似乎不是一个“干净的”解决方案。

在不同网站之间共享通用功能(包括GUI/HTML)时,有哪些“最佳实践”?

是否(例如)可以创建单个Web应用程序项目并将子目录(每个都有自己的web.config)部署到不同的生产环境中?

回答

1

有一个solution用于通过构建用户控制库共享用户控制由ScottGu描述。在我看来,这个解决方案也不是很干净,因为你必须复制预编译的文件才能使这个解决方案有效。

我决定在单独的类库中使用自定义Web控件来共享通用的UI功能。但也许斯科特的解决方案适合你。

+0

类库似乎是最明显的做不成方法。 – Darren 2012-12-11 05:42:41

0

恕我直言,即使它不干净,最好使用虚拟目录解决方案。这可以解决很多令人头疼的问题,因为您可以将其用于多个网站,而无需在每个网站中部署额外的文件,并且如果有更改,您只需在一个位置执行此操作。

HTH

3

我一直在处理这个相当长的一段时间了,而且都用了虚拟目录和“用户控件库”的方法,并发现他们都想要。我很惊讶,微软没有解决这个问题来编译用户控件,以便像服务器控件一样使用。

反正...

有两家便利,我们大多数人在试图寻找一个用户控件库时:

  1. 容易发展对。如果我们 更改用户控件,我们想要它做 它的一个地方。我们希望能够在我们工作的网络 中对 进行编辑和调试,而无需 管理ascx 文件的多个副本。
  2. 易于部署。我们想要 能够在多个网站 中抓取并发布ascx 文件,而没有太多麻烦。

不幸的是,虚拟目录方法只处理#2,而“用户控制库”处理#2地址,而只处理#1的一部分。使用“用户控制库”,您可以针对用户控制库源进行调试,但是如果您在工作网络中编辑了ascx,那么下次构建“用户控制库”时,这些更改将被覆盖。这与服务器控件的运行方式类似:必须在其他位置进行编辑,并且必须进行编译以进行更新。例外是必须复制“用户控件库”,而不是仅更新.dll引用。

解决方案?

我以前用来解决#1的是symlinks。在您的存储库中创建一个公共控件文件夹,并根据需要将该文件夹符号链接到每个网站。对源代码公共控件文件夹执行的任何对符号链接文件夹的更改都会完成。

为了解决#2,我只是部署完整的网站,将控件复制到适当的位置。您也可以轻松地创建虚拟目录,而不是在每个网站中推出符号链接的文件夹。由于担心性能问题(大量网络,大量流量),我倾向于从虚拟目录中为常见用户控件托管源代码。

我希望这有助于!