問題タブ [buildaction]

C# プロジェクトでファイルの BuildAction (Powershell を使用) を設定する方法について、この質問とこの回答を見つけました。

基本的に、指定されたアイテムを取得してから、「BuildAction」の値を設定します。

$item = $project.ProjectItems | where-object {$_.Name -eq "ReleaseNotes.txt"} $item.Properties.Item("BuildAction").Value = [int]3

prjBuildAction 列挙値を利用する方法があるかどうか疑問に思っています (私にはうまくいかないようです)。

2 番目のステートメントを変更しようとしましたが、BuildAction は変更されません。

では、代わりに列挙値を使用する方法はあります[int]3か?

プロジェクトのビルド時に変更された JS ファイルを縮小するために、次のコードを .csproj に追加しました。

これはうまく機能しますが、副作用があります。Visual Studio (2015) でプロジェクトを見ると、すべての JS ファイルが重複しているように見えます (パスは同じですが、ビルド アクションは異なります)。

プロジェクトに「JS」ビルド アクションを含むアイテムが表示されないようにしたいと思います。どうやってやるの？

複数の開発者がプロ​​ジェクトで作業しているため、提案されたソリューションは .csproj またはソリューション内に含める必要があることに注意してください (例: すべての開発者に、レジストリを変更して JS ファイルのデフォルトのビルド アクションを変更するよう依頼することは受け入れられません)。 ）。

プロジェクトにアクセス データベースをデータソースとして追加しました。したがって、自動的に生成された tableadapters クラスを取得し、接続文字列を含むテーブル アダプター インスタンスにアクセスします。これを使用してデータベースへの接続を開いているので、最初にいくつかのレコードを削除してから、それらを新しいレコードに置き換えることができます。.executenonquery影響を受ける行が返されるため、クエリは機能しているようです。delete *念のためコマンドも試してみました。しかし、データベースを開くと、すべてが同じです。その理由についていくつかのアイデアがありました。プロジェクトのデータ ディレクトリへの汎用ポインタが含まれているため、tableadapter によって返される接続文字列は間抜けかもしれないと思いました。

プロバイダー=Microsoft.Jet.OLEDB.4.0;データ ソース=| DataDirectory |\DupeMDB.mdb;Persist Security Info=True

また、ビルド アクションまたは出力ディレクトリへのコピーに問題があるのではないかと考えました。この 2 つの背後にあるメカニズムがよくわかりません。出力ディレクトリへのコピーが原因である可能性があると思います。

これが私の目標です。このプロジェクトを秘書に展開して、彼女がプログラムを使用して重複レコードリストなどを処理できるようにしたいと考えています。データはプログラムと一緒に移動する必要があります。この.mdfファイルを配置と一緒にパッケージ化し、彼女が作業を終えたときにそれを返したいと考えています。私はここで終わりに近づいています（テーブルに書き戻します）。テーブルが更新されない理由を知っている人はいますか?

C# プロジェクトで次の警告が表示されます。

プロジェクトは、次の値を持つ DAL05 を参照します。

また、プロジェクトの bin フォルダーには、次の値を持つ DAL05.dll が含まれています。

この DLL が「ファイルとして正しく指定されていない」と見なされるとはどういう意味ですか? これは「ただの」警告なので、喜んで無視してもいいですか、それとも浅瀬礁の可能性がありますか?

Visual Studio 2012データベース プロジェクトの SQL スクリプトのビルドアクションに関する多くの情報を ( Web 上で)見つけることができますが、展開時にスクリプトをコンパイルまたはインクルードしないことを理解していますが、誰かが明確にアドバイスまたは指示できます。との機微を決定的に定義する記事に私を。PreDeployPostDeploy NoneBuildCompile

私の大まかな想定では、これらは両方ともスキーマに対してコンパイルされますが、Build展開されるだけです。これは正しいです？

私が望むのは、現在のスキーマに対してシード スクリプトを検証する (そして、無効なスキーマ構造でビルド エラーを引き起こす) 正しい設定ですが、データベースの公開で展開したり、スキーマ比較セッションに表示したりしないことです。