部署跨多个文件夹的应用程序......几乎<探测>

发布于 2024-10-31 05:54:16 字数 1004 浏览 1 评论 0原文

我有一个相当大的系统需要部署,有大量的组件,并且构建得非常可扩展。有一组核心组件几乎对任何事情都是必需的,而其他组件集则可以完成更专业的事情(每组组件本身就是一个应用程序 - 现在不一定是这样,但我们正朝着那个方向...)

我想在部署时尝试将一些结构放入其中。我的思路是:

  • c:\program files \ MyCompany \ MyBigSystem \ App1
  • c:\program files \ MyCompany \ MyBigSystem \ App2
  • c:\program files \ MyCompany \ MyBigSystem \ App3
  • c:\program files \ MyCompany \ MyBigSystem \ AppN
  • c:\program files\MyCompany\MyBigSystem\Core

例如...\App1中的文件无疑在...\Core中会有依赖文件,但显然我想避免将这些文件重新分发到...\App1文件夹。我希望 App1 从 Core 文件夹中选取它们。

我正在努力看看这是否可能。

以下是一些限制和观察:

目前,每个组件都是使用静态引用构建的。我更有可能将所有内容部署到一个文件夹中,而不是放弃这种立场。此外,我不想修改任何采用此部署结构的程序代码。因此,诸如使用 Assembly.LoadFrom 或巧妙设置 appDomain 路径之类的大规模更改已不再适用。

然而,我愿意接受 app.config 条目,因为这些可以在安装过程中写入。

我查看了(并进行了非常简单的测试),乍一看似乎很理想,但最终由于它是子目录的限制而变得不合适,

我查看了- 我没有完全阅读这一点,因为必须单独注册十几个核心组件让我感到厌烦(尽管话虽如此,但如果我准备好迎接麻烦,它看起来很可能会得到我想要的东西) 。

谁能建议我可能考虑的任何其他方法?

蒂亚,皮特

I have a pretty large system to deploy, plenty of components and built to be quite extensible. There is a core set of components which are necessary for pretty much anything, and other sets of components which do more specialised things (to the point of each set being an application in their own right - this isn't necessarily true now, but we're headed that way...)

I would like to try and put some structure into things when I deploy. I was thinking along the lines of:

  • c:\program files \ MyCompany \ MyBigSystem \ App1
  • c:\program files \ MyCompany \ MyBigSystem \ App2
  • c:\program files \ MyCompany \ MyBigSystem \ App3
  • c:\program files \ MyCompany \ MyBigSystem \ AppN
  • c:\program files \ MyCompany \ MyBigSystem \ Core

The files in e.g. ...\App1 will undoubtedly have dependent files in ...\Core, but obviously I want to avoid redistributing these files to the ...\App1 folder. I want App1 to pick them up from the Core folder.

I am struggling to see whether this is possible.

Here's some constraints and observations:

Currently, every component is built using static references. I am more likely to deploy everything into a single folder than to abandon this stance. Furthermore I don't want to modify any program code which assumes this deployment structure. So wholesale changes such as using Assembly.LoadFrom, or smartly setting the appDomain's path, are out.

I am however amenable to app.config entries, because these can be written during setup.

I have looked at (and very briefly tested) <probing>, which at first glance appeared ideal, but ended up being unsuitable because of its constraint of being a subdirectory

I have looked at <codeBase> - I didn't read into this fully because having to register a dozen or so core assemblies individually put me right off (although having said that, it looks like it could well get me what I want if I were prepared to take the trouble).

Can anyone suggest any other approach I might consider?

TIA, Pete

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

冬天旳寂寞 2024-11-07 05:54:16

您可能必须编译而不是发布。使用第三方安装程序是最简单的。安装盾很好。

You will probably have to compile and not release. Using a third-party installer will be the easiest. Install Shield is nice.

写给空气的情书 2024-11-07 05:54:16

如果您使用的是 Eclipse,则可以为 Core 创建一个项目作为源库,并将其包含在所有其他项目中。

If you are using Eclipse, you can create a project for Core as a source library, and include it in all your other projects.

樱桃奶球 2024-11-07 05:54:16

最后我几乎得到了我想要的东西,但还不够。我最终得到了我想要的所有文件夹结构...

  • c:\program files \ MyCompany \ MyBigSystem \ App1
  • c:\program files \ MyCompany \ MyBigSystem \ App2
  • c:\program files \ MyCompany \ MyBigSystem \ App3
  • c: \program files \ MyCompany \ MyBigSystem \ AppN
  • c:\program files \ MyCompany \ MyBigSystem \ Core

....但必须将主要可执行文件放在“MyBigSystem”文件夹中,即

  • c:\program files \ MyCompany \ MyBigSystem \ App1 .exe
  • c:\program files\MyCompany\MyBigSystem\App1.exe.config
  • c:\program files\MyCompany\MyBigSystem\App2.exe
  • c:\program files\MyCompany\MyBigSystem\App2.exe.config

我用以下内容补充了此结构可执行文件的配置文件中的条目,例如

  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <probing privatePath="Core"/>
    </assemblyBinding>
  </runtime>

这似乎使根文件夹保持整洁,正如我合理希望的那样。例如,如果有必要,它还允许 App6 访问 App1 中的依赖库。 (正是出于这个原因,我回避了 GAC - 如果我们的应用程序依赖于应用程序,我可以看到我们必须对所有内容进行 GAC,这是不合适的。)

除了配置之外,此方法中没有任何代码更改。主要的挑战是让 VS 安装项目将除 .exe 和 .exe.config 之外的所有内容都放入子文件夹中。

In the end I got almost what I wanted but not quite. I ended up with all the folder structure that I wanted....

  • c:\program files \ MyCompany \ MyBigSystem \ App1
  • c:\program files \ MyCompany \ MyBigSystem \ App2
  • c:\program files \ MyCompany \ MyBigSystem \ App3
  • c:\program files \ MyCompany \ MyBigSystem \ AppN
  • c:\program files \ MyCompany \ MyBigSystem \ Core

....but had to put the main executables in the "MyBigSystem" folder, i.e.

  • c:\program files \ MyCompany \ MyBigSystem \ App1.exe
  • c:\program files \ MyCompany \ MyBigSystem \ App1.exe.config
  • c:\program files \ MyCompany \ MyBigSystem \ App2.exe
  • c:\program files \ MyCompany \ MyBigSystem \ App2.exe.config

I supplemented this structure with <probing> entries in the executables' config files, e.g.

  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <probing privatePath="Core"/>
    </assemblyBinding>
  </runtime>

This seemed to keep the root folder as uncluttered as I could reasonably hope for. It also allows App6 to access dependent libraries in App1, for example, should this ever be necessary. (It was for this reason that I shied away from the GAC - if ever we get Apps dependent on apps, I can see us having to GAC everything, which would be inappropriate.)

No code changes in this approach other than in the configs. The main challenge became getting the VS Setup project to put everything except the .exe and the .exe.config in the subfolder.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文