2

We have a legacy Access application that is still in production. I would like to at least have an automated build for it. Can you build access exe's from the command line?

Even better, there wouldn't by any chance, be an MSBuild target for Access would there?

4

3 回答 3

5

这适用于我 2010 年。需要一些时间来管理它。

Function makeAccde()
    Dim source, temp, target As String
    DoCmd.RunCommand acCmdCloseAll 
    source = CurrentProject.path & "\" & CurrentProject.name
    temp = CurrentProject.path & "\" & "_tmpCompile.accdb"
    target = Left(source, Len(source) - 1) & "e"  'you can also use "r"
    Dim db As New Access.Application
    DoCmd.RunCommand acCmdCompileAndSaveAllModules

    Set aFSO = CreateObject("Scripting.FileSystemObject")
    aFSO.CopyFile source, temp, True

    db.AutomationSecurity = msoAutomationSecurityLow
    db.SysCmd 603, temp, target
    db.Quit
    Kill temp
    Application.Quit ' if you do not quit current db, sometimes target file is corrupted.
End Function
于 2014-04-19T12:33:16.663 回答
3

您可能可以编写一个 Windows 脚本，从而具有命令行能力。

但是，尚不清楚为什么您不使用工具菜单中的选项？它不像这里的构建时间会很长。

菜单中用于将应用程序编译为访问可执行文件的选项可在此处找到：

Access 在其 20 年的历史中从未也确实生成过 .exe 文件，但将应用程序编译为 access 可执行文件的行为已成为大约 20 年的选择和选项。

因此，您似乎混淆或混淆了访问可执行文件（mde 或现在的 accde 文件）和 .exe 文件的术语。在访问方面，它们当然不是一回事。事实上，在今天，.exe 文件的概念确实没有实际意义。较旧的 FoxPro 分发工具只是简单地封装了运行时并在 p-code 系统前面添加了一个 .exe——尽管具有 .exe 文件扩展名，但从某种意义上说，它实际上从来都不是真正的可执行文件。

然而，今天大多数系统确实需要一个扩展的运行时系统。

所以请记住，就像过去使用 .net 甚至 VB6 一样，您将要求编译的 Access 可执行文件首先在目标计算机上安装支持运行时文件。然而，这与我们当今行业中的大多数主流开发工具没有什么不同。

. 因此，像 C#、vb.net 或 VB6 甚至 Java 一样，我们行业中的许多主流工具确实需要安装一组支持的运行时文件和库，然后才能在目标机器上运行已编译的应用程序。和 VB6、vb.net、C# 甚至 Java（注意我说的是 Java，而不是 JavaScript）一样，一旦在目标计算机上安装了运行时和支持库，通​​常可以通过简单的文件副本部署应用程序（xcopy 开发）。因此，在这方面，Access 再次与 Java 或 .net 大致相同。（您不必安装可执行文件 - 只需复制它，但这样的设置仅在您安装正确的支持运行时文件后才有效）。

请记住，Access 的一个缺点是支持库是办公室的共享组件。因此，功能区库、PDF 创建、图像渲染、拼写检查等都是 Word、Excel、Access、PowerPoint 等之间的通用代码共享库。

由于上述原因，如果安装了您正在使用的特定版本的 office（和 Access）的任何部分，则 Access 运行时的安装将被强制安装到与现有 office 安装相同的目录结构中。您无法更改此安装位置。请注意，反过来也是如此！– 如果您将 Access 运行时直接安装到自定义中，则 Excel、Word 和所有办公程序的安装将被强制安装到与您放置 Access 运行时文件的位置相同的目录中。如前所述，办公程序和 Access 之间的共享组件数量相当大的原因是这种组合的一部分。

由于这种大的依赖关系，除了运行时支持文件的直接固定位置之外，还会导致一些重大问题：

共享部件 = 只能安装一个版本的 Excel 或 Word 或 SAME 办公版本的 Access。因此，如果计算机已经安装了相同版本的 Office，但位格式不同，则无法安装 64 位版本的 Access 运行时。这意味着如果计算机安装了 Office 32 位 2010，则无法安装 Access 2010 运行时的 64 位版本。（您可以安装 2013 运行时或说 2007）。

此外，如果已安装 Access（完整版或运行时支持版），则无法安装运行时的第二个副本 - 安装程序将使用现有安装。

归根结底，上述所有结果意味着您为 Access 安装的运行时文件将依赖于该版本的 office，因此这种依赖关系会使 Access 应用程序的分发成为一个真正的挑战。不幸的是，虽然 Access 有一个编译器，但它没有链接器，因此无法链接 + 获取这些依赖项并创建一个单独的 dll 库。如果没有此功能，则 Access 可执行文件需要与 Access 运行时系统一起安装这些 office 支持文件。

如果您需要或需要在对已安装的现有 Office 版本的干扰最小的机器上安装 Access 运行时，那么建议采用商业安装程序以及来自 Sagkey 的一些脚本：

http://www.sagekey.com/installation_access.aspx

于 2013-01-22T20:26:09.840 回答
2 
a = CreateObject("Access.Application")
If a.SysCmd(603, PATH_TO_BXB_FILE, PATH_TO_BXE_FILE) = 0 Then
    MsgBox("Fail to compile to MDB file")
End If

syscmd的 603 参数未记录。它会因多种原因而失败，例如，在 VBA 下运行，如果您不使用单独的 MS Access 实例，它将失败。在此，其他失败的原因如下：

  • 当它用于在单独的 Access 数据库（与解决方案数据库分开）中运行的 VBA 代码中时；
  • 当解决方案数据库关闭时；和
  • 当解决方案数据库中的 VBA 代码中没有语法错误时。

请注意，即使创建成功，生成的 mde 或 accde 也可能无法在另一台机器上运行。在大多数情况下，我发现 Access 2010 是最宽容的，但是，您最终会收到令人讨厌的安全警告。

于 2013-01-22T19:49:42.540 回答