2

まだ本番環境にあるレガシーAccessアプリケーションがあります。少なくとも自動ビルドが必要です。コマンドラインからアクセスexeを作成できますか？

さらに良いことに、AccessのMSBuildターゲットはありませんか？

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スクリプトを記述して、コマンドライン機能を使用することができます。

しかし、とにかくツールメニューのオプションを使用しない理由は不明ですか？ここでビルド時間が長くなるのは好きではありません。

アプリケーションをアクセス実行可能ファイルにコンパイルするためのメニューのオプションは、次の場所にあります。

20年の歴史の中で、Accessは.exeファイルを生成できませんでしたが、アプリケーションをアクセス実行可能ファイルにコンパイルするという行為は、約20年間の選択とオプションでした。

したがって、アクセス実行可能ファイル（mdeまたは現在はaccdeファイル）という用語と.exeファイルの用語を混同または混同しているようです。アクセスに関しては、確かに同じものではありません。そして実際、今日では、.exeファイルの概念は非常に重要ではありません。古いFoxPro配布ツールは、ランタイムをラップし、pコードシステムの前に.exeを押し込んだだけでした。.exeファイル拡張子があるにもかかわらず、それはある意味で真の実行可能ファイルではありませんでした。

ただし、今日のMOSTシステムには、広範なランタイムシステムが必要です。

したがって、過去に.netまたはVB6を使用した場合と同様に、コンパイルされたAccess実行可能ファイルには、ターゲットコンピューターに最初にサポートするランタイムファイルがインストールされている必要があることに注意してください。ただし、これは、今日の業界の主流の開発ツールのほとんどと同じです。

。したがって、C＃、vb.net、VB6、さらにはJavaのように、業界の主流ツールの多くは、コンパイルされたアプリケーションをターゲットマシンで実行する前に、サポートするランタイムファイルとライブラリのセットをインストールする必要があります。また、VB6、vb.net、C＃、さらにはJava（JavaScriptではなくJavaと言ったことに注意してください）のように、ランタイムとサポートライブラリがターゲットコンピューターにインストールされると、通常、アプリケーションは単純なファイルコピーで展開できます。 （xcopy開発）。したがって、この点でも、AccessはJavaまたは.netとほとんど同じです。（実行可能ファイルをインストールする必要はありませんが、コピーするだけですが、そのようなセットアップは、正しいサポートランタイムファイルをインストールした後でのみ機能します）。

Accessの欠点の1つは、サポートするライブラリがOfficeの共有コンポーネントであることに注意してください。したがって、リボンライブラリ、PDF作成、画像レンダリング、スペルチェックなどはすべて、Word、Excel、Access、PowerPointなどの間の共通のコードライブラリです。

上記の結果、使用している特定のバージョンのOffice（およびAccess）のいずれかの部分がインストールされている場合、Accessランタイムのインストールは、既存のOfficeインストールと同じディレクトリ構造に強制的にインストールされます。このインストール場所は変更できません。逆もまた真であることに注意してください！– Accessランタイムをカスタムに直接インストールする場合、Excel、Word、およびすべてのOfficeプログラムのインストールは、Accessランタイムファイルを配置した場所と同じディレクトリに強制的にインストールされます。前述のように、この理由は、オフィスプログラムとAccessの間で共有されるコンポーネントの数がかなり多いためです。

この大きな依存関係の結果として、ランタイムサポートファイルの直接固定された場所に加えて、いくつかの重要な問題が発生します。

パーツの共有=インストールできるのはExcelまたはWordの1つのバージョン、または同じOfficeバージョンのAccessのみです。その結果、コンピューターに同じリリースのOfficeが既にインストールされているが、ビット単位の形式が異なる場合、64ビットバージョンのAccessランタイムをインストールすることはできません。つまり、コンピューターにOffice 32ビット2010がインストールされている場合、Access2010ランタイムの64ビット版をインストールすることはできません。（ただし、2013ランタイムをインストールすることも、2007と言うこともできます）。

また、Access（フルまたはランタイムサポートエディション）がすでにインストールされている場合、ランタイムの2番目のコピーをインストールすることはできません。インストーラーは既存のインストールを利用します。

結局のところ、上記のすべての結果は、Access用にインストールされたランタイムファイルがそのバージョンのOfficeに依存することを意味します。そのため、この依存関係により、Accessアプリケーションの配布が非常に困難になる可能性があります。残念ながら、Accessにはコンパイラがありますが、リンカーがないため、これらの依存関係をリンクして取得し、別のdllライブラリを作成することはできません。この機能がない場合、Access実行可能ファイルでは、これらのOfficeサポートファイルをAccessランタイムシステムと一緒にインストールする必要があります。

インストールされている既存のバージョンの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で実行すると、MSAccessの別のインスタンスを使用しないと失敗します。これで、失敗する他の理由は次のように与えられます：

  • 別のAccessデータベース（ソリューションデータベースとは別）で実行されているVBAコードで使用される場合。
  • ソリューションデータベースが閉じられたとき。と
  • ソリューションデータベースのVBAコードに構文エラーがない場合。

作成が成功した場合でも、結果のmdeまたはaccdeが別のマシンで機能しない場合があることに注意してください。ほとんどの場合、Access 2010が最も寛容であることがわかりましたが、厄介なセキュリティ警告が表示されることになります。

于 2013-01-22T19:49:42.540 に答える